Skip to main content
Glama

list_local_models

List installed ComfyUI models by type, using the /models API or filesystem scan, to see what's available 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), then falls back to a filesystem scan of COMFYUI_PATH/models/ when the REST endpoint is unavailable. Size and modified time are only available on the 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. Resolves the path across ALL configured roots — the primary /models AND every directory in extra_model_paths.yaml / extra_models_config.yaml (e.g. models stored on another drive like E:) — the same roots ComfyUI loads from. 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.
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so exceptionally. It flags destructive actions loudly ('THIS IS DESTRUCTIVE AND HAS NO UNDO'), discloses read-only vs mutating actions, explains fallback behavior (REST-first then filesystem), path traversal rejection, directory refusal, remote unsupported for remove, and restart requirements. It also covers edge cases like unconfirmed display fallback and sidecar-based CivitAI metadata. No behavioral trait is hidden.

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

Conciseness5/5

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

Though long, the description earns its length: it covers six actions with clear bullet-like separators, each with relevant warnings and context. The opening line gives an instant summary, and every subsequent sentence delivers specific, non-redundant information. The structure makes scanning easy despite the complexity.

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?

Given the tool's complexity (6 actions, 8 parameters, no output schema), the description is remarkably complete. It describes return behavior for most actions (grouping by type, fallback size/modified time, embedding names, updated config view, generic categories for list_paths) and explains side effects (restart needed, unlink bypassing recycle bin). No critical aspect—safety, scope, or constraints—is left unexplained.

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 semantics beyond the schema. It explains the dual meaning of `path` (model file vs directory per action), how `target` resolves live configs, and that `action` drives the entire behavior. It also describes nuances like path resolution across extra_model_paths.yaml roots and the distinction between deleting a file vs editing YAML, which the schema alone does not convey.

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 clear, specific statement: 'Inspect what models this ComfyUI has installed, and where it looks for them' — a concrete verb+resource+scope. It then enumerates six distinct actions under the same tool, making it obvious what each invocation does. It also distinguishes itself from the sibling download_model tool by pointing users there for searching and fetching new models, avoiding confusion.

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?

Explicit guidance is provided throughout: '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.' The description also warns against confusing remove with remove_path, tells users to confirm the exact path before calling remove, and explains when to use standalone/desktop config targeting. Alternatives and exclusions are clearly stated.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/artokun/comfyui-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server