Skip to main content
Glama
SwayamJoshi87

comfyui-mcp

by SwayamJoshi87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

enqueue_workflow

Submit ComfyUI workflows to the execution queue to start renders, rerun prior jobs, run shared URLs or templates, and return prompt IDs immediately.

Instructions

Submit work to the ComfyUI execution queue — the primary way an agent starts a render. Driven by the action parameter:

  • action:"enqueue" — Submit an API-format workflow you are already holding (one you built with create_workflow, loaded with get_workflow, or edited with create_workflow action:"modify"). Returns immediately with the prompt_id and queue position; does NOT wait for completion. Seed values in the workflow are used EXACTLY as supplied — they are NOT re-randomized, so a run is reproducible by resubmitting the same workflow (for a fresh-seed re-run of a past job, use action:"rerun"). workflow is required. Use queue (action:"status") to check progress later, or get_history (action:"list") to retrieve results and images after completion.

  • action:"rerun" — Re-run the workflow behind a PREVIOUS generation. Retrieves the prompt graph from execution history (by prompt_id, or the most recent run when omitted — chosen by ComfyUI's queue number, same logic as get_history) and re-enqueues it, optionally applying inputs overrides. Seeds are re-randomized (within each node's declared range) unless disable_random_seed is set or the seed is pinned via inputs. Returns the new prompt_id and the source prompt_id it came from. Clear error if no matching history exists. To re-run from a registered ASSET instead of history, use generate_image (action:"regenerate").

  • action:"run_url" — Read (and optionally execute) a SHARED workflow from a URL. Fetches the workflow JSON, accepts API-format prompt graphs or UI-format exports (UI is auto-converted via the same converter as get_workflow), validates it, and summarizes it. Supports raw .json links and GitHub blob/raw URLs (blob is normalized to raw); other share hosts that need a site API return a clear 'paste the raw JSON URL' error. The fetch is bounded (http/https only, timeout + size cap, loopback/private/metadata IPs rejected to prevent SSRF). READ-ONLY unless run=true; when run=true it enqueues the workflow (applying optional inputs overrides) and returns the prompt_id. url is required.

  • action:"template_schema" — Get a template's OVERRIDABLE run-time parameters (its 'slots') BEFORE running it. Pass a bundled pack name (from list_packs action:"list") or a custom-node-contributed workflow template name (from list_packs action:"list_templates") as template. Returns slots — the meaningful knobs: positive/negative prompt, seed, steps, cfg, sampler/scheduler, width/height, checkpoint/LoRA/model files, denoise, batch_size, input image — plus other_slots (every remaining overridable widget), each with a stable key ".<widget_name>", semantic role, type, current value, and min/max/options where the node schema is known. Read-only. Feed the keys DIRECTLY into action:"run_template"'s overrides (same convention) for a schema→run round-trip.

  • action:"run_template" — ONE-SHOT: run a named workflow template (a bundled pack from list_packs) with optional overrides. Resolves the template's expert graph, applies overrides, and enqueues it — replacing the manual list_packs (action:"read_workflow") → create_workflow (action:"modify") → action:"enqueue" chain. Override keys are '.<widget_name>' (e.g. {'6.text': 'a cat', '3.seed': 42}) — the SAME keys action:"template_schema" reports (when available), so schema→run round-trips; only widget values can be overridden, never graph connections. By default returns {prompt_id} immediately; pass wait:true to block until the job completes and return its outputs (images etc.). Unresolvable template names return a clear error with near-matches. template is required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
runNoaction:"run_url" — if true, enqueue the fetched workflow for execution and return the prompt_id. Default false: only fetch, validate, and summarize (read-only).
urlNoaction:"run_url" — URL of the workflow JSON. Raw .json links and GitHub blob/raw URLs work directly. REQUIRED for that action.
waitNoaction:"run_template" — block until the job completes and return its outputs. Default false: return {prompt_id} immediately.
actionYesWhich enqueue entry point to use. action:"enqueue" requires `workflow`; action:"rerun" takes an optional `prompt_id` (+ `inputs`); action:"run_url" requires `url` (+ `run`/`inputs`); action:"template_schema" and action:"run_template" require `template`; with action:"run_template" you may also pass `overrides`/`wait`/`timeout_s`.
inputsNoOverrides applied to every node with a matching input name (e.g. cfg, steps, sampler_name, seed, text). Used by action:"rerun", and by action:"run_url" only when run=true.
templateNoTemplate name/id: a bundled pack directory name (list_packs action:"list") or a custom-node-contributed workflow template name (list_packs action:"list_templates"). REQUIRED for action:"template_schema" and action:"run_template".
workflowNoaction:"enqueue" — ComfyUI workflow in API format (node ID -> {class_type, inputs}). REQUIRED for that action.
overridesNoaction:"run_template" — widget overrides keyed '<nodeId>.<widget_name>' (action:"template_schema"'s keys), e.g. {'6.text': 'a red fox', '3.steps': 20}.
prompt_idNoaction:"rerun" — prompt ID of the generation to re-run. If omitted, uses the most recent execution.
timeout_sNoaction:"run_template" — max seconds to wait when wait:true (default 300). On timeout the job keeps running; poll queue (action:"status").
disable_random_seedNoIf true, do not randomize seed values — applies to action:"rerun" and action:"run_template" (for action:"rerun", combine with inputs.seed to reproduce exactly). It is a NO-OP for action:"enqueue", whose seeds are always used exactly as supplied (issue #865).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description fully takes on the burden of behavioral disclosure. It covers async behavior ('Returns immediately... does NOT wait for completion'), seed handling ('used EXACTLY as supplied... NOT re-randomized'), SSRF protections ('loopback/private/metadata IPs rejected'), read-only vs. run modes, error responses, and timeout semantics. This is comprehensive transparency beyond what any annotation could succinctly convey.

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?

Though the description is long, it is tightly structured by action with clear headers and uses an introduction sentence that front-loads the primary use. Every sentence either specifies behavior, provides a cross-reference, or clarifies a schema nuance. Given the scale (5 actions, 11 parameters, several security and async details), the length is justified and the structure makes it easily scannable.

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

Completeness5/5

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

Despite lacking an output schema, the description explicitly states return values for each action (e.g., 'prompt_id and queue position', 'new prompt_id and the source prompt_id', 'slots', '{prompt_id}'). It also covers error handling, timeouts, read-only vs. execution modes, and integration with sibling tools, making it highly complete for a complex multi-action tool.

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 schema already describes all 11 parameters with 100% coverage, so the baseline is 3. However, the description adds substantial relationship context: it binds each parameter to specific actions, explains the 'same keys' convention between template_schema and run_template, and clarifies that `disable_random_seed` is a no-op for action:"enqueue" (issue #865). This goes well beyond a mere restatement of schema fields.

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 opens with a clear, specific verb+resource: 'Submit work to the ComfyUI execution queue — the primary way an agent starts a render.' It then enumerates five distinct actions, each with its own purpose, making it unambiguous what the tool does and how it contrasts with the broader toolset. This distinguishes it from sibling tools that handle workflow creation, retrieval, or inspection.

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 is explicit about when to use each action and provides direct alternatives: e.g., 'for a fresh-seed re-run of a past job, use action:"rerun"' and 'To re-run from a registered ASSET instead of history, use generate_image (action:"regenerate").' It also contrasts the full enqueue chain with the one-shot run_template action, offering clear decision guidance. This far exceeds the minimum 'clear context' threshold.

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

Deploy Server

Other Tools