Skip to main content
Glama
SwayamJoshi87

comfyui-mcp

by SwayamJoshi87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_local_models

Inspect installed models and search paths on a connected ComfyUI. Read-only listing by type helps confirm available models before generating or downloading.

Instructions

Inspect what models this ComfyUI has installed, and where it looks for them. Driven by the action parameter:

  • action:"list" — List model files available to the connected ComfyUI, grouped by type. Read-only. Queries ComfyUI's /models REST endpoint first (works with remote ComfyUI and respects extra_model_paths.yaml — symlinked / mounted dirs the install-path filesystem scan would miss). LOCAL ComfyUI then falls back to a filesystem scan of COMFYUI_PATH/models/ when the REST endpoint is unavailable; REMOTE ComfyUI never scans this MCP host's local path, so an unavailable remote listing is returned as undetermined rather than another machine's inventory. Size and modified time are only available on the local filesystem fallback path. Use to see which models are already available before generating or downloading; use download_model action:"search" to discover new models on HuggingFace, then action:"download" to fetch them. For models fetched via download_model action:"download_civitai", any CivitAI trigger/activation words and base model are shown inline (read from the <file>.civitai.json sidecar) — apply those trigger words in your prompt when generating with that model. A civitai: line under an entry is that model's CivitAI page URL (modelId + INSTALLED modelVersionId, from the same sidecar) — use it to reference the source or check for newer versions.

  • action:"remove" — DELETES a model FILE from the local ComfyUI models directories. path is REQUIRED and is a file path relative to models/. THIS IS DESTRUCTIVE AND HAS NO UNDO: the file is unlinked, not moved to a recycle bin, and a large checkpoint can take hours to re-download — confirm the exact path with the user (action:"list" shows it) before calling. Removal searches only roots the connected local server itself names or whose extra-path config is proven to have been loaded unchanged since launch (server-named/launch-state-proven roots). A root shown by action:"list_paths" may be visible but unproven, so removal can refuse it; read-only list/list_paths lookups can show configured roots. The path must stay within a known root (path traversal and absolute escapes are rejected), and a directory is refused. LOCAL-ONLY: deletes from the local filesystem, so it is not supported against a remote ComfyUI (remove the file on the host). Do NOT confuse this with action:"remove_path", which edits a config file and deletes nothing.

  • action:"embeddings" — List textual-inversion embeddings installed on the connected ComfyUI server (read from its /api/embeddings endpoint, i.e. the models/embeddings folder). Requires a running, reachable ComfyUI (local or remote); takes no other parameters. Returns the embedding names; reference them in positive or negative prompts as embedding:name (e.g. embedding:easynegative). Read-only.

  • action:"list_paths" — View ComfyUI extra search-path config for standalone/manual installs and ComfyUI Desktop. Read-only. Resolves LIVE-FIRST: the file the running ComfyUI actually reads (its --extra-model-paths-config, else the extra_model_paths.yaml beside its main.py), falling back to the local heuristic only when no server is reachable — /extra_model_paths.yaml (COMFYUI_PATH, else the saved default workspace from workspace action:"set_default") or the Desktop app-data extra_models_config.yaml. Reports generic categories, so model categories and custom_nodes entries are both visible when present. Because it is read-only it never refuses a reachable LOCAL server just because its argv does not prove which file it reads: it shows the server-named config when that file exists here, else the local auto-selected one, always labelled as unconfirmed rather than presented as the live server's. action:"add_path"/action:"remove_path" still refuse in that state — a write to an unproven file would be a silent no-op.

  • action:"add_path" — Add a directory to a ComfyUI extra search-path YAML config; category + path are REQUIRED. Use this for model categories such as checkpoints/loras/vae and, on ComfyUI builds that support it, custom_nodes. Writes the config file and returns the updated view; restart ComfyUI to apply.

  • action:"remove_path" — Remove a directory from a ComfyUI extra search-path YAML config; category + path are REQUIRED. Matches the stored path exactly. This edits the YAML only — it deletes NO model files and frees no disk space (that is action:"remove"). Restart ComfyUI after removing an active path.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoREQUIRED by three actions, and it means two DIFFERENT things — read this before calling. action:"remove": the MODEL FILE to DELETE, relative to the ComfyUI models/ directory (e.g. 'checkpoints/sd_xl_base_1.0.safetensors'); the leading segment is the category used to locate the file in extra roots too. action:"add_path" / action:"remove_path": a DIRECTORY to add to / remove from the extra-search-path YAML for `category` (absolute paths are safest; relative paths are resolved by ComfyUI) — no file is deleted.
