en es ja ko zh

ComfyUI MCP Server

Name: ComfyUI MCP Server
Author: Overseer66

by Overseer66

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Servidor MCP ComfyUI

1. Descripción general

Una implementación de servidor para integrar ComfyUI con MCP.
⚠️ IMPORTANTE: Este servidor requiere un servidor ComfyUI en ejecución.
- Debes alojar tu propio servidor ComfyUI,
- o tener acceso a una dirección de servidor ComfyUI existente.

Related MCP server: ComfyUI MCP

2. Depuración

2.1 Depuración de ComfyUI

python src/test_comfyui.py

2.2 Depuración de MCP

mcp dev src/server.py

3. Instalación y configuración

3.1 Configuración de ComfyUI

Edite src/.env para configurar el host y el puerto de ComfyUI:
```
COMFYUI_HOST=localhost
COMFYUI_PORT=8188
```

3.2 Agregar flujos de trabajo personalizados

Para agregar nuevas herramientas, coloque los archivos JSON de su flujo de trabajo en el directorio de workflows y declárelos como nuevas herramientas en el sistema.

4. Herramientas integradas

texto a imagen
- Devuelve solo la URL de la imagen generada.
- Para obtener la imagen real:
  - Utilice la herramienta download_image , o
  - Accede a la URL directamente en tu navegador.
descargar imagen
- Descarga imágenes generadas por otras herramientas (como text_to_image ) utilizando la URL de la imagen.
ejecutar_flujo_de_trabajo_con_archivo
- Ejecute un flujo de trabajo proporcionando la ruta a un archivo JSON de flujo de trabajo.
  # You should ask to agent like this. Run comfyui workflow with text_to_image.json
- imagen de ejemplo de CursorAI

ejecutar_flujo_de_trabajo_con_json

Ejecute un flujo de trabajo proporcionando los datos JSON del flujo de trabajo directamente.

# You should ask to agent like this.
Run comfyui workflow with this 
{
  "3": {
      "inputs": {
          "seed": 156680208700286,
          "steps": 20,
    ... (workflow JSON example)
}

5. Cómo correr

5.1 Uso de UV (recomendado)

Ejemplo mcp.json :

{
  "mcpServers": {
    "comfyui": {
      "command": "uv",
      "args": [
        "--directory",
        "PATH/MCP/comfyui",
        "run",
        "--with",
        "mcp",
        "--with",
        "websocket-client",
        "--with",
        "python-dotenv",
        "mcp",
        "run",
        "src/server.py:mcp"
      ]
    }
  }
}

5.2 Uso de Docker

Descargar imágenes a una carpeta local con download_image puede resultar difícil ya que el contenedor Docker no comparte el sistema de archivos del host.
Al utilizar Docker, tenga en cuenta lo siguiente:
1. Establezca RETURN_URL=false en .env para recibir datos de imagen como bytes.
2. Establezca COMFYUI_HOST en .env en la dirección adecuada (por ejemplo, host.docker.internal o la IP de su servidor).
3. Nota: Las cargas útiles de imágenes grandes pueden exceder los límites de respuesta cuando se utilizan datos binarios.

5.2.1 Crear imagen de Docker

# First build image
docker image build -t mcp/comfyui .

{
  "mcpServers": {
    "comfyui": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-p",
        "3001:3000",
        "mcp/comfyui"
      ]
    }
  }
}

5.2.2 Uso de imágenes existentes

También puedes utilizar imágenes prediseñadas.

{
  "mcpServers": {
    "comfyui": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-p",
        "3001:3000",
        "overseer66/mcp-comfyui"
      ]
    }
  }
}

5.2.3 Uso del transporte SSE

Ejecute el servidor SSE con Docker:

docker run -i --rm -p 8001:8000 overseer66/mcp-comfyui-sse

Configure mcp.json (cambie localhost a su IP o dominio si es necesario):

{
  "mcpServers": {
    "comfyui": {
      "url": "http://localhost:8001/sse" 
    }
  }
}

NOTA: Al agregar nuevos flujos de trabajo como herramientas, debe reconstruir y volver a implementar las imágenes de Docker para que estén disponibles.

Available Tools

4 tools

download_imageA

Download an image from a URL and save it to a file.

Args:
    url: The URL of the image to download.
    save_path: The absolute path to save the image to. Must be an absolute path, otherwise the image will be saved relative to the server location.

Name	Required	Description	Default
`url`	Yes
`save_path`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the save_path must be absolute, adding useful context about file handling. However, it lacks details on error handling, network behavior, file overwrites, or response format, leaving gaps in behavioral understanding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by parameter details in a structured 'Args' section. Every sentence adds value without redundancy, making it efficient and well-organized for quick comprehension.

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

