Skip to main content
Glama

list_packs

List the bundled ComfyUI installer packs, each with a ready workflow and manifest for a model family. Check available packs to choose the right local setup and build on your live canvas.

Instructions

Bundled ComfyUI knowledge — installer packs, model-family skills, workflow templates — plus the two workflow-readiness checks. Driven by the action parameter:

  • action:"list" — List the bundled installer packs under packs/: one-command setups for a model family (custom nodes + model weights via manifest.yaml) PLUS a ready workflow.json graph. Each entry reports its family/kind, its runtime (these packs are LOCAL-GPU / FREE — they run on the user's own GPU and never spend paid API credits), whether it has a ready workflow + manifest, and the manifest path for install_comfyui apply_manifest. When asked to "set up / build a workflow", PREFER applying the matching pack and loading its ready workflow (panel_load_workflow pack:) over building a generic graph from scratch. Read the ready graph with action:"read_workflow", and inspect its install manifest with action:"read_manifest".

  • action:"read_workflow" — Return a bundled pack's ready workflow.json graph by pack name (name; discover names + which packs have a workflow with action:"list"). This is the EXPERT graph for that model family — use it as the source of truth when setting up the family on the user's canvas: recreate it node-by-node with the panel_* tools (panel_add_node / panel_connect / panel_set_widget) so it lands on their live canvas, or enqueue it headlessly. Prefer this over inventing a graph from scratch. Names are validated (no path traversal) and must match an existing pack directory.

  • action:"read_manifest" — Return a bundled pack's install manifest (its manifest.yaml — the custom nodes + model weights apply_manifest would install) by pack name (name; discover names + which packs have a manifest with action:"list"). READ-ONLY — the way to INSPECT what a pack will install BEFORE calling the mutating apply_manifest. Names are validated (no path traversal) and must match an existing pack directory.

  • action:"list_templates" — List CUSTOM-NODE-contributed ComfyUI workflow templates on the connected ComfyUI, grouped by source (each pack's own example_workflows/*.json). Hits the live server's /api/workflow_templates index. SCOPE LIMIT: this endpoint does NOT include ComfyUI's own core bundled templates from the comfyui-workflow-templates package (e.g. "Flux.1 Inpaint") — those are served to the frontend as static assets via a separate code path this action cannot see, so a small/empty result here does NOT mean no official template exists, only that no custom-node pack contributed one. When asked to "set up / build a workflow", check here for a custom-node-contributed starter AFTER checking the bundled skills + installer packs (action:"skill_list" / action:"list"), and also tell the user to check the ComfyUI frontend's own Templates browser directly for core templates, since this action cannot enumerate those. NOTE: this lists what's available; loading a template onto the canvas is done in the ComfyUI frontend's Templates browser (the panel agent cannot load a template graph headlessly yet) — surface the matching template name to the user.

  • action:"check_runtime" — Determine whether a workflow runs on the user's OWN GPU (LOCAL — free) or uses hosted API NODES (PAID api credits). Pass pack (a bundled pack name — always local/free) OR graph (a UI or API/prompt workflow JSON, as object or string). It scans the workflow's node class_types against the connected ComfyUI's API-node set (the same signal list_api_nodes uses) and returns { runtime: 'local'|'api'|'mixed'|'unknown', usesApiNodes, apiNodes[], externalApiNodes[], unknownNodes[] } — 'unknown' means some nodes couldn't be classified (could be paid), so treat it (and 'api'/'mixed') as POSSIBLY PAID; only 'local' is confirmed free. externalApiNodes is the THIRD-PARTY paid kind (a fal.ai-style pack, or any node taking a service credential): those are INSTALLED LOCALLY yet still cost money, billed by that provider on the user's own account with them rather than out of Comfy api credits — so when you ask the user, name the provider, not "Comfy credits" (externalProviders names it when recognised — e.g. ["fal.ai"]; it is absent when the node was flagged only by taking a service credential, which proves it authenticates somewhere but not to whom). ALWAYS call this before building OR loading a non-pack/ad-hoc workflow so you can ASK the user before spending paid API credits — never silently use API nodes.

  • action:"extract_deps" — Analyze a ComfyUI workflow (workflow, API JSON) and determine which custom node packs it requires. Maps each node class_type to its owning node pack using ComfyUI-Manager mappings and the server's installed node definitions, reporting which packs are installed vs missing. READ-ONLY — it installs nothing. Works remotely (HTTP only) — mirrors comfy-cli node deps-in-workflow.

  • action:"install_deps" — MUTATING: this is the ONE action on this tool that INSTALLS anything. Resolve and INSTALL the custom node packs a ComfyUI workflow (workflow) requires, via ComfyUI-Manager: it determines the missing packs, resets the Manager queue, QUEUES THE INSTALLS, starts the worker, and reports what was installed/already-present/unresolved. Installing a pack downloads and runs third-party code (and may pull large files) on the connected ComfyUI host — local OR remote --comfyui-url — and a ComfyUI restart is typically needed before new nodes load. Use action:"extract_deps" first if you only want to SEE what is missing. Mirrors comfy-cli node install-deps.

  • action:"skill_list" — List the bundled ComfyUI model-family + workflow skills shipped with comfyui-mcp (name + description for each). These encode per-family expertise (e.g. krea2-txt2img: native krea2 CLIPLoader, Qwen3-VL encoder, 8-step turbo settings) and the installer-packs system. Call this BEFORE hand-building a workflow from scratch — if a matching skill exists, read its full guidance with action:"skill_read" and prefer a ready installer pack (action:"list") over a generic graph. Claude loads these natively; this action gives the SAME knowledge to any MCP client (e.g. the Codex backend).

  • action:"skill_read" — Return the full body of a bundled skill's SKILL.md by name (name; discover names with action:"skill_list"). Gives you the family's complete expertise on demand — model slots, node graph, recommended settings, and gotchas — so you can build the right workflow instead of guessing. Names are validated (no path traversal) and must match an existing skill directory.

  • action:"generate_skill" — MUTATING: it WRITES to the read-through skill cache on every cache miss, and when install_in is set it ALSO creates that directory and overwrites any SKILL.md in it. Generate a Claude skill (SKILL.md) documenting a ComfyUI custom node pack: its nodes, inputs/outputs, and example workflows. source accepts a ComfyUI Registry ID (resolved via api.comfy.org) or a GitHub repository URL. Uses a read-through cache under ~/.comfyui-mcp/skill-cache (override COMFYUI_SKILL_CACHE_DIR); set refresh:true to bypass it. On cache miss, fetches the repo README and scans its Python NODE_CLASS_MAPPINGS and example workflows over the network (uses GITHUB_TOKEN if set to avoid rate limits), so internet access is required. If a ComfyUI server is reachable it enriches node input/output types from /object_info, but the server is optional. Returns the SKILL.md markdown with structured cache metadata; if install_in is set, also creates that directory (recursively) and writes SKILL.md there, overwriting any existing file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoREQUIRED for action:"read_workflow" and action:"read_manifest" — the pack name (a directory under packs/, e.g. 'krea2-txt2img-manual'), from action:"list". REQUIRED for action:"skill_read" — the skill name (a directory under plugin/skills/, e.g. 'krea2-txt2img'), from action:"skill_list".
packNoaction:"check_runtime" — a bundled pack name (from action:"list"). Packs are local/free; this confirms it from the actual graph.
graphNoaction:"check_runtime" — a workflow graph to classify (UI or API/prompt format), as an object or a JSON string. Use this for ad-hoc/generated workflows.
actionYesWhich knowledge operation to perform. "list", "list_templates" and "skill_list" take no other parameters; "read_workflow", "read_manifest" and "skill_read" require `name`; "check_runtime" takes `pack` OR `graph`; "extract_deps" and "install_deps" require `workflow` (and "install_deps" INSTALLS custom nodes — the only action here that installs, though "generate_skill" also WRITES to disk: its skill cache on every miss, plus `install_in` when set); "generate_skill" requires `source` (optional `install_in`/`refresh`).
sourceNoREQUIRED for action:"generate_skill" — a ComfyUI Registry node ID (e.g. 'comfyui-impact-pack') or a GitHub repository URL.
refreshNoaction:"generate_skill" — bypass the read-through cache and rebuild the SKILL.md, overwriting the cached entry.
workflowNoREQUIRED for action:"extract_deps" and action:"install_deps" — a ComfyUI workflow in API format (JSON string or object).
install_inNoaction:"generate_skill" — optional directory to write the generated SKILL.md into. Created recursively if missing; an existing SKILL.md is overwritten. Omit to only return the markdown without touching disk.
Install Server

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does this thoroughly: it flags mutating actions ('MUTATING: this is the ONE action on this tool that INSTALLS anything', 'MUTATING: it WRITES to the read-through skill cache'), notes read-only actions ('READ-ONLY — it installs nothing', 'READ-ONLY — the way to INSPECT what a pack will install BEFORE calling the mutating apply_manifest'), and discloses side effects like 'Installing a pack downloads and runs third-party code (and may pull large files) on the connected ComfyUI host' and 'a ComfyUI restart is typically needed before new nodes load.' It also explains the 'externalApiNodes' nuance and the 'unknown' runtime classification, which is critical for cost transparency.

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 description is long (over 1000 words) but densely packed with essential information. It is structured with clear action headers and bullet points, making it scannable. Each sentence earns its place: it covers purpose, usage, side effects, and alternatives for each action. However, it is verbose in places, e.g., the 'check_runtime' section repeats the 'externalApiNodes' explanation twice. It could be tightened without losing value, but the structure is exemplary for a multi-action tool.

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 (10 actions, 8 parameters, no output schema, no annotations), the description is remarkably complete. It covers all actions, parameter interactions, side effects, cost implications, and alternatives. It even explains the return structure for 'check_runtime' and the 'externalProviders' field. The only minor gap is that it doesn't describe the exact return format for 'list' or 'skill_list', but the output schema is absent and the description gives enough context for the agent to infer. The description fully compensates for the lack of annotations and output schema.

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

Parameters4/5

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 description adds significant value beyond the schema: it explains the action-specific parameter requirements (e.g., 'action:"check_runtime" takes `pack` OR `graph`'), clarifies the meaning of 'name' for different actions, and provides examples ('e.g. "krea2-txt2img-manual"'). It also explains the 'externalProviders' field in the return value, which is not in the schema. However, some parameter semantics are only implied (e.g., 'refresh' is described in the schema but the description adds the 'bypass the read-through cache' context, which is already in the schema description). The description does not add much for 'install_in' beyond the schema, but overall it enriches the parameter understanding.

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 clearly states the tool's purpose: 'Bundled ComfyUI knowledge — installer packs, model-family skills, workflow templates — plus the two workflow-readiness checks.' It enumerates ten distinct actions, each with a specific verb and resource (e.g., 'List the bundled installer packs under packs/', 'Return a bundled pack's ready workflow.json graph'). It distinguishes from siblings by naming alternatives like 'install_comfyui apply_manifest' and 'panel_load_workflow', and by referencing the 'panel_*' tools for canvas operations.

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?

The description provides explicit when-to-use guidance for each action. For example, it says 'When asked to "set up / build a <model-family> workflow", PREFER applying the matching pack and loading its ready workflow... over building a generic graph from scratch.' It also gives exclusions: 'SCOPE LIMIT: this endpoint does NOT include ComfyUI's own core bundled templates...' and 'ALWAYS call this before building OR loading a non-pack/ad-hoc workflow so you can ASK the user before spending paid API credits.' It names alternatives like 'action:"extract_deps" first if you only want to SEE what is missing.'

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

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