local-comfyui-mcp

Overview Schema Source Related Servers Discussions Admin

stage_extension

Clone a GitHub ComfyUI extension into a safe staging directory and report what installing it would change, so you can review risk and Manager compatibility before deciding to install.

Instructions

Clone a repository somewhere safe and report what installing it would mean.

The answer to "this pack is on GitHub and not in the registry", and it deliberately stops one step short of installing. The clone goes to a staging directory that is not custom_nodes, which is the only place ComfyUI looks - so nothing here is imported, no install.py runs, and no package moves. What comes back is what a person needs in order to decide: what the pack says it is, what it would install, what that would move in this environment, and whether ComfyUI-Manager would accept it at the security level this ComfyUI is configured with.

When Manager would refuse it, that refusal stands. Its security_level is the administrator's answer to whether this ComfyUI may install code from an unvetted repository, and there is no tool here that installs one anyway - the decision to go further belongs to a person at a terminal, who can see this report first. That is the whole reason this tool exists rather than a git-and-pip installer.

The rating is a prediction. It reproduces Manager's own get_risky_level against the catalogue on disk, and Manager merges a fresher copy from the network at call time, so this can say "high" where Manager would say "middle" - never the reverse.

Args: url: an https:// repository URL. Only that scheme, because anything else reaches something other than a network fetch and a value beginning - is an option to git rather than a repository. ref: a branch or tag to clone instead of the default branch. refresh: clone again over a copy already staged. Off by default, so asking twice costs nothing and reads what is there.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ref`	No
`url`	Yes
`refresh`	No

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.7/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: the clone lands in a staging directory that is not custom_nodes, nothing is imported, no install.py runs, no package moves, and the security_level refusal stands. It also discloses that the rating is a prediction that can be higher but never lower than Manager's, which is exactly the kind of behavioral nuance an agent needs.

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?

Front-loaded with the core purpose in the first sentence, and each subsequent paragraph adds decision-relevant detail. It is verbose and slightly repetitive (the 'reason this tool exists' sentence restates the one-step-short point), so it is not maximally tight, but little is genuinely wasted.

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?

An output schema exists, so return values need not be spelled out, yet the description still tells the agent what the report contains (what the pack says it is, what it would install, what it would move, whether Manager would accept it). Combined with the mutation-adjacent staging behavior and security policy, nothing needed to call it correctly 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 coverage is 0%, so the description must compensate, and it does for all three params: url is restricted to https:// (with the leading-dash/git-option rationale), ref is a branch or tag replacing the default branch, and refresh re-clones over an already-staged copy and is off by default. This adds real semantics beyond the bare schema types.

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?

States a specific verb+resource (clone a repository to a staging directory) and an explicit scope boundary: it stops one step short of installing, which cleanly separates it from install_extension and describe_extension. The framing 'the answer to "this pack is on GitHub and not in the registry"' pins the purpose precisely.

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?

Gives a clear situational trigger (a pack on GitHub that isn't in the registry) and an implicit boundary against install_extension ('stops one step short of installing'). It explains the security_level refusal policy well, but never names the sibling it hands off to, so the alternative selection is inferred rather than stated.

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

Deploy Server