Skip to main content
Glama

comfy_cli

Manage ComfyUI server lifecycle, async jobs, workflow validation and runs, file transfers, model downloads, and agent skills through a CLI interface.

Instructions

Drive the official comfy-cli (envelope/1 JSON contract) for the selected ComfyUI environment. The MCP resolves comfy from COMFY_CLI_PATH, PATH, or the selected workspace's .venv/venv. Driven by the action parameter:

  • action:"status" — Inspect the comfy-cli integration and selected environment (comfy which / comfy env); detail selects version/which/env/discover (default env). Call this before local CLI operations when workspace or server routing is uncertain.

  • action:"server_start" / "server_stop" / "server_restart" — Manage a local ComfyUI through comfy-cli background process management. Restart performs comfy stop followed by comfy launch --background; extra launch arguments go in launchArgs.

  • action:"jobs_list" — List local or Comfy Cloud jobs (limit optional). Local jobs include CLI-tracked async submissions plus the ComfyUI queue/history.

  • action:"jobs_status" / "jobs_watch" / "jobs_cancel" — Inspect, watch, or cancel one job; promptId required.

  • action:"jobs_wait" — Wait for jobs: one of promptId, promptIds, or all=true is required; timeoutSeconds optional.

  • action:"search_nodes" — Fuzzy-search actual ComfyUI node classes by name, display name, or description using comfy nodes search; query required. Complements search_custom_nodes, which searches installable node packs. Works locally, in Comfy Cloud, or offline with objectInfoPath. When comfy-cli is not installed/on PATH and the target is the connected (local) server, falls back to fuzzy-searching that server's live /object_info — so installed-node discovery works without the CLI.

  • action:"workflow_validate" — Validate an API/UI workflow file (class types, inputs, enums, edge wiring) without submission; workflowPath required.

  • action:"workflow_run" — Submit an API/UI workflow file (workflowPath required). Asynchronous by default; set wait=true to await outputs (timeoutSeconds).

  • action:"transfer_upload" — Upload input files (files required) for local ComfyUI or Comfy Cloud; overwrite=false passes --no-overwrite.

  • action:"transfer_download" — Download completed outputs for promptId (required); outDir and urlOnly optional.

  • action:"models_list_folders" / "models_list_folder" / "models_search" / "models_show" — Discover model folders/files locally or in Comfy Cloud (folder required for list_folder, name for show). For models_show, pass folder/type or a relative name path (e.g. vae/foo.safetensors) when the same basename exists in more than one folder. When comfy-cli is not installed/on PATH and the target is the connected (local) server, these read-only listings fall back to that server's own local models (via /models) — so model discovery works without the CLI.

  • action:"models_download" — Download a model url (required) into the workspace (relativePath, default models/checkpoints). A download can run for many minutes and is gated on an idle-liveness timeout, so a progressing download is never killed.

  • action:"models_remove" — Remove workspace model files (modelNames required; relativePath optional).

  • action:"skills_list" / "skills_show" / "skills_validate" / "skills_install" / "skills_status" / "skills_uninstall" — Manage the official comfy-cli bundled agent skills (comfy, fragments, debug, relay, director). validate requires path; install/uninstall default to dry-run unless apply=true; scope="project" requires projectDir.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