Completeness3/5

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

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description covers the basic operation and parameters adequately. However, it lacks information on return values, error cases, or performance aspects, making it incomplete for full contextual understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides clear semantics for both parameters: 'url' as the source and 'save_path' as the destination with a constraint about absolute paths. This adds meaningful context beyond the bare schema, though it could specify URL formats or path examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('download an image from a URL') and the outcome ('save it to a file'), using precise verbs and specifying the resource. It distinguishes itself from sibling tools like text_to_image (which generates rather than downloads) and workflow tools, making the purpose unambiguous.

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

Usage Guidelines3/5

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

The description implies usage when needing to download an image from a URL to a file, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. No guidance is given on prerequisites or error conditions, leaving usage context partially inferred.

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

run_workflow_from_fileC

Run a workflow from a file.

Args:
    file_path: The absolute path to the file to run.

Name	Required	Description	Default
`file_path`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Run') but doesn't describe what 'running a workflow' entails—whether it's a read-only operation, has side effects, requires specific permissions, or what happens upon execution. This leaves critical behavioral traits unspecified for a tool that likely performs significant operations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, with the main purpose stated first and parameter details following. It avoids unnecessary elaboration, though the parameter explanation could be more integrated. The structure is efficient, but the lack of usage context slightly reduces its effectiveness.

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

Completeness2/5

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

Given the complexity of running a workflow (likely involving execution, side effects, or outputs), the description is incomplete. With no annotations, no output schema, and minimal parameter details, it fails to provide sufficient context for safe and effective use. The agent lacks information on what 'running' entails, expected results, or error conditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds minimal semantics beyond the input schema. It explains that 'file_path' is 'The absolute path to the file to run,' which clarifies the parameter's purpose slightly, but with 0% schema description coverage and only one parameter, this is a baseline case. The description doesn't elaborate on file format requirements or path validation, leaving gaps in parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Run a workflow') and the resource ('from a file'), making the purpose understandable. It distinguishes from 'run_workflow_from_json' by specifying the source as a file rather than JSON input, but doesn't explicitly differentiate from other siblings like 'download_image' or 'text_to_image' in terms of workflow execution context.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'run_workflow_from_file' over 'run_workflow_from_json', nor does it explain prerequisites like file format or workflow compatibility. Usage is implied by the name but not explicitly stated.

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

run_workflow_from_jsonC

Run a workflow from a JSON data.

Args:
    json_data: The JSON data to run.

Name	Required	Description	Default
`json_data`	Yes

TDQS

C2.4/5.0

Behavior2/5

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 only states what the tool does at a surface level without explaining what 'run a workflow' entails - whether it's a read or write operation, what permissions are needed, what happens when executed, or what the expected outcomes are. This leaves significant behavioral questions unanswered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise with two sentences. The first states the purpose, the second documents the single parameter. There's no unnecessary verbiage, though the structure could be improved by front-loading more critical information about workflow behavior.

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

Completeness2/5

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

For a tool that presumably executes workflows (potentially complex operations), with no annotations, no output schema, and minimal parameter documentation, the description is incomplete. It doesn't address what 'running a workflow' means, what types of workflows exist, what happens upon execution, or what results to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. While it mentions 'json_data: The JSON data to run', this adds minimal semantic value beyond the parameter name. It doesn't explain what structure the JSON should have, what fields are expected, or provide any examples of valid JSON data for running workflows.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool 'Run a workflow from a JSON data' which provides a basic verb+resource combination. However, it's vague about what 'workflow' means in this context and doesn't differentiate from sibling tools like 'run_workflow_from_file' which appears to serve a similar purpose with different input format.

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

Usage Guidelines2/5

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

No guidance is provided about when to use this tool versus alternatives. The existence of 'run_workflow_from_file' suggests there are multiple ways to run workflows, but the description offers no comparison or context about when JSON input is preferred over file input.

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

text_to_imageB

Generate an image from a prompt.

Args:
    prompt: The prompt to generate the image from.
    seed: The seed to use for the image generation.
    steps: The number of steps to use for the image generation.
    cfg: The CFG scale to use for the image generation.
    denoise: The denoise strength to use for the image generation.

