Prepare PCB Auto-routing or Unrouting

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

Beyond the annotations, the description discloses meaningful behavior: there is a safety preview, an 'exact confirmation phrase' is required, and nothing is mutated until confirmation — this explains why readOnlyHint=true can coexist with a routing operation. It also flags that 'unroute' is destructive, which is context the destructiveHint=false annotation alone would hide. It does not say what the preview contains or how the confirmation phrase is obtained.

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?

A single dense sentence, front-loaded with the operation and followed by scope, safety behavior, and the non-mutation guarantee. Every clause carries information; nothing is redundant with the title.

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 6-parameter mutation-preparation tool with a nested target object and no output schema, the definition omits what the preview/response looks like and how the confirmation phrase is produced or passed on. It covers risk and scope well but leaves the agent unsure how to finish the flow.

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 83%, so the schema already documents nets, ignoreNets, action and keepExistingRoutes. The description adds only the notion of 'explicit nets scope', with no guidance on the target object, timeout, or how ignoreNets interacts with nets. Baseline 3 applies when the schema does the heavy lifting.

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 ('Prepares') plus the resource ('auto-routing or destructive unrouting of tracks/vias') and its scope ('active PCB canvas with explicit nets scope'), so an agent can tell it apart from read-only siblings like easyeda_get_routing_status or easyeda_get_pcb_tracks. It does not explicitly distinguish itself from adjacent prepare tools such as easyeda_prepare_pcb_layout or easyeda_prepare_pcb_track_via, which keeps it below a 5.

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?

'Does not modify the PCB until confirmed' implies a two-step prepare-then-confirm workflow, but the description never names the follow-up tool (easyeda_confirmed_action / easyeda_get_mutation_result) nor states prerequisites such as inspecting routing status first. Usage is implied rather than instructed, and there are no when-not-to-use conditions.

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