Skip to main content
Glama

get_work_queues

Retrieve work queues from Prefect with filtering options by name, paused status, and pagination controls to manage workflow automation resources.

Instructions

Get a list of work queues with optional filtering.

Args: limit: Maximum number of work queues to return offset: Number of work queues to skip name: Filter by name is_paused: Filter by paused status

Returns: A list of work queues with their details

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
is_pausedNo
limitNo
nameNo
offsetNo

Implementation Reference

  • Implementation of the get_work_queues tool handler function using Prefect client to fetch work queues with optional filters.
    @mcp.tool
    async def get_work_queues(
        limit: Optional[int] = None,
        offset: Optional[int] = None,
        name: Optional[str] = None,
        is_paused: Optional[bool] = None,
        work_pool_name: Optional[str] = None,
    ) -> List[Union[types.TextContent, types.ImageContent, types.EmbeddedResource]]:
        """
        Get a list of work queues with optional filtering.
        
        Args:
            limit: Maximum number of work queues to return
            offset: Number of work queues to skip
            name: Filter by name
            is_paused: Filter by paused status
            work_pool_name: Filter by work pool name
            
        Returns:
            A list of work queues with their details
        """
        async with get_client() as client:
            # Build filter object
            work_queue_filter = None
            
            if name or is_paused is not None:
                work_queue_filter = WorkQueueFilter()
                if name:
                    work_queue_filter.name = WorkQueueFilterName(like_=f"%{name}%")
                # Note: is_paused filter is not directly available in WorkQueueFilter
                # We'll handle it by filtering the results after the API call
            
            work_queues = await client.read_work_queues(
                work_queue_filter=work_queue_filter,
                work_pool_name=work_pool_name,
                limit=limit,
                offset=offset or 0
            )
            
            # Apply is_paused filter manually if needed
            if is_paused is not None:
                work_queues = [wq for wq in work_queues if wq.is_paused == is_paused]
            
            work_queues_result = {
                "work_queues": [work_queue.model_dump() for work_queue in work_queues]
            }
            
            return [types.TextContent(type="text", text=str(work_queues_result))]
  • Conditional import of the work_queue module in main.py, which triggers registration of tools (including get_work_queues) via @mcp.tool decorators.
    if APIType.WORK_QUEUE.value in apis:
        info("Loading Work Queue API...")
        from . import work_queue
  • Creation of the FastMCP server instance 'mcp' used by @mcp.tool decorators to register tools.
    mcp = FastMCP(f"MCP Prefect {__version__}")
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions optional filtering and returns a list with details, but lacks critical information such as pagination behavior (implied by limit/offset but not explained), authentication requirements, rate limits, error handling, or whether it's read-only (though 'Get' suggests it). For a tool with no annotations, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized: a clear purpose statement followed by 'Args' and 'Returns' sections. Each sentence adds value without redundancy. It could be slightly more concise by integrating the purpose with the args, but overall it's efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (a list retrieval tool with filtering), no annotations, no output schema, and low schema coverage, the description is moderately complete. It covers the basic purpose, parameters, and return type, but lacks behavioral details (e.g., pagination, errors) and usage context. Without an output schema, it doesn't explain the structure of returned details, leaving gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It lists parameters (limit, offset, name, is_paused) and briefly explains their purposes (e.g., 'Filter by name'), adding meaning beyond the schema's titles. However, it doesn't provide details like default values, constraints (e.g., limit ranges), or how filtering works (e.g., exact match vs. substring). This offers some value but falls short of fully compensating for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get a list of work queues with optional filtering.' It specifies the verb ('Get') and resource ('work queues'), and the optional filtering adds specificity. However, it doesn't explicitly differentiate from sibling tools like 'get_work_queue' (singular) or 'get_work_queue_by_name', which might handle individual retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools such as 'get_work_queue' (for single queue retrieval) or 'get_work_queue_by_name' (for retrieval by name), nor does it specify prerequisites or contexts for usage. This leaves the agent without clear direction on tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/allen-munsch/mcp-prefect'

If you have feedback or need assistance with the MCP directory API, please join our Discord server