This server acts as an MCP bridge to ComfyUI, enabling AI image generation and manipulation from any MCP-compatible client (Claude Code, Claude Desktop, etc.) using natural language prompts.
Image Generation
generate_image – Generate an image from a text prompt with control over dimensions, steps, CFG, seed, and checkpoint
generate_variations – Produce multiple variations (2–16) of the same prompt by varying the seed
generate_with_workflow – Submit a fully custom ComfyUI node graph (exported via "Save (API Format)") for custom pipelines
generate_with_controlnet – Generate images conditioned on a preprocessed ControlNet image (pose, depth, edges, etc.) with adjustable strength
generate_with_ip_adapter – Use a reference image as a visual/style guide via IP-Adapter with various presets and weight control
Image Editing & Enhancement
refine_image – Run img2img on a source image with a new prompt and adjustable denoise strength
upscale_image – Upscale an image using ESRGAN, SwinIR, or other installed upscaler models
Asset & Model Discovery
list_models – List available checkpoints, LoRAs, samplers, schedulers, and upscalers on the connected ComfyUI instance
list_workflows – List built-in workflow templates (txt2img, img2img, upscale, controlnet, ip_adapter)
upload_image – Upload a reference image to ComfyUI from a URL or base64 data for use in workflows
Workflow Template Registry
save_workflow_template – Save a custom workflow JSON under a named slot for reuse
list_workflow_templates – List all saved templates with descriptions and timestamps
get_workflow_template – Retrieve a saved template's JSON and metadata
delete_workflow_template – Remove a saved template
run_workflow_template – Execute a previously saved workflow template and return image URLs
The server also provides an image proxy endpoint, making ComfyUI-generated image URLs accessible to MCP clients even when ComfyUI is not directly reachable. Both streamable HTTP and stdio transports are supported.
Supports running the MCP server in a Docker container, enabling easy deployment and isolation of the image generation service alongside ComfyUI instances.
Hosts the project repository and provides access to the MCP server source code, documentation, and issue tracking for development and community contributions.
Accepts financial support for ongoing development, maintenance, and future enhancements of the ComfyUI MCP server through GitHub's sponsorship platform.
Accepts financial support for ongoing development, maintenance, and future enhancements of the ComfyUI MCP server through Ko-fi donations.
Provides package distribution and installation of the MCP server through npm registry, enabling easy installation and updates via npm or npx.
MCP server for ComfyUI. Generate images from natural language prompts in any MCP-compatible client.
v0.2 ships the core tools plus upscale, an image proxy, and public-URL support. Current tool surface: generate_image, generate_variations, generate_with_workflow, refine_image, upscale_image, list_models, list_workflows, upload_image, generate_with_controlnet, generate_with_ip_adapter, plus a workflow template registry. See Roadmap for what's next.
Related MCP server: ComfyUI MCP
npx @miller-joe/comfyui-mcp --comfyui-url http://your-comfyui-host:8188npm install -g @miller-joe/comfyui-mcp
comfyui-mcp --comfyui-url http://your-comfyui-host:8188docker run -p 9100:9100 \
-e COMFYUI_URL=http://your-comfyui-host:8188 \
ghcr.io/miller-joe/comfyui-mcp:latestClaude Code:
claude mcp add --transport http comfyui http://localhost:9100/mcpOr register the streamable HTTP endpoint with an MCP gateway (e.g. MetaMCP) to aggregate with other servers.
All options can be set via CLI flag or environment variable:
CLI flag | Env var | Default | Description |
|
|
| Bind host (HTTP mode only) |
|
|
| Bind port (HTTP mode only) |
|
| (unset) | Speak MCP over stdio instead of HTTP. Use when launched as a subprocess by a stdio-first MCP client (Claude Desktop, mcp-inspector). |
|
|
| ComfyUI HTTP URL used internally by this server |
|
| same as | External URL in image URLs returned to clients. Set this when the internal URL is not reachable from MCP clients (common with Docker networks). |
(no flag) |
|
| Default checkpoint filename |
The server speaks streamable HTTP by default (great for Claude Code, MetaMCP, raw fetch). Pass --stdio (or set MCP_TRANSPORT=stdio) to switch into stdio mode, which is what stdio-first clients like Claude Desktop and the MCP Inspector expect:
# Claude Desktop config (claude_desktop_config.json):
{
"mcpServers": {
"comfyui": {
"command": "npx",
"args": ["-y", "@miller-joe/comfyui-mcp", "--stdio", "--comfyui-url", "http://127.0.0.1:8188"]
}
}
}Generation tools return image URLs like <comfyui-public-url>/view?filename=…. If --comfyui-public-url is not set, URLs use the internal --comfyui-url value.
The server also exposes a proxy endpoint: GET /images/<filename>?subfolder=&type=output streams the image bytes through this server, which is useful when clients can reach the MCP server but not ComfyUI directly.
The default checkpoint must match a file in your ComfyUI models/checkpoints/ directory. Override via COMFYUI_DEFAULT_CKPT or pass checkpoint as a tool argument.
generate_imageGenerate an image from a text prompt using ComfyUI's default txt2img workflow.
Parameters: prompt (required), negative_prompt, width, height, steps, cfg, seed, checkpoint.
generate_variationsGenerate multiple variations of the same prompt by varying the seed. Returns all images at once.
Parameters: prompt (required), count (2–16, default 4), plus the same generation params as generate_image, with base_seed instead of seed.
generate_with_workflowSubmit an arbitrary ComfyUI workflow JSON (full node graph) and return the resulting image URLs. Use this for custom workflows — ControlNet, upscaling, or anything exported from ComfyUI's Save (API Format).
Parameter: workflow (object), the complete node graph.
refine_imageRun img2img on a source image. The server fetches a source URL, uploads it to ComfyUI, and runs a denoising pass guided by a new prompt. Lower denoise preserves more of the original; higher gives the prompt more freedom.
Parameters: prompt, source_image_url (required), denoise (0–1, default 0.5), plus standard generation params.
list_modelsList available checkpoints, LoRAs, samplers, or schedulers on the ComfyUI instance.
Parameter: kind, one of checkpoints (default), loras, samplers, schedulers.
list_workflowsList built-in workflow templates shipped with this server (currently txt2img, img2img, upscale, controlnet, ip_adapter).
upload_imageUpload a reference image to ComfyUI for use in img2img, ControlNet, or IP-Adapter workflows.
Parameters: source_url or image_base64 (one required), filename (optional), overwrite (default false).
Returns: the stored filename, which can be used as the image input in workflow nodes like LoadImage.
generate_with_controlnetGenerate an image conditioned by a ControlNet preprocessed image (pose skeleton, depth map, canny edges, normal map, etc.) plus a text prompt.
Parameters: prompt, control_image_url (the preprocessed conditioning image; this tool doesn't run preprocessors), controlnet_model (filename from models/controlnet/), strength (0–2, default 1), start_percent / end_percent (0–1, controlling when CN is active during sampling), plus standard generation params.
Requires a ControlNet model installed in your ComfyUI models/controlnet/ directory.
generate_with_ip_adapterGenerate an image using a reference image as a visual/style/subject guide via IP-Adapter.
Parameters: prompt, reference_image_url, preset (e.g. "STANDARD (medium strength)", "PLUS FACE (portraits)", "VIT-G (medium strength)"), weight (0–3, default 1), start_at / end_at (0–1), plus standard generation params.
Requires the ComfyUI-IPAdapter-plus custom node pack plus the preset's matching IPAdapter weights and CLIP Vision models.
Save complex workflow JSON once, run by name later. Templates are stored on disk under --templates-dir (defaults to ~/.config/comfyui-mcp/templates/<name>.json) so they survive restarts and are portable across MCP clients.
Tool | Description |
| Save a workflow JSON under a named slot. |
| List saved templates with descriptions and last-updated timestamp. |
| Fetch a stored template's JSON plus metadata. |
| Delete a stored template. |
| Run a saved template against ComfyUI and return image URLs. |
Template names must start alphanumeric. Allowed: a-z, A-Z, 0-9, -, _. Max 64 chars.
All generation tools return image URLs served directly by the ComfyUI instance (http://<comfyui>/view?filename=…). These URLs can be passed straight to any client that accepts image URLs.
┌────────────────┐ ┌──────────────────┐ ┌──────────────┐
│ MCP client │────▶│ comfyui-mcp │────▶│ ComfyUI │
│ (Claude, etc.)│◀────│ (this server) │◀────│ instance │
└────────────────┘ └──────────────────┘ └──────────────┘
streamable HTTP HTTP REST + pollThe server is stateless. A single MCP request submits a workflow to ComfyUI, polls /history/{id} until complete, and returns image URLs.
git clone https://github.com/miller-joe/comfyui-mcp
cd comfyui-mcp
npm install
npm run dev # hot-reload via tsx watch
npm run build # compile TS to dist/
npm run typecheck # strict type checkingRequires Node 20+.
Shipped in v0.2:
generate_image, generate_variations, generate_with_workflow
refine_image (img2img from a source URL)
upscale_image (ESRGAN / SwinIR-style model upscale)
list_models, list_workflows, upload_image
Image proxy endpoint (/images/<filename>) for clients that can't reach ComfyUI directly
Configurable public URL for externally-correct image URLs
Workflow template registry (save/list/get/delete/run)
generate_with_controlnet (requires ControlNet models on the ComfyUI side)
generate_with_ip_adapter (requires ComfyUI-IPAdapter-plus pack)
Planned:
WebSocket progress events for long-running generations.
MIT © Joe Miller
If this tool saves you time, consider supporting development:
Every contribution funds maintenance, documentation, and the next release.
Delete a saved workflow template.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Template name to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It implies a destructive operation ('Delete') but does not mention permissions, cascading effects, or confirm irreversibility. The minimal description is insufficient for an AI to understand side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no redundant information. Every word serves a purpose, making it highly concise and efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is mostly adequate. However, it could mention that the action is irreversible, which would improve completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'name' is described clearly in the schema as 'Template name to delete.' The tool description adds no additional meaning beyond the schema, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete' and the resource 'saved workflow template'. It differentiates from sibling tools like save, get, list, and run, but does not specify the deletion is by name or any unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites (e.g., template must exist), or that deletion is irreversible. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image from a text prompt using ComfyUI's default txt2img workflow. Returns one or more image URLs served directly by the ComfyUI instance.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Text prompt describing the image to generate | |
| negative_prompt | No | What to avoid in the image | |
| width | No | Image width in pixels | |
| height | No | Image height in pixels | |
| steps | No | Number of diffusion steps | |
| cfg | No | CFG / prompt adherence (1-30) | |
| seed | No | Seed for reproducibility | |
| checkpoint | No | Checkpoint filename (defaults to COMFYUI_DEFAULT_CKPT) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should fully explain behavioral traits. However, it only states that the tool returns image URLs and uses ComfyUI. It does not disclose resource usage, persistence, idempotency, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with no wasted words. However, it could be more structured (e.g., separating input, output, and usage).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is insufficiently complete. It lacks details on image URL format, handling of multiple images, and potential failures, which are important for a tool with 8 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters have descriptions in the input schema (100% coverage), so the description does not need to add much. It does not provide extra context beyond what the schema already gives, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('generate'), the input (text prompt), the method (ComfyUI default txt2img workflow), and the output (image URLs). It also distinguishes itself from sibling tools like 'generate_variations' or 'generate_with_controlnet' by specifying the default workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It mentions the default workflow, implying it's for basic text-to-image, but does not list alternatives or conditions for other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate multiple variations of the same prompt by varying the seed. Useful for picking the best result or exploring a concept.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Text prompt for the base image | |
| count | No | Number of variations to generate | |
| negative_prompt | No | ||
| width | No | ||
| height | No | ||
| steps | No | ||
| cfg | No | ||
| base_seed | No | Starting seed; subsequent variations use base_seed + i | |
| checkpoint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only mentions seed variation, omitting details like whether it uses the same model, order of returns, or any rate limits. For a generative tool with no output schema, more clarity is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences with no wasted words. It is front-loaded with the core action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, no annotations), the description is too minimal. It explains the main purpose but lacks details on parameter usage, expected return values, and when alternatives are preferable. Significant gaps remain for an agent to use it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (3 of 9 parameters described). The description adds context for seed-related parameters (base_seed, count) but does not explain others like negative_prompt, width, height, steps, cfg, or checkpoint. Since coverage is low, the description should compensate but fails to do so for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool generates multiple variations of a prompt by varying the seed. It differentiates from siblings like 'generate_image' which produces a single image, and 'generate_with_controlnet' which uses control conditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description notes usefulness for 'picking the best result or exploring a concept', providing some guidance. However, it does not explicitly state when not to use this tool versus alternatives like 'generate_image' or 'generate_with_workflow', leaving ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image conditioned by a ControlNet preprocessed image (pose, depth, canny, etc.) plus a prompt. Requires a ControlNet model installed in ComfyUI's models/controlnet/ directory. The control_image_url must already be the preprocessed conditioning image — this tool does not run preprocessors itself.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Text prompt for the generated image. | |
| negative_prompt | No | ||
| control_image_url | Yes | URL of the conditioning image (pose skeleton, depth map, canny edges, normal map, etc.). Must already match the control type — ControlNet expects preprocessed input. | |
| controlnet_model | Yes | ControlNet model filename from your ComfyUI `models/controlnet/` directory. Examples: 'control_v11p_sd15_openpose.safetensors', 'control_v11f1p_sd15_depth.safetensors', 'control_v11p_sd15_canny.safetensors', 'controlnet-union-sdxl-1.0.safetensors'. | |
| strength | No | How strongly ControlNet influences generation. 1.0 = full. | |
| start_percent | No | Fraction of the sampling timeline at which ControlNet starts. | |
| end_percent | No | Fraction of the sampling timeline at which ControlNet stops. | |
| width | No | ||
| height | No | ||
| steps | No | ||
| cfg | No | ||
| seed | No | ||
| checkpoint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool does not run preprocessors and requires model installation. With no annotations, it misses details about side effects, auth requirements, or output format, but adds key operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three concise sentences, each adding unique value: purpose, prerequisite, and input constraint. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters and no output schema, the description explains core functionality but omits details about many parameters and what the tool returns (e.g., image URL). More completeness could be provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 46%, and the description adds examples for controlnet_model and clarifies control_image_url expects preprocessed input. However, many parameters (negative_prompt, width, height, steps, etc.) remain unexplained beyond basic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an image conditioned on ControlNet preprocessed images, specifying types like pose, depth, canny. It distinguishes from siblings like generate_image and generate_with_ip_adapter through the mention of ControlNet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions prerequisite of a ControlNet model in a specific directory and warns that the input image must already be preprocessed. Does not contrast with alternatives but provides clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image using a reference image as an IP-Adapter visual/style/subject guide. Requires the ComfyUI-IPAdapter-plus custom node pack and the preset's matching models (IPAdapter weights + CLIP vision). Weight tunes how strongly the reference guides generation.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Text prompt for the generated image. | |
| negative_prompt | No | ||
| reference_image_url | Yes | URL of the reference image that IP-Adapter uses as a visual/style/subject guide. | |
| preset | No | IP-Adapter preset (picks the matching IPAdapter + CLIP Vision models). Common values: LIGHT - SD1.5 only (low strength) | STANDARD (medium strength) | VIT-G (medium strength) | PLUS (high strength) | PLUS FACE (portraits) | FULL FACE - SD1.5 only (portraits stronger) | STANDARD (medium strength) |
| weight | No | How strongly the reference guides the output. | |
| start_at | No | ||
| end_at | No | ||
| width | No | ||
| height | No | ||
| steps | No | ||
| cfg | No | ||
| seed | No | ||
| checkpoint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that 'Weight tunes how strongly the reference guides generation' but fails to disclose other behavioral traits such as error handling, authentication needs, or potential destructive actions. For a complex tool with 13 parameters, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three sentences, each adding value: purpose, prerequisites, and weight guidance. It is front-loaded with the main purpose. Could be slightly more structured, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the return format, error conditions, or the behavior of many parameters. The tool is complex, and the description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 31%. The description adds context for weight and lists preset values, but many parameters (e.g., negative_prompt, start_at, end_at, steps, cfg, seed, checkpoint) are left unexplained in both schema and description. The description does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate an image using a reference image as an IP-Adapter visual/style/subject guide.' The verb 'generate' and resource 'image' are specific, and the inclusion of 'IP-Adapter' distinguishes it from sibling tools like generate_with_controlnet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites: 'Requires the ComfyUI-IPAdapter-plus custom node pack and the preset's matching models.' This helps the agent know if the tool is usable. However, it does not explicitly state when not to use this tool or recommend alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit an arbitrary ComfyUI workflow (full node graph) and return the resulting image URLs. Use this when you need a custom workflow like ControlNet, upscaling, or a node graph exported from ComfyUI's 'Save (API Format)'.
| Name | Required | Description | Default |
|---|---|---|---|
| workflow | Yes | Complete ComfyUI workflow JSON (node graph as returned by ComfyUI's 'Save (API Format)' export) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns image URLs but omits details on whether the workflow runs synchronously or side effects. The description adds context beyond the schema but lacks comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a usage note. It is front-loaded with the core purpose and includes a concrete example. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one complex parameter and no output schema, the description adequately explains the input format and use cases. It does not detail the return structure, but the context signals (no output schema) mitigate this. The sibling differentiation helps contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described. The description adds meaning by specifying the workflow JSON should be in ComfyUI's 'Save (API Format)' export format, which is not evident from the schema alone. This helps the agent construct correct input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool submits an arbitrary ComfyUI workflow and returns image URLs. It specifies the resource (ComfyUI workflow) and verb (submit), and distinguishes from siblings like run_workflow_template by focusing on custom workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when you need a custom workflow like ControlNet, upscaling' providing clear context. It indirectly implies alternatives (e.g., saved templates via sibling run_workflow_template) but does not directly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a saved workflow template's JSON and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Template name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description mentions it fetches data but does not disclose any behavioral traits like authentication, error handling, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that immediately conveys the tool's purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While minimal and functional, the description lacks details on error handling, return format specifics, or how it differs from list_workflow_templates, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with a description for the only parameter. The description adds no extra meaning beyond the schema, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'fetch', the resource 'saved workflow template', and the outputs 'JSON and metadata', distinguishing it from siblings like list_workflow_templates and run_workflow_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as list_workflow_templates or run_workflow_template. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available models or samplers on the ComfyUI instance. Use this to discover valid values for the 'checkpoint' parameter of other tools, or to see what LoRAs and samplers are installed.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Which category of resource to list | checkpoints |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes the action as listing, implying a read operation, but does not explicitly state that it is non-destructive or has no side effects. It could be more transparent about permissions or rate limits, but the basic behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not mention the return format (e.g., list of names). For a listing tool, this would be helpful. However, the behavior is straightforward, so the lack of output details is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions and enums. The description adds value by explaining the purpose of the 'kind' parameter in discovering valid values for other tools, which goes beyond the schema's enum list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists available models/samplers and explicitly mentions the resources (checkpoints, LoRAs, samplers). It also distinguishes from sibling list tools like list_workflows by specifying its domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context: 'Use this to discover valid values for the ''checkpoint'' parameter of other tools'. This tells the agent when to use it. It does not explicitly mention when not to use or alternatives, but the context is sufficient for a simple listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List built-in workflow templates shipped with this MCP server. These are the named workflows that can be used as a baseline; for arbitrary workflows use generate_with_workflow.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description makes clear it's a read-only listing operation, implying safe behavior. Adds context that these are named baseline workflows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste, front-loaded with key action and resource, then sibling differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no parameters, and simple read operation, description fully covers what the tool does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, schema coverage 100%, but description adds value by specifying the resource type (built-in workflow templates), which is beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List built-in workflow templates' with specific verb and resource, and distinguishes from sibling tool 'generate_with_workflow' for arbitrary workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (list built-in templates) and when not (for arbitrary workflows, use generate_with_workflow), providing clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all saved workflow templates in the registry.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully bears transparency. It states read-only list behavior but omits details like pagination, ordering, or whether it returns full template details or just names. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, directly states purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the agent lacks information about return format. Description is adequate for a simple list tool but could be more helpful by hinting at what properties are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero parameters, so description adds value by clarifying scope ('all saved templates in the registry'). Baseline for 0 params is 4, and the description meets it without redundant info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all saved workflow templates in the registry' uses a specific verb 'list' and resource 'workflow templates', clearly distinguishing it from siblings like get_workflow_template (singular) and list_workflows (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as get_workflow_template for a single template or run_workflow_template for execution. Lacks explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refine an existing image using img2img: fetch the source image, upload it to ComfyUI, and run a denoising pass guided by the prompt. Lower denoise preserves more of the original; higher denoise gives more freedom to the prompt.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Text prompt describing the desired refined image | |
| source_image_url | Yes | URL of the source image to refine. Will be fetched and uploaded to ComfyUI. | |
| denoise | No | How much to change the source image (0 = no change, 1 = fully regenerate). Typical: 0.3-0.7 | |
| negative_prompt | No | ||
| steps | No | ||
| cfg | No | ||
| seed | No | ||
| checkpoint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the internal process (fetch, upload, denoising pass) and denoise semantics, but omits details like authorization needs, rate limits, or whether original image is preserved. Some behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no waste. Key information about tool purpose and denoise behavior is front-loaded. Every sentence adds distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and complex img2img workflow, description lacks explanation of return values, usage of advanced parameters, or comparison with similar sibling tools like generate_variations or generate_with_controlnet. Incomplete for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (38%). Description adds value for denoise parameter with usage guidance, but for 5 other parameters (negative_prompt, steps, cfg, seed, checkpoint) no additional semantic is provided beyond schema. Description does not adequately compensate for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (refine), resource (existing image), and technical method (img2img with denoising). It distinguishes from siblings like generate_image by explicitly noting it modifies an existing image instead of creating from scratch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on denoise parameter (lower preserves original, higher gives freedom) but lacks explicit when-to-use or when-not-to-use compared to sibling tools like generate_variations or generate_with_controlnet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a saved workflow template against ComfyUI and return the resulting image URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Saved template name to run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the tool returns image URLs but does not mention potential side effects (e.g., resource consumption, temporary storage, or error handling). For a tool that executes a workflow, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the core action and output. It is front-loaded and to the point, but could benefit from additional context (e.g., error conditions) without becoming overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description provides the basic function and output. However, it lacks information about prerequisites (e.g., template existence), error handling, or performance considerations, leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the sole parameter 'name' as 'Saved template name to run.' The tool description adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (run), the specific resource (saved workflow template), the target system (ComfyUI), and the output (image URLs). This distinguishes it from sibling tools like 'generate_image' (standalone generation) and 'generate_with_workflow' (generic workflow).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when you have a saved template to run. However, it does not explicitly state when not to use this tool nor mentions alternatives like 'generate_with_workflow' for non-template workflows. The purpose is clear, but usage boundaries are only implicitly suggested.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a ComfyUI workflow JSON to the server's template registry under a named slot. Overwrites are disabled by default.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Template name. Letters, digits, '-', '_'; max 64 chars. Must start alphanumeric. | |
| workflow | Yes | Complete ComfyUI workflow JSON (from ComfyUI's 'Save (API Format)'). | |
| description | No | ||
| overwrite | No | Allow overwriting an existing template with the same name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It indicates overwrite behavior and that the operation is a save (mutation). But it lacks details on validation, error handling, or permission requirements, which are important for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one clear sentence and a short statement about overwrites. Every word adds value without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (4 params, no enums, no output schema), the description covers the essential purpose and a key behavioral trait. Missing return value info, but for a save operation it's acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% and the schema already documents parameters with descriptions. The description adds minimal extra meaning ('workflow JSON', 'named slot'). Baseline score is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (save), the resource (ComfyUI workflow JSON to template registry), and the slot mechanism. It distinguishes from sibling tools like delete and get by specifying 'save' and 'template registry'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that overwrites are disabled by default, providing some usage guidance. However, it does not explicitly state when to use this tool versus alternatives (e.g., run_workflow_template for execution) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a reference image to ComfyUI for use in img2img, ControlNet, or IP-Adapter workflows. Accepts either a source URL (will be fetched) or base64-encoded image data. Returns the stored filename for use as 'image' in workflow nodes like LoadImage.
| Name | Required | Description | Default |
|---|---|---|---|
| source_url | No | URL to fetch the image from. One of source_url or image_base64 is required. | |
| image_base64 | No | Base64-encoded image data (without the data:image/... prefix). One of source_url or image_base64 is required. | |
| filename | No | Filename to save as on the ComfyUI side. Defaults to a timestamped name. | |
| overwrite | No | Replace an existing file with the same name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description adds that URL is fetched and output filename is for workflow nodes. Lacks details on limits, supported formats, or side effects beyond overwrite param.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficient, no redundancy, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, description adequately covers purpose, input options, and output use. Missing error cases or format constraints, but still sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100%; description adds mutual exclusivity of source_url and image_base64, fetch behavior, and output usage context beyond schema basics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'upload' with specific resource 'reference image to ComfyUI' and explicit use cases (img2img, ControlNet, IP-Adapter). Distinguishes from sibling generation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies two input methods and purpose, but no explicit when-to-use vs alternatives. Context is clear enough for an upload tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upscale an image using a loaded upscaler model (ESRGAN, SwinIR, etc.). Fetches the source image, uploads to ComfyUI, runs the upscale node, and returns the output URL. Requires at least one upscaler model in ComfyUI's models/upscale_models/ directory.
| Name | Required | Description | Default |
|---|---|---|---|
| source_image_url | Yes | URL of the image to upscale. Will be fetched and uploaded to ComfyUI. | |
| upscale_model | Yes | Upscaler model filename (e.g. RealESRGAN_x4plus.pth). Use list_models with kind=upscalers to see what's installed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the steps (fetch, upload, run node, return URL) and a requirement. However, it lacks details on error handling, synchronicity, or side effects, which is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded purpose, no redundant words. Every part is informative and necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers the main process and prerequisite. It could mention output format or error cases, but is mostly complete for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds value beyond schema by explaining the model directory and suggesting list_models, enhancing usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (upscale an image) and the resource (loaded upscaler model), with examples (ESRGAN, SwinIR). It distinguishes from siblings by specifying the mechanism and prerequisites, unlike refine_image or generate_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (upscaling with a loaded model) and provides a prerequisite (model must be in directory). It does not explicitly exclude alternatives or compare to siblings, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0delete_workflow_templategenerate_imagegenerate_variationsgenerate_with_controlnetgenerate_with_ip_adaptergenerate_with_workflowget_workflow_templatelist_modelslist_workflow_templateslist_workflowsrefine_imagerun_workflow_templatesave_workflow_templateupload_imageupscale_imageScored across 15 tools
Each tool has a clearly distinct purpose: generation methods (standard, variations, ControlNet, IP-Adapter, custom workflow), image manipulation (refine, upscale), workflow management (list, get, save, delete, run templates), and utilities (upload_image, list_models). No overlap in functionality.
All tools follow a consistent verb_noun pattern in snake_case (e.g., generate_image, list_models, save_workflow_template). No mixing of styles or ambiguous verbs.
15 tools cover the core capabilities of a ComfyUI integration (generation, conditioning, upscaling, workflow templates, and utilities) without being excessive. Each tool earns its place for a comprehensive image generation server.
The tool surface covers major workflows: txt2img, img2img, ControlNet, IP-Adapter, upscaling, and custom workflows via templates. Minor gaps like explicit inpainting/outpainting tools exist, but these can be handled through custom workflows.
MCP server for Qwen Image 3 AI image generation
Remote MCP for RunComfy: ComfyUI deployments, hosted models, LoRA training. 31 tools.
MCP server for Flux AI image generation
MCP server for Wan AI video generation
