ComfyUI MCP Server

get_queue_status

Check the execution status of workflows in ComfyUI by retrieving running and pending job details from the queue.

Instructions

Get current queue: running and pending jobs.

    Returns:
    - queue_running: List of currently executing workflows
    - queue_pending: List of queued workflows waiting to run
    - running_count: Number of running jobs
    - pending_count: Number of pending jobs

    Use this to check if workflows are executing or queued.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_queue_status"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Implementation Reference

src/comfy_mcp_server/tools/system.py:37-58 (handler)

The handler function for the 'get_queue_status' tool. It fetches the queue status from ComfyUI's /queue endpoint, validates it with QueueStatus model, adds computed fields, and returns the result or an error.

def get_queue_status(ctx: Context) -> dict:
    """Get current queue: running and pending jobs.

    Returns:
    - queue_running: List of currently executing workflows
    - queue_pending: List of queued workflows waiting to run
    - running_count: Number of running jobs
    - pending_count: Number of pending jobs

    Use this to check if workflows are executing or queued.
    """
    ctx.info("Fetching queue status...")
    try:
        data = comfy_get("/queue")
        status = QueueStatus(**data)
        result = status.model_dump()
        result["running_count"] = status.running_count
        result["pending_count"] = status.pending_count
        result["is_empty"] = status.is_empty
        return result
    except Exception as e:
        return ErrorResponse.unavailable(str(e)).model_dump()

src/comfy_mcp_server/models.py:53-70 (schema)

Pydantic model defining the structure and validation for the queue status response used in get_queue_status.

class QueueStatus(BaseModel):
    """Queue status from /queue endpoint."""

    queue_running: list[list[Any]] = Field(default_factory=list)
    queue_pending: list[list[Any]] = Field(default_factory=list)

    @property
    def running_count(self) -> int:
        return len(self.queue_running)

    @property
    def pending_count(self) -> int:
        return len(self.queue_pending)

    @property
    def is_empty(self) -> bool:
        return self.running_count == 0 and self.pending_count == 0

src/comfy_mcp_server/__init__.py:92-92 (registration)
Top-level registration call that includes get_queue_status by invoking register_all_tools(mcp), which chains to register_system_tools.
```
register_all_tools(mcp)
```
src/comfy_mcp_server/tools/__init__.py:25-25 (registration)
Specific registration for system tools, including get_queue_status, called within register_all_tools.
```
register_system_tools(mcp)
```

Schema Changelog

Changes observed during successful MCP inspections.

First observedDec 16, 2025

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (queue status with specific fields) and implies it's a read-only operation by using 'Get' and 'check,' though it doesn't explicitly state permissions, rate limits, or side effects. It adds useful context about the return structure, which is valuable given the lack of annotations.

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

Conciseness5/5

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

The description is well-structured and front-loaded with the main purpose, followed by a clear breakdown of return values and usage guidance. Every sentence earns its place by adding value—no wasted words or redundancy. It's appropriately sized for a tool with no parameters and clear output details.

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

Completeness4/5

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

Given the tool's complexity (simple read operation with 0 parameters) and lack of annotations/output schema, the description is quite complete: it explains the purpose, return structure, and usage. However, it doesn't cover potential edge cases like error handling or data freshness, which could be useful for an agent. Still, it provides sufficient context for effective use.

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

Parameters4/5

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

The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the inputs. The description doesn't need to add parameter details, but it does mention the context of 'workflows' which aligns with the tool's purpose. Since there are no parameters, a baseline of 4 is appropriate as the description compensates by explaining the output semantics.

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

Purpose5/5

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

The description clearly states the specific action ('Get current queue') and resource ('running and pending jobs'), distinguishing it from siblings like get_history, get_system_stats, or get_prompt_status which focus on different aspects of the system. It precisely defines what the tool retrieves without being vague or tautological.

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

Usage Guidelines5/5

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

The description explicitly states 'Use this to check if workflows are executing or queued,' providing clear guidance on when to use this tool. It differentiates from siblings by focusing on queue status rather than history, stats, or other workflow operations, making it easy to choose this over alternatives like get_history or get_system_stats.

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