allNoaction:"jobs_wait" — wait on every known job.
urlNoaction:"models_download" — model URL to download. REQUIRED.
nameNoactions "models_show"/"skills_show" — the model or skill name. For models_show a relative path (e.g. vae/qwen_image_vae.safetensors) selects among duplicate basenames.
pathNoaction:"skills_validate" — path to the skill to validate. REQUIRED.
textNoaction:"models_search" — search text.
typeNoaction:"models_search" — model type filter (checkpoint, lora, vae, …). action:"models_show" — same filter, to pick among duplicate basenames.
waitNoaction:"workflow_run" — await outputs instead of returning after submission.
applyNoactions "skills_install"/"skills_uninstall" — actually mutate; default false = dry-run.
filesNoaction:"transfer_upload" — input files to upload. REQUIRED.
limitNoResult cap for "jobs_list", "search_nodes" and the "models_*" listing/search actions.
queryNoaction:"search_nodes" — fuzzy search text. REQUIRED.
scopeNoactions "skills_install"/"skills_uninstall"/"skills_status" — install scope.
whereNoTarget for the jobs/search_nodes/workflow/transfer/models actions: "local" (default) or "cloud" (Comfy Cloud).
actionYesWhich comfy-cli operation to perform. Families: status; server_* (lifecycle); jobs_* (list/status/wait/watch/cancel); search_nodes; workflow_* (validate/run); transfer_* (upload/download); models_* (list_folders/list_folder/search/show/download/remove); skills_* (list/show/validate/install/status/uninstall).
detailNoaction:"status" — which inspection to run.env
folderNoaction:"models_list_folder" — the model folder to list (REQUIRED). action:"models_show" — optional folder to pick among duplicate basenames.
outDirNoaction:"transfer_download" — output directory.
skillsNoactions "skills_install"/"skills_uninstall" — skill names.
targetsNoactions "skills_install"/"skills_uninstall" — agent targets.
urlOnlyNoaction:"transfer_download" — print URLs instead of downloading files.
promptIdNoSingle prompt id. Required for "jobs_status"/"jobs_watch"/"jobs_cancel" and "transfer_download"; accepted for "jobs_wait" (normalized into a one-element promptIds list).
overwriteNoaction:"transfer_upload" — set false to pass --no-overwrite.
promptIdsNoaction:"jobs_wait" — prompt ids to wait on. Use this or promptId or all=true.
workspaceNoOptional ComfyUI workspace override (the data/base root comfy-cli uses for custom_nodes/models). Otherwise the live --base-directory / COMFYUI_PATH is used; the CLI executable may still come from the COMFYUI_CODE_PATH checkout's .venv.
launchArgsNoactions "server_start"/"server_restart" — extra ComfyUI launch arguments, e.g. ['--listen','0.0.0.0','--port','8188'].
modelNamesNoaction:"models_remove" — model filenames to remove. REQUIRED.
projectDirNoWorking directory for project-scoped skill operations. Required when scope='project'.
relativePathNoactions "models_download"/"models_remove" — workspace-relative model directory (default models/checkpoints).
workflowPathNoactions "workflow_validate"/"workflow_run" — path to an API/UI workflow JSON file. REQUIRED.
objectInfoPathNoaction:"search_nodes" — offline object_info JSON file to search instead of a live target.
timeoutSecondsNoactions "jobs_wait"/"jobs_watch"/"workflow_run" — max seconds to wait.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so richly: async-by-default workflow_run with wait/timeout, dry-run default for skill install/uninstall, background process management for server actions, idle-liveness timeout for downloads, and fallback to live /object_info or /models when the CLI is unavailable. These are material traits beyond the schema.

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

Conciseness4/5

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

The definition is long, but it is front-loaded with purpose and organized into action families with bullet-style explanations. For a 26-action, 31-parameter mega-tool, most sentences earn their place, though some redundancy with the schema could be trimmed.

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

Completeness4/5

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

Given the complexity, no output schema, and no annotations, the description is largely complete: it covers action selection, required parameters, fallbacks, dry-run behavior, and timeout semantics. It does not explain the envelope/1 JSON return shape or error format, which is a minor gap without an output schema.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 31 parameters in detail. The description adds some conditional grouping and cross-references, but mostly restates required-parameter relationships already present in the schema descriptions.

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

Purpose5/5

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

States a specific verb and resource ('Drive the official comfy-cli ... for selected ComfyUI environment') and breaks down behavior by action families. It also explicitly distinguishes search_nodes from search_custom_nodes, so an agent can tell it apart from that sibling without opening schemas.

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

Usage Guidelines4/5

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

Provides clear context for each action, including when to call status before local CLI operations and how fallbacks work when comfy-cli is missing. However, it does not state when to prefer comfy_cli over overlapping siblings like install_comfyui, restart_comfyui, or download_model, so exclusions are absent.

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