repair_extension

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 well: it reads the on-disk requirements.txt rather than the registry copy, plans before acting, refuses a plan that would move a CUDA-build package, writes a checkpoint, and reports the delta. It also discloses the Windows file-lock failure mode and the 'run with ComfyUI stopped when the plan is not additive' constraint, which is exactly the kind of operational context annotations would otherwise supply.

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 operative statement is front-loaded in sentence one, and the operating constraint is bolded and placed last for emphasis. Some of the prose is stylistically heavy ('The other half of installing, on its own...'), but each sentence still carries usable information.

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?

For a 2-param mutation tool with an output schema already covering return values, the description supplies everything an agent needs: the source of truth for requirements, the refusal/checkpoint behavior, the safety precondition, and both parameter meanings. Nothing material is left to inference.

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 coverage is 0%, so the description must compensate, and it documents both args: `name` is 'the installed pack, by folder name, registry id, or part of either' (a useful matching hint beyond type=string) and `dry_run` is 'read the plan and stop'. It adds real semantics, though it does not spell out the boolean's effect on side effects versus a full run beyond the plan/stop framing.

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?

States a specific verb and resource ('Install the Python requirements of a pack that is already on disk') and immediately frames it against the other install tools ('the half that needs neither ComfyUI-Manager nor a running ComfyUI'). An agent can distinguish it from install_extension and plan_packages without opening any schema.

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?

Explicitly names the two situations that select this tool ('a pack whose import fails for a missing module' and 'an install that deliberately left its packages for later'), which is genuine when-to-use guidance. It stops short of naming the alternative tools by name or stating when *not* to reach for it, so it is clear context without full exclusion rules.

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