groupNoaction:"add_path" / "remove_path" — top-level YAML group to edit. Defaults to comfyui_mcp.
actionYesWhich inventory operation to perform. "list" (optional `model_type`), "embeddings" and "list_paths" are READ-ONLY. "remove" DELETES the model file named by `path` — required, and destructive. "add_path"/"remove_path" edit the extra-search-path YAML and require `category` + `path`; they never touch model files.
targetNoaction:"list_paths" / "add_path" / "remove_path" — config target. auto (default) is LIVE-FIRST: the running ComfyUI's own --extra-model-paths-config, else the extra_model_paths.yaml next to its main.py. When no server is reachable, auto shows the Desktop config if one exists, otherwise standalone. When a reachable LOCAL server does not expose main.py, listing degrades to the server-named config (if it exists here) or the local auto-selected one, explicitly marked as an unconfirmed display fallback; mutations refuse instead. standalone forces <ComfyUI root>/extra_model_paths.yaml, where the root is COMFYUI_PATH (or an auto-detected install) and falls back to the saved default workspace; desktop forces the OS app-data extra_models_config.yaml. Use standalone/desktop (or config_path) to deliberately target a file the running server does not read.
categoryNoREQUIRED for action:"add_path" / action:"remove_path" — the ComfyUI search-path category, e.g. checkpoints, loras, vae, diffusion_models, unet_gguf, or custom_nodes.
is_defaultNoaction:"add_path" — set is_default on a newly-created group. Existing groups are not overwritten.
model_typeNoaction:"list" — filter by model type (e.g. 'checkpoints', 'loras'). Lists all types if omitted.
config_pathNoaction:"list_paths" / "add_path" / "remove_path" — explicit YAML config path override, mainly for advanced/manual installs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Without annotations, the description carries the full burden and does so exceptionally well. It discloses destructiveness with 'THIS IS DESTRUCTIVE AND HAS NO UNDO', explains the fallback behavior (REST-first then filesystem scan), notes that size/mtime are only available locally, describes sidecar file reading for CivitAI metadata, and explains path traversal rejection and directory refusal.

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

Conciseness3/5

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

The description is extremely dense and long, with deeply nested parenthetical explanations. While front-loaded with a clear purpose statement, the action breakdowns are verbose and could be more scannable. It earns its length given the complexity but is not concise.

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

Completeness5/5

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

Complete for a multi-action tool with no output schema. It covers every action variant, the fallback logic, permissions implications, side effects, and cross-references to sibling tools. An agent has everything needed to select and invoke correctly.

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

Parameters5/5

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

Schema coverage is 100%, so baseline is 3, but the description adds substantial value by clarifying that `path` has two different meanings depending on action, explaining the category requirement, the target parameter's live-first resolution strategy, and the group default. It goes well beyond 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?

The description opens with a specific verb+resource ('Inspect what models this ComfyUI has installed, and where it looks for them') and then breaks down every action variant with precise detail. Each action is described with its own verb and scope, making it unmistakably distinct from siblings like download_model or model_metadata.

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

Usage Guidelines5/5

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

Explicitly states when to use list ('before generating or downloading') versus download_model's search/download actions, and provides detailed guidance for each action including restrictions ('LOCAL-ONLY', 'REMOTE ComfyUI never scans'). It also warns against confusing action:"remove" with action:"remove_path" and explains the distinction.

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

Deploy Server

Other Tools