local-comfyui-mcp

Overview Schema Source Related Servers Discussions Admin

install_extension

Install a ComfyUI node pack from the Comfy Registry safely: preview the plan with dry_run, get an automatic checkpoint, and refuse unsafe installs before fetching.

Instructions

Install a node pack from the Comfy Registry, with a checkpoint and a refusal first.

The order is the whole design. What installing a pack does to this machine is almost never about the pack's own files - those are a folder that set_extension_enabled can hide again in one rename. It is about the packages its requirements move, and that is irreversible without a record. So: the plan is read before anything is fetched and an unsafe one is refused outright; a checkpoint is written whether or not anyone asked; and the difference the install actually made is measured afterwards rather than taken from the plan.

The fetching is ComfyUI-Manager's and the packages are this server's. Manager resolves the registry id, downloads the archive and places it with its own conventions - reimplementing that would be a second set of conventions for the same folders. But its post-install step pip-installs requirements.txt one line at a time with nothing watching torch, and runs the pack's own install.py, which is arbitrary code. This asks it to skip that step and does the package half here.

Two consequences to know about, both reported in the reply rather than hidden:

A pack shipping install.py is only partly installed by this route. That script is not run. Most packs do not have one; a pack that does may need a person.
Packages that move an already-installed version are not installed while ComfyUI is running, because it has them loaded and replacing a loaded file fails on Windows. The pack lands, the packages wait, and repair_extension finishes the job with ComfyUI stopped.

Args: name: the pack's registry id, or something that identifies one entry. Ambiguity is refused rather than guessed at. version: which released version, or "latest". Not a git ref - Manager rates every nightly and every unknown git URL as high risk and refuses them at the usual security level, and this server does not work around that. dry_run: read the plan and stop. Nothing is fetched, nothing is written, and no checkpoint is taken. This is the call to make first.

Input Schema

TableJSON Schema

Name	Required	Default
`name`	Yes
`dry_run`	No
`version`	No	latest

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.10Sep 13, 2026

TDQS

A4.6/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 burden and does so richly: it discloses that a plan is read and unsafe plans refused, a checkpoint is always written, the pack's install.py is NOT run, and packages that would replace a loaded version are deferred until ComfyUI stops. These are exactly the irreversible/side-effect facts an agent needs before invoking.

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 purpose is front-loaded and every section is content-bearing, but the definition is long and editorial ('The order is the whole design', 'the fetching is ... and the packages are ...'), with a lot of prose the agent must wade through before reaching the Args. It earns most of its length but is not tightly sized.

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 complex, side-effecting install tool with no annotations, the description covers mechanism, ordering guarantees, deferral conditions, and failure modes; an output schema exists so return details need not be explained, and it notes the consequences 'reported in the reply'. Nothing essential to correct invocation is missing.

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 description coverage is 0%, so the description must compensate, and it documents all three parameters in the Args block: name (registry id, ambiguity refused), version (released version or 'latest', explicitly not a git ref), and dry_run (read plan and stop, nothing fetched/written). This fully compensates for the empty schema.

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 opening line states a specific verb and resource ('Install a node pack from the Comfy Registry'). It explicitly names sibling tools it does not do the job of (set_extension_enabled hides files in one rename, repair_extension finishes the package half), so an agent can distinguish it without opening the 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?

The dry_run arg guidance is explicit routing ('This is the call to make first'), and repair_extension is named as the follow-up when packages wait for a stopped ComfyUI. It does not, however, contrast with stage_extension, update_extension, or search_extensions, so the sibling-selection picture is incomplete.

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

Deploy Server