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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write-but-non-destructive profile is known. The description adds genuinely new behavioral facts: validation is skipped ('Nothing is checked here'), nets must pre-exist on the board, and sizes inherit from the board's current track/via defaults. It does not contradict the annotations, though it omits permission requirements and confirms the ripup undo path without detailing reversibility limits.

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?

Four compact sentences, each earning its place: what it makes, how sizes default, the pre-condition, and the post-conditions. The core purpose is front-loaded before caveats.

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?

With no output schema and only a wait_s/job-follow-up mechanism documented in the schema, the description supplies the missing workflow context (validate with run_drc, undo with ripup_routing) plus defaults and pre-conditions. An agent could still want explicit return/status behavior beyond the schema's wait_s note, but the definition is substantially complete for a manual-edit tool.

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 only 50%, so the description must compensate, and it does for the key gaps: it explains that width_mm, diameter_mm and drill_mm default to the board's current track/via sizes (functional defaults absent from the schema) and that nets must exist. It does not clarify the layer pattern for tracks or the points array shape beyond what the schema documents.

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 ('Lay exact copper by hand', tracks as polylines on a copper layer, and through vias) and positions it against the automated router siblings by scoping it to 'where the routers leave a gap'. An agent can distinguish this from route_board, add_project_files, or fill_zones without opening a 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?

Gives clear when-to-use context (manual copper where routers leave a gap) and names the lifecycle neighbors explicitly: run_drc afterwards to validate, ripup_routing to undo. It never names route_board/auto_place as the 'don't use this' alternative, so the exclusion is implied rather than stated.

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