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

The annotations declare destructiveHint=false, but the description says moved or re-netted pads lose copper, copper under a new part is removed, and tracks/vias are ripped. That is a direct contradiction with the destructive hint, so behavioral transparency is scored 1 despite the otherwise detailed disclosure of placement, rip, retention, and refusal behavior.

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 opening sentence front-loads the action and the description is information-dense without marketing filler. The middle sentence is a long, clause-heavy run-on, so it is effective but not maximally clean.

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 complex mutation with no output schema, the description covers the placement strategy, copper preservation and removal, rip-list refusal, job behavior via wait_s, and the summary counts returned. Combined with the schema descriptions for netlist, design_id, remove, and wait_s, an agent has enough to call it correctly apart from the contradictory destructive annotation.

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 high at 86%, so the schema already documents most parameters. The description still adds real semantics for placement behavior—edge placement, board growth, free-room-near-connections, and exact placements—and clarifies the rip-list interaction beyond the schema.

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 names a specific verb and resource: bringing a routed board to a changed circuit/netlist, mapped to KiCad's Update PCB from Schematic plus routing. It also scopes the operation to only open copper, which distinguishes it from a full routing run.

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 establishes the triggering context of a changed circuit/netlist and explains that correct existing tracks are retained, implying this is the update path rather than a fresh route. It does not explicitly name route_board or ripup_routing as alternatives or state when not to use this tool.

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