install_node

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 thoroughly. It discloses that the tool runs third-party code, asks first, does NOT restart ComfyUI (restart_required is true when anything installs), requires ComfyUI-Manager, and that per-pack failures are reported in 'failed' rather than raised. It also explains the fallback behavior of confirm_install on non-elicitation clients.

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

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

The description front-loads a one-line summary, then uses clear 'Args:', 'Returns:', and 'Gotchas:' headers to organize nuanced information. Every section adds essential operational detail, and the formatting makes the long content scannable. There is minimal redundancy; each gotcha addresses a distinct failure mode.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, no output schema, and no annotations, the description covers all necessary aspects: input formats, required ComfyUI-Manager setup, return dictionary structure, error keys ('unsupported', 'failed'), restart behavior, and how to verify success. It enables an agent to call the tool correctly and interpret results without needing additional documentation.

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

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. It provides detailed semantics for both parameters: 'names' is defined as registry pack ids from nodes/workflow_deps, with explicit exclusions (class names, git URLs, @version pins), and 'confirm_install' is explained as a fallback that should only be True after user agreement, with prompt behavior depending on client support.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Install custom node packs into the LOCAL ComfyUI') and immediately distinguishes itself from siblings by clarifying input types ('registry pack ids ... never a node CLASS name') and pointing to workflow_deps for conversion. It also notes that git URLs and version pins are refused, which differentiates this tool from direct terminal installs. This clearly identifies the tool's purpose among the sibling set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states the correct input ('Feed it registry pack ids ... from nodes / workflow_deps'), what to avoid ('never a node CLASS name', 'a git URL or an @version pin is refused'), and provides alternatives: 'convert it with workflow_deps first' and 'run comfy node install in a terminal for those.' It also explains when confirm_install should be True, giving clear conditional usage.

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