Problem
When debugging deployment issues with stuck or pending flow runs, it's impossible to determine if work pool concurrency limits are the cause because the MCP server doesn't expose work pool configuration details.
Current Situation
The MCP server currently provides:
- Basic work pool status via
prefect://dashboard (name, type, is_paused, status)
- Work pool events via
read_events(event_type_prefix="prefect.work-pool")
But it's missing crucial debugging information:
- Work pool concurrency limits
- Work queue configuration and concurrency limits
- Number of workers polling the queue
- Global concurrency limits
Example Debug Scenario
When debugging deployment d2282256-e963-4175-87af-830a0d9bf710:
- Flow runs transition from SCHEDULED → LATE without reaching PENDING
- Dashboard shows multiple running flows
- Cannot determine if work pool concurrency (likely set to 2) is blocking new runs
Proposed Solution
Add a new resource: prefect://work-pools/{name} that returns:
{
"id": "...",
"name": "test-pool",
"type": "process",
"status": "READY",
"is_paused": false,
"concurrency_limit": 2, # Critical for debugging
"work_queues": [
{
"name": "default",
"concurrency_limit": null,
"priority": 1
}
],
"active_workers": 1, # How many workers are polling
"description": "..."
}
This would enable proper diagnosis of concurrency-related issues without needing direct API or CLI access.
Problem
When debugging deployment issues with stuck or pending flow runs, it's impossible to determine if work pool concurrency limits are the cause because the MCP server doesn't expose work pool configuration details.
Current Situation
The MCP server currently provides:
prefect://dashboard(name, type, is_paused, status)read_events(event_type_prefix="prefect.work-pool")But it's missing crucial debugging information:
Example Debug Scenario
When debugging deployment
d2282256-e963-4175-87af-830a0d9bf710:Proposed Solution
Add a new resource:
prefect://work-pools/{name}that returns:{ "id": "...", "name": "test-pool", "type": "process", "status": "READY", "is_paused": false, "concurrency_limit": 2, # Critical for debugging "work_queues": [ { "name": "default", "concurrency_limit": null, "priority": 1 } ], "active_workers": 1, # How many workers are polling "description": "..." }This would enable proper diagnosis of concurrency-related issues without needing direct API or CLI access.