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

Annotations only supply the safety triad (readOnlyHint=false, destructiveHint=false, openWorldHint=false); the description adds substantial behavior beyond that: changing copper_layers rebuilds the stackup, tracks on removed layers are reported, and copper_layers=1 forces single-face routing with no vias and removal of copper on the other face. That last point is a genuine side effect an agent must know before setting 1 layer.

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?

Front-loads the purpose and preset semantics before the detail, and most sentences earn their place given 19 parameters and the tricky copper_layers=1 case. The final single-sided-board sentence is long and packs several conditional behaviors together, which costs some scannability.

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 mutation tool with no output schema and 21% schema coverage, the description covers the important behavioral consequences (stackup rebuild, removed-layer reporting, preset precedence) and the route_board/run_drc relationship. It does not describe the return payload or the wait_s/job-follow-up flow, leaving a small gap for an agent that needs to confirm the write succeeded.

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 only 21% across 19 parameters, so the description has to carry weight, and it does by explaining parameter families: min_* board minimums, default_* Default net class, named net classes with wildcard net patterns, and the preset's per-feature limits. It never enumerates the individual min_/default_ fields or the stackup/thickness interplay, so some parameters remain defined only by 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?

Opens with a specific verb+resource: 'Set the project design rules (.kicad_pro) and copper layer count.' It goes on to name the concrete artifacts it writes (.kicad_dru custom rules) and its downstream consumers (route_board, run_drc), so an agent can place it precisely among siblings like check_net_rules and set_keepouts.

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 operating context: route_board routes with these rules and run_drc checks against them, so the agent knows this must be configured upstream of routing/DRC, and 'explicit values override the minimums' resolves preset-vs-explicit precedence. It stops short of stating when to prefer this tool over a sibling or any prerequisites, so it is context without explicit exclusions.

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