comfyops-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| comfy_generateA | Generate image, video, or upscale via a curated ComfyUI workflow. RATIONALEConsolidated portmanteau: all generation modes share the same ComfyUI workflow submission and result polling pipeline. The operation discriminator selects the workflow type. Return Format{"success": bool, "prompt_id": str, "outputs": [...], "seed": int, "message": str} Examples |
| comfy_workflowsB | Manage curated ComfyUI workflow definitions. Return Format{"success": bool, "workflows": [...], "workflow": {...}, "sources": [...], "message": str} Examples |
| comfy_modelsA | Manage local models, download from Hugging Face (hash-verified), and check GPU VRAM. Return Format{"success": bool, "models": [...], "download": {...}, "vram": {...}, "health": {...}} Examples |
| comfy_nodesA | 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. Return Format{"success": bool, "packages": [...], "mapped": {...}, "message": str} Examples |
| comfy_libraryC | Browse past generations and record new ones. Return Format{"success": bool, "generations": [...], "message": str} Examples |
| comfy_agentic_assistA | 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. Return Format{"success": bool, "agent_plan": str, "error": str} Examples |
| show_comfyops_status_cardB | Show ComfyUI health and generation status as a rich in-chat card. Return FormatPrefab UI card with system status, VRAM, workflow count, model count |
| show_generation_cardC | Display a single generation result as a Prefab card. Return FormatRich card with prompt, seed, workflow, and output files |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Prefab Renderer (show_comfyops_status_card) | |
| Prefab Renderer (show_generation_card) |
TDQS
Scored 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.