comfy-workflow-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| COMFY_URL | No | ComfyUI base URL, e.g. http://127.0.0.1:8188 | |
| COMFY_USER | No | Basic auth username, used together with COMFY_PASSWORD | |
| COMFY_TOKEN | No | Bearer token for authentication | |
| VAST_API_KEY | No | Instead of COMFY_URL: connect to a running vast.ai instance | |
| COMFY_HEADERS | No | Extra headers as JSON, if your server needs them | |
| COMFY_MAX_WAIT | No | Longest a single call blocks, in seconds (some MCP hosts drop calls after ~30 s) | 25 |
| COMFY_PASSWORD | No | Basic auth password, used together with COMFY_USER | |
| VAST_COMFY_PORT | No | ComfyUI's container port on the instance | 8188 |
| VAST_INSTANCE_ID | No | Which instance (default: the first running one that exposes the port) | |
| COMFY_DOWNLOAD_DIR | No | Where results are saved | ./comfy_outputs |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| server_statusA | ComfyUI server: which server, version, GPU and free VRAM, queue length. |
| list_workflowsC | Names of the workflows saved in the ComfyUI editor (Workflows panel). |
| describe_workflowB | The nodes of a saved workflow and the values you can change: per node its id, title, class and widget inputs. 'image_input' nodes take an image (see run_workflow images), 'output' nodes produce the files, 'rerolls_each_run' seeds get a new random value on each run unless you set them. |
| run_workflowA | Run a saved workflow with your inputs. set: {"<node id|title|class>.": value}, e.g. {"Positive.text": "a cat", "KSampler.seed": 7, "EmptyLatentImage.width": 1024}. images: {"<LoadImage node id|title>": local file path (uploaded) or a file name already on the server}. enable / bypass: node ids or titles to switch on or bypass for this run (e.g. an optional LoRA). wait_seconds: wait up to this long (capped by COMFY_MAX_WAIT) and download results; otherwise poll get_job. |
| judge_imageB | Judge one image with a rubric (path to a rubric JSON file, or the JSON itself) against a description of what it must show. Returns score, pass/fail, the problems found (criteria + focused checks) and the suggested fix. Needs JUDGE_URL and JUDGE_MODEL. |
| run_judgedA | Run a saved workflow under the harness: generate -> judge with the rubric -> fix -> judge ..., keeping the best result. prompt_field: the input that holds the prompt, e.g. "Positive.text"; on a retry the judge's problems are appended to it. description: what the image must show (the judge checks against it). rubric: rubric JSON file path or JSON (see harness.py). Starts in the background and returns a job id at once; poll get_judged(job_id). Needs JUDGE_URL and JUDGE_MODEL. |
| get_judgedA | Status of a run_judged job: running | done | error, the attempt log, and when done the best image, whether it passed, and every attempt's score and problems. |
| get_jobA | Status of a run (queued | running | done | error). When done, output files are downloaded ('saved_to' has the local path, 'url' the public one in HTTP mode) and image results also come back as preview images. wait_seconds waits up to that long (capped by COMFY_MAX_WAIT). |
| upload_imageA | Upload a local image to the server's input folder; returns the name to use in run_workflow images. |
| list_modelsC | Model folders on the server, or the files in one folder (e.g. 'checkpoints', 'loras', 'diffusion_models'). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools have distinct targets, but two clear pairs shade into each other: run_workflow vs run_judged and get_job vs get_judged. The descriptions do explain the pairing (get_job polls run_workflow, get_judged polls run_judged) and judge_image vs run_judged is clarified as single-image judging versus an iterative harness, so a careful agent can pick correctly, but misselection risk remains for an inattentive one.
The dominant pattern is verb_noun (list_workflows, describe_workflow, run_workflow, judge_image, get_job, upload_image, list_models). Deviations are minor: server_status is noun_phrase rather than verb_noun, and run_judged/get_judged use a past-participle object instead of a noun, which slightly muddies the run/poll pairing.
Ten tools sit squarely in the well-scoped range, and each earns its place: discovery (server_status, list_workflows, describe_workflow, list_models), execution (run_workflow, upload_image), polling (get_job), and the judging layer (judge_image, run_judged, get_judged). No obvious filler or redundant tool.
The lifecycle is largely covered: inspect server, discover/describe workflows, upload inputs, run, poll results, and iterate with a judge. The notable gap is queue control — there is no cancel/interrupt for a running job or a way to clear the ComfyUI queue, which agents will need when a run hangs or a seed sweep should stop.