Servidor MCP para ComfyUI. Genera imágenes a partir de prompts en lenguaje natural en cualquier cliente compatible con MCP.
La versión v0.2 incluye las herramientas principales, además de escalado, un proxy de imágenes y soporte para URL públicas. Superficie de herramientas actual: generate_image, generate_variations, generate_with_workflow, refine_image, upscale_image, list_models, list_workflows, upload_image, generate_with_controlnet, generate_with_ip_adapter, además de un registro de plantillas de flujo de trabajo. Consulta la hoja de ruta para ver qué sigue.
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/mcpO registra el endpoint HTTP transmitible con una pasarela MCP (por ejemplo, MetaMCP) para agregar con otros servidores.
Todas las opciones se pueden establecer mediante indicadores de CLI o variables de entorno:
Indicador CLI | Variable de entorno | Predeterminado | Descripción |
|
|
| Host de enlace (solo modo HTTP) |
|
|
| Puerto de enlace (solo modo HTTP) |
|
| (sin establecer) | Habla MCP a través de stdio en lugar de HTTP. Úsalo cuando se inicie como un subproceso por un cliente MCP que priorice stdio (Claude Desktop, mcp-inspector). |
|
|
| URL HTTP de ComfyUI utilizada internamente por este servidor |
|
| igual que | URL externa en las URL de imagen devueltas a los clientes. Configúralo cuando la URL interna no sea accesible desde los clientes MCP (común con redes Docker). |
(sin indicador) |
|
| Nombre de archivo del checkpoint predeterminado |
El servidor utiliza HTTP transmitible de forma predeterminada (ideal para Claude Code, MetaMCP, fetch sin procesar). Pasa --stdio (o establece MCP_TRANSPORT=stdio) para cambiar al modo stdio, que es lo que esperan los clientes que priorizan stdio como Claude Desktop y el Inspector MCP:
# 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"]
}
}
}Las herramientas de generación devuelven URL de imágenes como <comfyui-public-url>/view?filename=…. Si no se establece --comfyui-public-url, las URL utilizan el valor interno de --comfyui-url.
El servidor también expone un endpoint de proxy: GET /images/<filename>?subfolder=&type=output transmite los bytes de la imagen a través de este servidor, lo cual es útil cuando los clientes pueden acceder al servidor MCP pero no directamente a ComfyUI.
El checkpoint predeterminado debe coincidir con un archivo en tu directorio models/checkpoints/ de ComfyUI. Sobrescríbelo mediante COMFYUI_DEFAULT_CKPT o pasa checkpoint como argumento de la herramienta.
generate_imageGenera una imagen a partir de un prompt de texto utilizando el flujo de trabajo txt2img predeterminado de ComfyUI.
Parámetros: prompt (obligatorio), negative_prompt, width, height, steps, cfg, seed, checkpoint.
generate_variationsGenera múltiples variaciones del mismo prompt variando la semilla. Devuelve todas las imágenes a la vez.
Parámetros: prompt (obligatorio), count (2–16, predeterminado 4), además de los mismos parámetros de generación que generate_image, con base_seed en lugar de seed.
generate_with_workflowEnvía un JSON de flujo de trabajo de ComfyUI arbitrario (grafo de nodos completo) y devuelve las URL de las imágenes resultantes. Úsalo para flujos de trabajo personalizados: ControlNet, escalado o cualquier cosa exportada desde Save (API Format) de ComfyUI.
Parámetro: workflow (objeto), el grafo de nodos completo.
refine_imageEjecuta img2img en una imagen de origen. El servidor obtiene una URL de origen, la sube a ComfyUI y ejecuta una pasada de eliminación de ruido guiada por un nuevo prompt. Un denoise más bajo conserva más del original; uno más alto le da al prompt más libertad.
Parámetros: prompt, source_image_url (obligatorio), denoise (0–1, predeterminado 0.5), además de los parámetros de generación estándar.
list_modelsEnumera los checkpoints, LoRAs, samplers o schedulers disponibles en la instancia de ComfyUI.
Parámetro: kind, uno de checkpoints (predeterminado), loras, samplers, schedulers.
list_workflowsEnumera las plantillas de flujo de trabajo integradas que se incluyen con este servidor (actualmente txt2img, img2img, upscale, controlnet, ip_adapter).
upload_imageSube una imagen de referencia a ComfyUI para usarla en flujos de trabajo img2img, ControlNet o IP-Adapter.
Parámetros: source_url o image_base64 (uno obligatorio), filename (opcional), overwrite (predeterminado falso).
Devuelve: el nombre de archivo almacenado, que se puede usar como entrada image en nodos de flujo de trabajo como LoadImage.
generate_with_controlnetGenera una imagen condicionada por una imagen preprocesada de ControlNet (esqueleto de pose, mapa de profundidad, bordes canny, mapa normal, etc.) más un prompt de texto.
Parámetros: prompt, control_image_url (la imagen de condicionamiento preprocesada; esta herramienta no ejecuta preprocesadores), controlnet_model (nombre de archivo de models/controlnet/), strength (0–2, predeterminado 1), start_percent / end_percent (0–1, controlando cuándo está activo CN durante el muestreo), además de los parámetros de generación estándar.
Requiere un modelo ControlNet instalado en tu directorio models/controlnet/ de ComfyUI.
generate_with_ip_adapterGenera una imagen utilizando una imagen de referencia como guía visual/estilo/sujeto a través de IP-Adapter.
Parámetros: prompt, reference_image_url, preset (por ejemplo, "STANDARD (medium strength)", "PLUS FACE (portraits)", "VIT-G (medium strength)"), weight (0–3, predeterminado 1), start_at / end_at (0–1), además de los parámetros de generación estándar.
Requiere el paquete de nodos personalizados ComfyUI-IPAdapter-plus además de los pesos de IPAdapter y los modelos CLIP Vision que coincidan con el preset.
Guarda JSON de flujos de trabajo complejos una vez y ejecútalos por nombre más tarde. Las plantillas se almacenan en el disco bajo --templates-dir (predeterminado ~/.config/comfyui-mcp/templates/<name>.json) para que sobrevivan a los reinicios y sean portátiles entre clientes MCP.
Herramienta | Descripción |
| Guarda un JSON de flujo de trabajo en una ranura con nombre. |
| Enumera las plantillas guardadas con descripciones y marca de tiempo de la última actualización. |
| Obtiene el JSON de una plantilla almacenada más los metadatos. |
| Elimina una plantilla almacenada. |
| Ejecuta una plantilla guardada en ComfyUI y devuelve las URL de las imágenes. |
Los nombres de las plantillas deben comenzar con caracteres alfanuméricos. Permitidos: a-z, A-Z, 0-9, -, _. Máximo 64 caracteres.
Todas las herramientas de generación devuelven URL de imágenes servidas directamente por la instancia de ComfyUI (http://<comfyui>/view?filename=…). Estas URL se pueden pasar directamente a cualquier cliente que acepte URL de imágenes.
┌────────────────┐ ┌──────────────────┐ ┌──────────────┐
│ MCP client │────▶│ comfyui-mcp │────▶│ ComfyUI │
│ (Claude, etc.)│◀────│ (this server) │◀────│ instance │
└────────────────┘ └──────────────────┘ └──────────────┘
streamable HTTP HTTP REST + pollEl servidor no tiene estado. Una única solicitud MCP envía un flujo de trabajo a ComfyUI, sondea /history/{id} hasta que se completa y devuelve las URL de las imágenes.
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 checkingRequiere Node 20+.
Incluido en v0.2:
generate_image, generate_variations, generate_with_workflow
refine_image (img2img desde una URL de origen)
upscale_image (escalado de modelo estilo ESRGAN / SwinIR)
list_models, list_workflows, upload_image
Endpoint de proxy de imagen (/images/<filename>) para clientes que no pueden acceder directamente a ComfyUI
URL pública configurable para URL de imágenes externamente correctas
Registro de plantillas de flujo de trabajo (guardar/listar/obtener/eliminar/ejecutar)
generate_with_controlnet (requiere modelos ControlNet en el lado de ComfyUI)
generate_with_ip_adapter (requiere el paquete ComfyUI-IPAdapter-plus)
Planeado:
Eventos de progreso de WebSocket para generaciones de larga duración.
MIT © Joe Miller
Si esta herramienta te ahorra tiempo, considera apoyar el desarrollo:
Cada contribución financia el mantenimiento, la documentación y la próxima versión.
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
