Skip to main content
Glama

install_custom_node

Manage ComfyUI custom node packs: install, update, repair, enable/disable, uninstall, list, and sync dependencies.

Instructions

Install, repair, enable/disable and remove ComfyUI custom node packs on this ComfyUI. To FIND a pack in the public registry first, use search_custom_nodes. Driven by the action parameter:

  • action:"install" — Install a pack by registry id, git URL, or name. Local installs prefer official comfy-cli when available; remote or CLI-unavailable installs use the ComfyUI-Manager HTTP API. A ComfyUI restart may be required. Targeting the comfyui-mcp sidebar panel pack ('comfyui-agent-panel' / 'comfyui-mcp-panel') is routed through the verified install_comfyui(action:'panel') path (the version is re-read from disk afterwards) and is REFUSED while the panel is version-pinned.

  • action:"update" — Update an installed pack, or pass id:'all' to update every installed pack. Local operations prefer official comfy-cli; remote operations use Manager HTTP. Targeting the sidebar panel pack is routed through the verified install_comfyui(action:'panel') path. While the panel is version-pinned, BOTH a direct panel target and 'all' are REFUSED — 'all' would move the pinned panel too; clear the pin with install_comfyui(action:'panel')(action='unpin') or update other packs individually.

  • action:"reinstall" — Reinstall a pack. Local operations prefer official comfy-cli; remote operations use Manager HTTP. A ComfyUI restart may be required. A panel target is routed through the verified install_comfyui(action:'panel') path and is REFUSED while the panel is version-pinned.

  • action:"fix" — Repair a pack's install and Python dependencies, or pass id:'all' to repair every pack. Local operations prefer official comfy-cli; remote single-pack repairs use Manager HTTP. REFUSES the sidebar panel pack — 'fix' has no verified on-disk check, so use install_comfyui(action:'panel') for the panel — and refuses 'all' while the panel is version-pinned.

  • action:"uninstall" — Uninstall a pack (removes it). IRREVERSIBLE through this tool — for a cleanup audit prefer action:"disable", which is reversible. The pack must be one ComfyUI-Manager tracks: an id that resolves nowhere is REFUSED before anything is queued (a drained queue would otherwise read exactly like a success), and a pack that is on disk but unmanaged is named so you can remove its directory yourself. After the queue drains the installed-pack list is re-read and the pack must be GONE before anything claims 'uninstalled'. A ComfyUI restart is required to unload it fully. REFUSES the sidebar panel pack.

  • action:"disable" — Disable an installed pack WITHOUT removing it — the reversible first step of a cleanup (re-enable with action:"enable"; action:"uninstall" removes a pack outright). Uses the ComfyUI-Manager HTTP API (works against remote instances) or official comfy-cli locally, and re-reads the installed-pack list afterwards so a Manager no-op is reported as NOT disabled rather than as success. A ComfyUI restart is required for the change to take effect. REFUSES the sidebar panel pack.

  • action:"enable" — Re-enable a pack previously disabled with action:"disable". Same Manager/comfy-cli mechanics and the same post-op re-read, so a Manager no-op is reported as NOT enabled rather than as success. A ComfyUI restart is required for the change to take effect. REFUSES the sidebar panel pack.

  • action:"list" — List installed packs with their version and enabled/disabled state. Uses the ComfyUI-Manager HTTP API (works against remote instances); the cm-cli fallback returns names only. Read-only.

  • action:"sync_deps" — Reconcile the Python dependencies of ALL installed packs through official comfy node restore-dependencies. Requires a local ComfyUI install and comfy-cli; takes no other parameters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoThe pack to act on. REQUIRED for actions "install", "update", "reinstall", "fix", "uninstall", "enable" and "disable". For "install" this is a registry id, git URL, or node-pack name (find one with search_custom_nodes); for "update"/"fix" it may also be 'all' (every installed pack); for "update"/"reinstall"/"fix"/"uninstall"/"enable"/"disable" it is a registry id / module name of an INSTALLED pack.
refNoaction:"install" — git ref (commit SHA, branch, or tag) to pin when installing a git URL. Overrides any ref parsed from the URL and any `version` value. Ignored for registry-id installs.
modeNoTwo distinct meanings, one per action group. For actions "install"/"update"/"reinstall"/"fix": the ComfyUI-Manager data source (default 'remote'); 'remote' fetches the live node list, 'local'/'cache' use bundled/cached data. For action:"list": 'default' lists all installed packs, 'imported' lists only those successfully imported this session. Passing a value from the wrong group is refused, naming the ones the action accepts.
actionYesWhich custom-node operation to perform. "install", "update", "reinstall", "fix", "uninstall", "enable" and "disable" require `id`; "list" and "sync_deps" take no required parameters.
sourceNoaction:"install" — how to interpret `id` (default 'auto', which detects git URLs vs registry ids).
channelNoComfyUI-Manager channel name (default 'default').
versionNoVersion to install. action:"install" — e.g. 'latest', 'nightly', or a semver; for git installs this is treated as a git ref unless `ref` is also provided, and registry installs default to 'latest'. action:"reinstall" — version to reinstall (default 'latest').
useCmCliNoPrefer the official comfy-cli subprocess instead of the ComfyUI-Manager HTTP API. Local operations use comfy-cli by default; set false to force Manager HTTP. Requires a local ComfyUI install — for actions "install"/"disable"/"enable"/"uninstall", an unavailable CLI falls back to Manager HTTP automatically (disclosed in the result); "update"/"reinstall"/"fix"/"list" do not fall back.
Behavior5/5

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

With no annotations, the description carries full burden and excels. It discloses irreversibility ('uninstall' is IRREVERSIBLE), restart requirements, fallback mechanics (comfy-cli vs Manager HTTP), post-operation verification (re-reads installed-pack list), and edge-case behavior like a drained queue appearing as success. This is far beyond minimal disclosure.

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, but it is structured as action-specific bullets, front-loaded with the main purpose. Every section adds concrete operational detail (refusals, fallbacks, post-conditions) that would be hard to compress further. It loses one point for overall verbosity—arguably it could be tightened, though the complexity of nine actions justifies much of the length.

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?

For a tool with no output schema, the description thoroughly explains expected result states: re-reads after operations, 'reported as NOT disabled rather than as success', cm-cli fallback 'returns names only', and 'must be GONE before anything claims uninstalled'. It covers edge cases like panel pinning, queue drains, and unmanaged packs, making it complete for an AI agent to invoke safely.

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?

The schema already covers 100% of parameters with detailed descriptions, so baseline is 3. The description adds valuable cross-parameter interactions: 'ref' overrides 'version', 'mode' has distinct meanings per action group with wrong-group refusal, and 'useCmCli' fallback rules differ by action. It doesn't systematically enumerate all params, but it enriches the semantics in context.

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 verb+resource statement: "Install, repair, enable/disable and remove ComfyUI custom node packs on this ComfyUI." It immediately distinguishes itself from siblings by referencing search_custom_nodes for discovery and install_comfyui for panel-specific operations, ensuring no ambiguity about what this tool does versus others.

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 guidance on when to use this tool vs alternatives: "To FIND a pack in the public registry first, use search_custom_nodes" and it repeatedly routes sidebar panel operations to install_comfyui(action:'panel'). It also details refusal conditions (e.g., 'REFUSES the sidebar panel pack' for fix/uninstall/disable/enable) and explains when 'all' is unsafe due to panel pinning, giving clear when/when-not scenarios.

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