Provides tools for downloading models from Hugging Face, including optional SHA-256 verification and bearer-token support for gated repositories.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@comfyops-mcp Generate an image of a cat surfing on a pizza slice"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Wraps ComfyUI so you can generate images, video, and upscales from a prompt — without ever touching the node editor. Pick a curated workflow, type what you want, get a PNG or MP4.
FastMCP 3.4+ | 5 portmanteau tools | 27 curated workflows | ComfyUI :11086 | Backend :11087 | Dashboard :11088
What's ComfyUI? It's the engine room of local AI image generation. You connect boxes labelled "KSampler", "CLIP Text Encode", and "VAE Decode" with wires, like a Moog synthesizer made by someone who hates knobs. It's incredibly powerful and completely impenetrable.
What's this? comfyops-mcp is a butler for ComfyUI. You tell it what you want — "a cat surfing on a pizza slice" — and it picks the right boxes, wires them up, and hands you the result. No node editor, no patch cables, no "what's a CFG scale?"
What can it do?
Turn text into images — verified: FLUX.2 klein 4B (seed-reproducible) and SD 1.5; curated: SDXL, FLUX.1 family, Z-Image, PixArt, Lumina2
Turn text or photos into short videos — curated (Wan 2.1/2.2, Hunyuan, LTX, Mochi, Cosmos) — not yet end-to-end verified
Upscale / restore old images — curated (ESRGAN, SUPIR) — not yet end-to-end verified
Inpaint and edit (SD1.5 inpaint/img2img; FLUX fill curated)
Browse and catalog workflows from the community
Remember every generation with its seed so you can reproduce it later
Who is it for?
You, who just wants pictures — prompt in, PNG out
You, who has an RTX 4090 gathering dust — put it to work
You, who already uses ComfyUI — now your AI assistant can drive it
You, who saw a cool AI image online and wants to make one
If you already know ComfyUI: comfyops registers curated workflows from
workflows/as MCP tools. You can add your own withcomfy_workflows/register. The workflows dir is yours — export from the node editor, drop in, done.
Related MCP server: comfyui-mcp
ComfyUI Node Editor (what we wrap) | comfyops Dashboard (what you see) |
|
|
Screenshots pending — run
just screenshotsonce the dashboard is live.
"Generate a 1024x1024 image of a cat surfing on a pizza slice"
"Upscale my archive of 2024 SD generations to 4K"
"Turn this photo into a cinematic video" (Wan 2.2 i2v)
"Make 10 variations of this character concept"git clone https://github.com/sandraschi/comfyops-mcp
cd comfyops-mcp
uv sync
.\start.ps1See docs/ONBOARDING.md for first-run (ComfyUI + models), and INSTALL.md for Claude Desktop config.
Models from Civitai: use civitai-mcp to search/download into the ComfyUI models tree; this repo generates.
Prompt-to-image — verified: FLUX.2 klein 4B fp8 (official ComfyUI wiring, ~1-2 min per 1024x1024 on a 4090, seed-reproducible) and SD 1.5
Prompt-to-video / upscale / inpaint: curated workflows (Wan 2.1/2.2, Hunyuan, LTX, Mochi, ESRGAN, SUPIR) — pending end-to-end verification
Model downloads: comfy_models/download streams from Hugging Face with optional sha256 verification and Bearer auth for gated repos
VRAM guard: Checks free GPU memory before queueing — no OOM crashes; models are unloaded after each run so the reading stays honest
Seed control: Same seed + same workflow = identical output, every time (verified)
Generation library & gallery: SQLite history with sorting, filters, batch delete/export (CSV/JSON), and crossconnects (same workflow/model)
Agentic workflow: Multi-step generation planning via MCP sampling (SEP-1577)
Prefab cards: Rich in-chat status and generation cards
Mode | ComfyUI required? | When |
MCP tools (stdio/HTTP) | Yes | Generation via Claude Desktop, Cursor, opencode |
Dashboard (Vite) | No | Browse workflows, models, library — generation needs ComfyUI |
ComfyUI sidecar | Optional |
|
comfyops ships with 27 curated workflows (t2i, i2v, t2v, inpaint, edit, upscale, restore).
Use comfy_workflows/register to add your own exports from the ComfyUI node editor.
Tool | Ops |
| image, video, upscale, inpaint, edit |
| list, get, validate, register |
| list_installed, download, check_vram, health |
| recent, search, record |
| Multi-step via MCP sampling |
ComfyUI GitHub — the project we wrap
ComfyUI Discord — 100k+ members, workflow sharing, troubleshooting
ComfyUI Workflows on Reddit — daily shared workflows
CivitAI — models, LoRAs, and workflow downloads
ComfyUI Registry — official workflow and node registry
OpenArt — community workflows with parameter previews
ComfyUI Examples — official example gallery
Onboarding — ComfyUI, ports, civitai handoff
Configuration — env vars reference
Tool Reference — full parameter docs
Development — setup, testing, contributing
Troubleshooting — common issues
Fleet start: mcp-central-docs/starts/comfyops-mcp-start.bat
Multi-step agentic generation via MCP sampling (SEP-1577).
Plans a generation campaign: describes the creative goal, selects appropriate workflow(s), generates, optionally vision-checks via local multimodal model, and retries with adjusted params (max 3).
Requires a host with MCP sampling. Falls back to a structured manual tool sequence when sampling is unavailable.
{"success": bool, "agent_plan": str, "error": str}
comfy_agentic_assist(goal="Create a cinematic aerial shot of a cyberpunk city")| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | Natural language description of what to generate. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure and does so thoroughly. It explains the internal campaign steps, the optional vision-check, the maximum retry count of 3, the MCP sampling requirement, the fallback behavior, and the exact return format. This gives the agent a strong mental model of what will happen when invoked.
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 efficiently structured: a one-line purpose statement, a compact bullet-like process summary, a prerequisite and fallback note, and a clearly labeled return format and example. Every section earns its place, and the most important information is 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?
For a single-parameter tool with an output schema, the description is remarkably complete. It covers what the tool does, the steps it performs, constraints (MCP sampling, max 3 retries), fallback behavior, return format, and a usage example. An agent has sufficient information to decide when to call it and what to pass.
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 already documents the single 'goal' parameter at 100% coverage, so the baseline is 3. The description adds value by including a concrete example ('Create a cinematic aerial shot of a cyberpunk city') that demonstrates the expected natural-language input style and by framing the parameter as a 'creative goal' within the agentic workflow.
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 opens with a specific verb phrase, 'Multi-step agentic generation via MCP sampling,' and then details the full workflow: planning, workflow selection, generation, optional vision-checking, and retries. This clearly distinguishes it from sibling tools like comfy_generate or comfy_workflows by emphasizing the agentic, multi-step campaign nature.
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 gives clear context: this tool is for multi-step agentic generation campaigns and requires a host with MCP sampling. It also mentions a fallback to a manual tool sequence when sampling is unavailable, which helps an agent understand when the tool can run. However, it does not explicitly name alternatives or state 'use this instead of comfy_generate for complex goals,' leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate image, video, or upscale via a curated ComfyUI workflow.
Consolidated portmanteau: all generation modes share the same ComfyUI workflow submission and result polling pipeline. The operation discriminator selects the workflow type.
{"success": bool, "prompt_id": str, "outputs": [...], "seed": int, "message": str}
comfy_generate(operation="image", workflow_id="flux-klein-t2i",
prompt="a cat surfing on a pizza slice", seed=42)
comfy_generate(operation="upscale", workflow_id="esrgan-upscale",
prompt="", image_input="<base64>")| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Random seed for reproducibility. Omit for random. | |
| size | No | Image size as WxH (e.g. '1024x1024'). | |
| prompt | Yes | Text prompt for generation. | |
| operation | Yes | Generation type. | |
| image_input | No | Base64 image for i2v/inpaint/edit. | |
| workflow_id | Yes | Workflow ID from comfy_workflows/list. | |
| negative_prompt | No | Negative prompt. | |
| auto_install_nodes | No | Install missing custom nodes via ComfyUI-Manager. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It does add useful context by revealing the shared workflow submission and result polling pipeline and by providing a return format. However, it does not explain asynchronous behavior, failure modes, side effects, or cost/network implications, so transparency is only partial.
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 well-structured and appropriately sized: a one-line summary, a rationale for the consolidated design, a return-format block, and two concrete examples. Every section earns its place and there is no filler or repetition of the input schema.
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?
For a tool with 8 parameters and 5 enum values, the description is largely complete: it provides the return format, illustrates required parameters, and explains why one pipeline covers all operations. It lacks examples for video, inpaint, and edit, and does not elaborate on operation-specific input dependencies, but the schema covers those details, making the remaining gaps minor.
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%, so the baseline is 3, but the description adds operational meaning through its examples: it shows how operation pairs with workflow_id, demonstrates that upscale uses an empty prompt with a base64 image_input, and illustrates the optional seed parameter. This helps an agent combine parameters correctly beyond what the schema alone provides.
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 opens with a clear verb and resource: 'Generate image, video, or upscale via a curated ComfyUI workflow.' The rationale explains that a single operation discriminator selects the workflow type, which distinguishes it from sibling workflow-management and list tools. However, the first sentence omits the 'inpaint' and 'edit' operations that appear in the schema enum, and it does not explicitly name sibling alternatives.
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?
Usage is mostly implied rather than stated. The rationale says all generation modes share the same workflow submission and result polling pipeline, and the examples show image and upscale invocations, but the description does not explicitly say when to use this tool versus comfy_workflows or comfy_agentic_assist. There are no exclusion conditions or alternative routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse past generations and record new ones.
{"success": bool, "generations": [...], "message": str}
comfy_library(operation="recent", limit=10)
comfy_library(operation="search", query="cat surfing")| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results. | |
| model | No | Model for record. | |
| query | No | Search text. | |
| outputs | No | JSON outputs for record. | |
| seed_val | No | Seed for record. | |
| operation | Yes | Operation to perform. | |
| prompt_id | No | Prompt ID for record. | |
| prompt_text | No | Prompt for record. | |
| workflow_id | No | Workflow ID for record. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations are empty, so the description carries the full burden of behavioral disclosure. It does share a return format and examples, but it does not disclose side effects of 'record', whether the operation mutates stored data, required permissions, or failure behavior. For a tool that includes a write-style operation, this is a significant gap.
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 compact and front-loaded: the purpose appears first, and the return format plus examples are genuinely useful. The main weakness is that 'record new ones' is vague enough that the opening sentence could be more precise. No obvious filler is present.
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 nine parameters and a multi-mode operation enum, the description is incomplete because it does not explain per-operation expectations, required parameter combinations, or behavior of the 'record' operation. The return format helps, but the description alone is not enough to correctly invoke all operations.
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 100%, so the baseline is 3. The examples add some value by pairing operation values with relevant parameters, but the description still does not clarify which parameters are required for the 'record' operation or how fields like model, outputs, seed_val, prompt_id, and workflow_id interrelate.
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 names a clear domain: 'Browse past generations and record new ones', and the operation enum adds concrete verbs such as recent, search, and record. However, it does not differentiate this tool from siblings like show_generation_card or comfy_generate, and 'record new ones' is somewhat vague about what exactly is being recorded.
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?
Examples for 'recent' and 'search' show basic usage but there is no explicit guidance on when to use this tool versus alternatives, no exclusions, and no conditions for choosing record versus comfy_generate. The description leaves the agent to infer context from the operation enum alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage local models, download from Hugging Face (hash-verified), and check GPU VRAM.
{"success": bool, "models": [...], "download": {...}, "vram": {...}, "health": {...}}
comfy_models(operation="list_installed")
comfy_models(operation="check_vram", model_vram_gb=6.0)
comfy_models(operation="download", hf_repo="org/model", filename="m.safetensors",
target="diffusion_models", sha256="<hash>")
comfy_models(operation="health")| Name | Required | Description | Default |
|---|---|---|---|
| sha256 | No | Expected sha256 of the file (verified when provided). | |
| target | No | ComfyUI model subdir (checkpoints, diffusion_models, loras, text_encoders, vae, upscale_models). | |
| hf_repo | No | Hugging Face repo id for download (e.g. 'black-forest-labs/FLUX.1-schnell'). | |
| filename | No | File name within the repo for download. | |
| dest_name | No | Optional destination filename (defaults to filename). | |
| operation | Yes | Operation to perform. | |
| model_vram_gb | No | Estimated VRAM for check_vram. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the behavioral disclosure burden. It mentions hash-verified downloads and the return format, but does not disclose that downloads write to local disk, require network access, or that other operations are read-only. This is not misleading, but it is incomplete.
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 compact and well-organized into summary, return format, and examples. Every line earns its place, with no redundant prose.
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 7 parameters and 4 operations, the description provides a return format and concrete examples for every operation, which is sufficient for an agent to invoke the tool correctly. It doesn't detail error behavior or sub-object fields, but the output schema is present and the examples cover the main 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?
All parameters have schema descriptions (100% coverage), so baseline is 3. The examples add value by showing which parameters apply to each operation (e.g., model_vram_gb for check_vram, hf_repo/filename/target/sha256 for download), exceeding baseline.
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 resource (local models) and key actions (manage, download from Hugging Face, check GPU VRAM), and the operation enum plus examples further pin down the scope. It does not explicitly differentiate from siblings like comfy_library, so it misses the top score.
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?
Examples show valid invocations for each operation, which gives implicit usage guidance. However, there is no explicit statement about when to use this tool vs. alternatives such as comfy_generate or comfy_library, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install and resolve ComfyUI custom nodes via ComfyUI-Manager.
Maps missing node class_types → Manager packages (registry/GitHub catalog), installs via cm-cli or Manager REST queue, restarts ComfyUI, re-validates.
{"success": bool, "packages": [...], "mapped": {...}, "message": str}
comfy_nodes(operation="status")
comfy_nodes(operation="ensure", workflow_id="my-complex-wf")
comfy_nodes(operation="install", packages="ComfyUI-Impact-Pack,ComfyUI-VideoHelperSuite")
comfy_nodes(operation="resolve", missing_types="ImpactInt,VHS_LoadVideo")| Name | Required | Description | Default |
|---|---|---|---|
| git_url | No | Git repo URL for install_git. | |
| packages | No | Comma-separated Manager package names for install. | |
| operation | Yes | Operation to perform. | |
| workflow_id | No | Workflow ID for ensure/resolve. | |
| auto_install | No | Override COMFYOPS_AUTO_INSTALL_NODES. | |
| missing_types | No | Comma-separated class_types for resolve. | |
| workflow_json | No | Raw workflow JSON for ensure/resolve. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose meaningful behavior: installation via cm-cli or Manager REST queue, restart of ComfyUI, and re-validation after install. It also specifies the return format. It does not detail per-operation side effects or permission needs, but the main mutating behavior is transparent.
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?
Purpose is front-loaded, followed by a compact process line, return format, and useful examples. Every section earns its place and there is no filler or 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?
The tool has 7 parameters and 6 operations with no annotations. The description covers overall behavior and some examples, but leaves the mappings and install_git operations underspecified and does not clearly distinguish 'ensure' from 'resolve'. An agent could still be uncertain which operation to invoke in edge cases.
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%, so baseline is 3. The description adds value by showing concrete operation-to-parameter examples (install→packages, resolve→missing_tpes, ensure→workflow_id) and explaining the mapping concept from missing class_types to packages.
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?
States a specific verb+resource+mechanism: 'Install and resolve ComfyUI custom nodes via ComfyUI-Manager.' The mapping of missing class_types to packages and the examples distinguish it from sibling tools focused on generation, workflows, models, or library management.
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?
Clear context is given: the tool maps missing node class_types to Manager packages, installs, restarts, and re-validates. This implies when to use it (missing/required custom nodes), though it does not explicitly name alternatives or 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.
Manage curated ComfyUI workflow definitions.
{"success": bool, "workflows": [...], "workflow": {...}, "sources": [...], "message": str}
comfy_workflows(operation="list")
comfy_workflows(operation="search", query="flux", tags="video")
comfy_workflows(operation="discover")
comfy_workflows(operation="register", workflow_id="my-wf",
workflow_json='{"3":{"class_type":"KSampler",...}}',
tags="t2i,portrait", source_url="https://civitai.com/...")| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Display name for register. | |
| tags | No | Comma-separated tags for search/register. | |
| query | No | Search text for search operation. | |
| operation | Yes | Operation to perform. | |
| source_url | No | Original source URL for register. | |
| description | No | Description for register. | |
| workflow_id | No | Workflow ID for get/validate/register. | |
| workflow_json | No | JSON string for register. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It provides a return-format sketch and examples, but it does not disclose side effects (e.g., whether register persists data, whether discover pulls remote sources) or any safety, auth, or rate-limit 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 compact and well-organized with a one-line purpose, a Return Format block, and a few representative examples. The 'Manage' verb is generic, but the structure earns its place without redundancy.
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 six operations and eight parameters, the description omits explicit guidance for get and validate, and it does not state which parameters are relevant per operation beyond examples and schema hints. The presence of an output schema reduces the need to document return values, but behavior and operation selection remain under-specified.
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 already documents all eight parameters with 100% coverage, so the description need not repeat them. The examples do illustrate sensible combinations like operation='search' with query and tags, but no new parameter meaning is added beyond the 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 phrase 'Manage curated ComfyUI workflow definitions' names a clear resource and general action, and the examples show concrete operations such as list, search, discover, and register. It does not explicitly contrast with sibling tools like comfy_library or comfy_generate, so it stops short of a 5.
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?
Usage is implied by the operation enum and examples, but the description never states when to prefer this tool over siblings or how to choose among list, search, discover, get, and validate. There are no explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show ComfyUI health and generation status as a rich in-chat card.
Prefab UI card with system status, VRAM, workflow count, model count
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It states it shows a card with system status and counts, implying a read-only operation, but it does not explicitly confirm that no state changes occur, nor does it mention any side effects or requirements. For a display tool, the risk is low but still under-specified.
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 lines of intent plus a brief return-format note. It is front-loaded with the main purpose and adds a useful detail about the card contents, with no waste.
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 no parameters and an output schema, the description covers the essential return content. However, it does not clarify how this differs from the sibling show_generation_card, which is a notable contextual gap for an agent selecting between them.
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 tool has zero parameters, so there is nothing to add beyond the schema. The description correctly omits parameter details, and the schema coverage is 100% (trivially). This is a baseline 4.
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 states a specific action ('show') and resource ('ComfyUI health and generation status') and mentions it returns a rich in-chat card. It is clear and distinct from generation-specific tools, though it does not explicitly differentiate from the sibling show_generation_card, so not a 5.
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 given on when to use this tool versus alternatives such as show_generation_card or the comfy_* family. The description does not state any context, prerequisites, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Display a single generation result as a Prefab card.
Rich card with prompt, seed, workflow, and output files
| Name | Required | Description | Default |
|---|---|---|---|
| seed | Yes | ||
| prompt | Yes | ||
| outputs | No | ||
| workflow_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden. It only states what it displays but does not disclose whether it is read-only, whether it has side effects, or any constraints. The return-format note hints at output but not operational 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 short and to the point, but the '## Return Format' heading is oddly placed and the content is sparse. It is concise without being verbose, but could be better structured with front-loaded key details.
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 4 parameters, no schema coverage, no annotations, and an output schema, the description is incomplete. It does not provide enough context for an agent to construct a valid call, understand parameter relationships, or know what the expected output fully looks like.
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 0%, so the description must explain the parameters. It mentions prompt, seed, workflow, and output files only in the context of the card's content, not as input semantics. It does not explain what each parameter means, how they are used, or any constraints.
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?
States a specific verb 'Display' and resource 'single generation result as a Prefab card', making the core action clear. However, it does not distinguish this from sibling tools like show_comfyops_status_card or comfy_generate, so differentiation is missing.
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 versus alternatives. There is no mention of use cases, prerequisites, or exclusions. An agent cannot determine whether to pick this over comfy_generate or other display tools.
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.0comfy_agentic_assistcomfy_generatecomfy_librarycomfy_modelscomfy_nodescomfy_workflowsshow_comfyops_status_cardshow_generation_cardScored across 8 tools
Most tools map cleanly to a distinct resource or action: generation, workflow definitions, models, nodes, generation history, and UI cards. The main boundary overlaps are comfy_agentic_assist vs comfy_generate and comfy_models health vs show_comfyops_status_card, but the descriptions and operation parameters give enough guidance for an agent to choose correctly.
The core tools share a predictable comfy_ prefix and snake_case style, with each comfy_<domain> tool using an operation parameter to select actions. The show_*_card presentation tools and comfy_agentic_assist deviate from the resource-manager pattern, but the naming remains readable and mostly consistent.
Eight tools is a well-scoped size for a ComfyUI operations server; each tool covers a meaningful area such as generation, workflow registry, model management, node resolution, generation history, agentic orchestration, and UI display. The operation-based design keeps the tool count from ballooning while still exposing the needed functionality.
The core generation lifecycle is covered end-to-end: discover/register workflows, resolve nodes, manage models, generate, browse history, and display results. Gaps such as deleting/uninstalling workflows/models/nodes and an explicit library record operation keep it from being fully complete, but agents can work around these for typical generation tasks.
Remote MCP for RunComfy: ComfyUI deployments, hosted models, LoRA training. 31 tools.
Create and manage AI image and video generations through Quriov's fixed public MCP tools.
Multi-model AI image and video generator. 14 models behind one OAuth-secured MCP endpoint.
Create images & video from any MCP agent — 17 models, spend limits, one URL.