Name	Required	Description	Default
`prompt`	Yes
`seed`	Yes
`steps`	Yes
`cfg`	Yes
`denoise`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool generates an image but doesn't describe what happens (e.g., where the image is stored, if it's returned as data or a file, potential rate limits, or error conditions). For a tool with 5 parameters and no annotations, this is a significant gap in behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and concise. It starts with a clear purpose statement, followed by a bullet-point list of parameters with brief explanations. Every sentence earns its place, and there's no wasted text, making it easy to parse.

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

Completeness2/5

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

Given the tool's complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns (e.g., image data, file path, error messages), nor does it provide behavioral details like side effects or constraints. This leaves significant gaps for an AI agent to understand the tool fully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds substantial meaning beyond the input schema, which has 0% description coverage. It lists all 5 parameters with brief explanations (e.g., 'The prompt to generate the image from'), providing essential semantic context that the schema lacks. However, it doesn't specify value ranges or units for numeric parameters like 'steps' or 'cfg'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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 from a prompt.' This is a specific verb ('Generate') and resource ('image'), though it doesn't explicitly differentiate from sibling tools like 'download_image' or 'run_workflow_from_file'. The purpose is unambiguous but lacks sibling distinction.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or suggest scenarios where this tool is preferred over others, leaving the agent without context for selection among available options.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesAug 15, 2025
- First observeddownload_image
- First observedrun_workflow_from_file
- First observedrun_workflow_from_json
- First observedtext_to_image

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-04-18 10:20 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: downloading images, running workflows from files, running workflows from JSON, and generating images from text. There is no overlap in functionality, making it easy for an agent to select the correct tool for any given task without confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (e.g., download_image, run_workflow_from_file, run_workflow_from_json, text_to_image). This predictable naming scheme enhances readability and usability for agents.

Tool Count4/5

With 4 tools, the server is well-scoped for basic ComfyUI operations, covering key areas like image handling and workflow execution. However, it might feel slightly thin for advanced use cases, such as missing tools for managing workflows or querying server status, but it remains reasonable for its purpose.

Completeness3/5

The tools cover core functionalities like image generation and workflow execution, but there are notable gaps. For example, there are no tools for listing available workflows, updating or deleting workflows, or handling errors, which could limit agents in more complex scenarios within the ComfyUI domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Related MCP Connectors

mcp-qwen-imageOAuth
io.github.AceDataCloud
MCP server for Qwen Image 3 AI image generation
AI & Machine Learning Image & Video Processing
1
https://qwen-image.mcp.acedata.cloud/mcp
mcp-flux-proOAuth
io.github.AceDataCloud
MCP server for Flux AI image generation
Image & Video Processing Multimedia Processing
23
https://flux.mcp.acedata.cloud/mcp
Claude Imagine AOAuth
com.claudeimagine
Generate AI images and videos from any compatible MCP client.
AI & Machine Learning Image & Video Processing
102
https://claudeimagine.com/api/mcp
mcp A
com.budgetpixel
Generate AI images, video, music, and sound effects, and upscale them, from any MCP client.
AI & Machine Learning Image & Video Processing Audio Processing
2113
https://mcp.budgetpixel.com/mcp

Related MCP Servers

comfyui-mcp-server-node
AI & Machine Learning Image & Video Processing Multimedia Processing
yar3333
A
license
Not graded
quality
D
maintenance
A lightweight MCP server that bridges AI agents with a local ComfyUI instance to generate and iteratively refine images, audio, and video through conversational tool calls.
Updated 3 months ago (2026-07-31 17:02 UTC)
19 npm
1
MIT
ComfyUI MCP
Image & Video Processing AI & Machine Learning Autonomous Agents
orange521456
F
license
Not graded
quality
D
maintenance
MCP server that connects local ComfyUI to AI agents, enabling natural language control of ComfyUI for creating workflows, generating images, and managing the queue.
Updated 4 months ago (2026-06-27 04:27 UTC)
1
-
fm-mcp-comfyui-bridge
Image & Video Processing AI & Machine Learning
rerofumi
A
license
A
quality
D
maintenance
MCP server that provides image generation, captioning, and tagging via ComfyUI API, configurable for agent tools.
Updated a year ago (2025-07-12 16:30 UTC)
4
3
MIT
good-comfyui-mcp
Image & Video Processing AI & Machine Learning Browser Automation
xingxue-ux
A
license
Not graded
quality
A
maintenance
MCP server for generating AI images with local ComfyUI, featuring a reference-image-to-replication toolchain including Danbooru tag lookup, local Ollama vision, deobfuscation, and Civitai LoRA search/download.
Updated 3 months ago (2026-08-11 07:51 UTC)
4
MIT

Appeared in Searches

Finding and Saving Image Assets for Mini Program Development and Design