Skip to main content
Glama

list_comfyui_queue

View running and pending jobs in the ComfyUI execution queue to monitor workflow processing status and manage job priorities.

Instructions

List current ComfyUI execution queue.

Shows running and pending jobs in the ComfyUI queue.

Args: server_address: ComfyUI server address

Returns: Queue information with running and pending jobs

Examples: list_comfyui_queue() list_comfyui_queue("192.168.1.100:8188")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
server_addressNo127.0.0.1:8188

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The primary handler function for the 'list_comfyui_queue' MCP tool. It creates a ComfyUIClient instance, fetches the queue status via API, formats the running and pending jobs, and returns a structured result.
    @mcp.tool
    async def list_comfyui_queue(
        ctx: Context,
        server_address: str = DEFAULT_COMFYUI_SERVER
    ) -> Dict[str, Any]:
        """List current ComfyUI execution queue.
        
        Shows running and pending jobs in the ComfyUI queue.
        
        Args:
            server_address: ComfyUI server address
        
        Returns:
            Queue information with running and pending jobs
        
        Examples:
            list_comfyui_queue()
            list_comfyui_queue("192.168.1.100:8188")
        """
        await ctx.info(f"Fetching queue status from {server_address}")
        
        try:
            client = ComfyUIClient(server_address)
            queue = await client.get_queue_status()
            
            result = {
                "server_address": server_address,
                "queue_running": len(queue.get("queue_running", [])),
                "queue_pending": len(queue.get("queue_pending", [])),
                "running_jobs": [],
                "pending_jobs": []
            }
            
            # Format running jobs
            for item in queue.get("queue_running", []):
                result["running_jobs"].append({
                    "prompt_id": item[1],
                    "submitted_at": item[2],
                    "position": 0  # Currently running
                })
            
            # Format pending jobs
            for i, item in enumerate(queue.get("queue_pending", [])):
                result["pending_jobs"].append({
                    "prompt_id": item[1],
                    "submitted_at": item[2],
                    "position": i + 1
                })
            
            await ctx.info(f"✓ Queue: {result['queue_running']} running, {result['queue_pending']} pending")
            return result
            
        except Exception as e:
            raise ToolError(f"Failed to get queue status: {e}")
  • The ComfyUIClient helper method that performs the HTTP GET request to the ComfyUI /queue endpoint to retrieve the raw queue data used by the tool handler.
    async def get_queue_status(self) -> Dict[str, Any]:
        """Get current queue status"""
        async with httpx.AsyncClient() as client:
            response = await client.get(f"{self.base_url}/queue")
            response.raise_for_status()
            return response.json()
  • Documentation in __init__.py listing the available tools, including list_comfyui_queue.
    - list_comfyui_queue: View ComfyUI queue status
Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses the tool's read-only nature (list/shows) and scope (running and pending jobs), but doesn't mention rate limits, authentication needs, pagination, or error conditions. The behavioral disclosure is adequate but minimal.

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 efficiently structured with a clear purpose statement, brief elaboration, and well-organized sections for Args, Returns, and Examples. Every sentence adds value without redundancy, and information is appropriately front-loaded.

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 moderate complexity (queue listing), no annotations, and the presence of an output schema (which handles return value documentation), the description is reasonably complete. It covers purpose, parameter meaning, and examples, though could benefit from more behavioral context about limitations or edge cases.

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?

Schema description coverage is 0%, but the description compensates well by explaining the single parameter's purpose ('ComfyUI server address') and providing examples with default and explicit values. For a tool with only one optional parameter, this provides sufficient semantic context beyond the bare schema.

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 verb 'List' and resource 'current ComfyUI execution queue', with additional detail about 'running and pending jobs'. It distinguishes from siblings like get_job_status (single job) and list_workflows (workflow definitions).

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

Usage Guidelines3/5

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

The description implies usage when needing queue status, but doesn't explicitly state when to use this vs alternatives like get_job_status for specific job details or execute_workflow for queueing new jobs. No explicit exclusions or prerequisites are mentioned.

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/christian-byrne/comfy-mcp'

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