ComfyUI용 MCP 서버입니다. MCP 호환 클라이언트에서 자연어 프롬프트를 사용하여 이미지를 생성하세요.
v0.2 버전은 핵심 도구와 함께 업스케일, 이미지 프록시, 공개 URL 지원 기능을 제공합니다. 현재 도구 목록: generate_image, generate_variations, generate_with_workflow, refine_image, upscale_image, list_models, list_workflows, upload_image, generate_with_controlnet, generate_with_ip_adapter 및 워크플로우 템플릿 레지스트리. 향후 계획은 로드맵을 참조하세요.
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/mcp또는 스트리밍 가능한 HTTP 엔드포인트를 MCP 게이트웨이(예: MetaMCP)에 등록하여 다른 서버와 통합할 수 있습니다.
모든 옵션은 CLI 플래그 또는 환경 변수를 통해 설정할 수 있습니다:
CLI 플래그 | 환경 변수 | 기본값 | 설명 |
|
|
| 바인드 호스트 (HTTP 모드 전용) |
|
|
| 바인드 포트 (HTTP 모드 전용) |
|
| (설정 안 됨) | HTTP 대신 stdio를 통해 MCP 통신. stdio 우선 MCP 클라이언트(Claude Desktop, mcp-inspector)에 의해 하위 프로세스로 실행될 때 사용합니다. |
|
|
| 이 서버가 내부적으로 사용하는 ComfyUI HTTP URL |
|
|
| 클라이언트에 반환되는 이미지 URL의 외부 URL. 내부 URL에 MCP 클라이언트가 접근할 수 없는 경우(Docker 네트워크에서 흔함) 설정하세요. |
(플래그 없음) |
|
| 기본 체크포인트 파일명 |
서버는 기본적으로 스트리밍 가능한 HTTP를 사용합니다(Claude Code, MetaMCP, 원시 fetch에 적합). --stdio를 전달하거나 MCP_TRANSPORT=stdio를 설정하여 stdio 모드로 전환할 수 있으며, 이는 Claude Desktop 및 MCP Inspector와 같은 stdio 우선 클라이언트에서 기대하는 방식입니다:
# 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"]
}
}
}생성 도구는 <comfyui-public-url>/view?filename=…와 같은 이미지 URL을 반환합니다. --comfyui-public-url이 설정되지 않은 경우, URL은 내부 --comfyui-url 값을 사용합니다.
또한 서버는 프록시 엔드포인트를 노출합니다: GET /images/<filename>?subfolder=&type=output은 이 서버를 통해 이미지 바이트를 스트리밍하며, 클라이언트가 MCP 서버에는 접근할 수 있지만 ComfyUI에는 직접 접근할 수 없는 경우 유용합니다.
기본 체크포인트는 ComfyUI models/checkpoints/ 디렉토리에 있는 파일과 일치해야 합니다. COMFYUI_DEFAULT_CKPT를 통해 재정의하거나 도구 인수로 checkpoint를 전달하세요.
generate_imageComfyUI의 기본 txt2img 워크플로우를 사용하여 텍스트 프롬프트에서 이미지를 생성합니다.
매개변수: prompt (필수), negative_prompt, width, height, steps, cfg, seed, checkpoint.
generate_variations시드를 변경하여 동일한 프롬프트의 여러 변형을 생성합니다. 모든 이미지를 한 번에 반환합니다.
매개변수: prompt (필수), count (2~16, 기본값 4), 그리고 generate_image와 동일한 생성 매개변수(seed 대신 base_seed 사용).
generate_with_workflow임의의 ComfyUI 워크플로우 JSON(전체 노드 그래프)을 제출하고 결과 이미지 URL을 반환합니다. 사용자 지정 워크플로우(ControlNet, 업스케일링 또는 ComfyUI의 **Save (API Format)**에서 내보낸 모든 것)에 사용하세요.
매개변수: workflow (객체), 전체 노드 그래프.
refine_image소스 이미지에 img2img를 실행합니다. 서버가 소스 URL을 가져와 ComfyUI에 업로드하고, 새 프롬프트에 따라 디노이징 패스를 실행합니다. denoise 값이 낮을수록 원본을 더 많이 보존하며, 높을수록 프롬프트에 더 많은 자유도를 부여합니다.
매개변수: prompt, source_image_url (필수), denoise (0~1, 기본값 0.5), 그리고 표준 생성 매개변수.
list_modelsComfyUI 인스턴스에서 사용 가능한 체크포인트, LoRA, 샘플러 또는 스케줄러를 나열합니다.
매개변수: kind, checkpoints(기본값), loras, samplers, schedulers 중 하나.
list_workflows이 서버와 함께 제공되는 내장 워크플로우 템플릿(txt2img, img2img, upscale, controlnet, ip_adapter)을 나열합니다.
upload_imageimg2img, ControlNet 또는 IP-Adapter 워크플로우에서 사용할 참조 이미지를 ComfyUI에 업로드합니다.
매개변수: source_url 또는 image_base64 (둘 중 하나 필수), filename (선택 사항), overwrite (기본값 false).
반환값: 저장된 파일명. 이는 LoadImage와 같은 워크플로우 노드에서 image 입력으로 사용할 수 있습니다.
generate_with_controlnetControlNet 전처리 이미지(포즈 스켈레톤, 깊이 맵, Canny 엣지, 노멀 맵 등)와 텍스트 프롬프트를 사용하여 이미지를 생성합니다.
매개변수: prompt, control_image_url (전처리된 컨디셔닝 이미지; 이 도구는 전처리기를 실행하지 않음), controlnet_model (models/controlnet/의 파일명), strength (02, 기본값 1), start_percent / end_percent (01, 샘플링 중 CN 활성화 시점 제어), 그리고 표준 생성 매개변수.
ComfyUI models/controlnet/ 디렉토리에 ControlNet 모델이 설치되어 있어야 합니다.
generate_with_ip_adapterIP-Adapter를 통해 참조 이미지를 시각적/스타일/주제 가이드로 사용하여 이미지를 생성합니다.
매개변수: prompt, reference_image_url, preset (예: "STANDARD (medium strength)", "PLUS FACE (portraits)", "VIT-G (medium strength)"), weight (03, 기본값 1), start_at / end_at (01), 그리고 표준 생성 매개변수.
ComfyUI-IPAdapter-plus 커스텀 노드 팩과 프리셋에 맞는 IPAdapter 가중치 및 CLIP Vision 모델이 필요합니다.
복잡한 워크플로우 JSON을 한 번 저장하고 나중에 이름으로 실행하세요. 템플릿은 --templates-dir 아래 디스크에 저장되므로(~/.config/comfyui-mcp/templates/<name>.json 기본값) 재시작 후에도 유지되며 MCP 클라이언트 간에 이식 가능합니다.
도구 | 설명 |
| 워크플로우 JSON을 이름이 지정된 슬롯에 저장합니다. |
| 설명 및 마지막 업데이트 타임스탬프와 함께 저장된 템플릿을 나열합니다. |
| 저장된 템플릿의 JSON과 메타데이터를 가져옵니다. |
| 저장된 템플릿을 삭제합니다. |
| 저장된 템플릿을 ComfyUI에서 실행하고 이미지 URL을 반환합니다. |
템플릿 이름은 영문자와 숫자로 시작해야 합니다. 허용 문자: a-z, A-Z, 0-9, -, _. 최대 64자.
모든 생성 도구는 ComfyUI 인스턴스에서 직접 제공하는 이미지 URL(http://<comfyui>/view?filename=…)을 반환합니다. 이 URL은 이미지 URL을 허용하는 모든 클라이언트에 바로 전달할 수 있습니다.
┌────────────────┐ ┌──────────────────┐ ┌──────────────┐
│ MCP client │────▶│ comfyui-mcp │────▶│ ComfyUI │
│ (Claude, etc.)│◀────│ (this server) │◀────│ instance │
└────────────────┘ └──────────────────┘ └──────────────┘
streamable HTTP HTTP REST + poll서버는 상태를 저장하지 않습니다. 단일 MCP 요청이 ComfyUI에 워크플로우를 제출하고, 완료될 때까지 /history/{id}를 폴링한 후 이미지 URL을 반환합니다.
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 checkingNode 20+가 필요합니다.
v0.2 포함 사항:
generate_image, generate_variations, generate_with_workflow
refine_image (소스 URL에서 img2img)
upscale_image (ESRGAN / SwinIR 스타일 모델 업스케일)
list_models, list_workflows, upload_image
ComfyUI에 직접 접근할 수 없는 클라이언트를 위한 이미지 프록시 엔드포인트 (/images/<filename>)
외부에서 올바른 이미지 URL을 위한 구성 가능한 공개 URL
워크플로우 템플릿 레지스트리 (저장/나열/가져오기/삭제/실행)
generate_with_controlnet (ComfyUI 측에 ControlNet 모델 필요)
generate_with_ip_adapter (ComfyUI-IPAdapter-plus 팩 필요)
계획 중:
장시간 생성 작업을 위한 WebSocket 진행 상황 이벤트.
MIT © Joe Miller
이 도구가 시간을 절약해 주었다면 개발 지원을 고려해 주세요:
모든 기여는 유지 관리, 문서화 및 다음 릴리스를 지원합니다.
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
