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

ComfyUI MCP 서버

1. 개요

ComfyUI를 MCP와 통합하기 위한 서버 구현.
⚠️ 중요: 이 서버에는 ComfyUI 서버가 실행 중이어야 합니다.
- 자신의 ComfyUI 서버를 호스팅해야 합니다.
- 또는 기존 ComfyUI 서버 주소에 액세스할 수 있습니다.

Related MCP server: ComfyUI MCP

2. 디버깅

2.1 ComfyUI 디버깅

지엑스피1

2.2 MCP 디버깅

mcp dev src/server.py

3. 설치 및 구성

3.1 ComfyUI 구성

src/.env 편집하여 ComfyUI 호스트와 포트를 설정합니다.
```
COMFYUI_HOST=localhost
COMFYUI_PORT=8188
```

3.2 사용자 정의 워크플로 추가

새로운 도구를 추가하려면 워크플로 JSON 파일을 workflows 디렉토리에 넣고 시스템에서 새 도구로 선언합니다.

4. 내장 도구

텍스트를 이미지로
- 생성된 이미지의 URL만 반환합니다.
- 실제 이미지를 얻으려면:
  - download_image 도구를 사용하거나
  - 브라우저에서 URL에 직접 접근하세요.
다운로드_이미지
- 이미지 URL을 사용하여 다른 도구(예: text_to_image )에서 생성된 이미지를 다운로드합니다.
파일과 함께 워크플로 실행
- 워크플로 JSON 파일의 경로를 제공하여 워크플로를 실행합니다.
  # You should ask to agent like this. Run comfyui workflow with text_to_image.json
- CursorAI의 예시 이미지

json으로 워크플로 실행

워크플로 JSON 데이터를 직접 제공하여 워크플로를 실행합니다.

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

5. 실행 방법

5.1 UV 사용(권장)

예시 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 Docker 사용하기

download_image 사용하여 로컬 폴더에 이미지를 다운로드하는 것은 Docker 컨테이너가 호스트 파일 시스템을 공유하지 않기 때문에 어려울 수 있습니다.
Docker를 사용할 때 다음 사항을 고려하세요.
1. .env 에서 RETURN_URL=false 설정하여 이미지 데이터를 바이트로 받습니다.
2. .env 에서 COMFYUI_HOST 적절한 주소(예: host.docker.internal 또는 서버의 IP)로 설정합니다.
3. 참고: 이진 데이터를 사용하면 대용량 이미지 페이로드가 응답 한도를 초과할 수 있습니다.

5.2.1 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 기존 이미지 사용

미리 만들어진 이미지를 사용할 수도 있습니다.

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

5.2.3 SSE 전송 사용

Docker로 SSE 서버를 실행합니다.

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

mcp.json 구성합니다(필요한 경우 localhost를 IP 또는 도메인으로 변경합니다):
```
{
  "mcpServers": {
    "comfyui": {
      "url": "http://localhost:8001/sse" 
    }
  }
}
```

참고: 새로운 워크플로를 도구로 추가하는 경우 Docker 이미지를 다시 빌드하고 다시 배포해야 사용할 수 있습니다.

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-image
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-pro
io.github.AceDataCloud
MCP server for Flux AI image generation
Image & Video Processing Multimedia Processing
23
https://flux.mcp.acedata.cloud/mcp
Claude Imagine A
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
2413
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
C
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