eda_pcb_document_auto_routing

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It notes the default behavior (routing all unrouted nets when no params) but does not mention side effects (e.g., modifying the PCB), whether the operation is reversible, any need for prior layout, or what the result contains. This is a significant gap for a mutative operation.

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 description is reasonably concise, including a signature line, a Chinese label, remarks, version info, and a returns note. However, it lacks a clear front-loading of the core action, and the structure mixes technical signature with sparse explanatory content, making it acceptable but not optimally organized.

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?

Given the tool's complexity (auto-routing with optional props) and lack of annotations or output schema, the description is incomplete. It does not explain what the result contains, what conditions must be met (e.g., active PCB document), how to specify which nets to route, or how this relates to the broader routing workflow. An agent would have difficulty using this tool correctly.

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?

The description does not explain the IPCB_AutoRoutingProps structure or what parameters can be passed. The input schema's 'args' description is generic ('按官方签名顺序排列的JSON参数数组'), providing no semantic meaning. The only parameter-related info is the remark that omitting props routes all unrouted nets, which is a behavioral hint but not parameter semantics.

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 clearly states the action (auto routing) and the resource (PCB document) via the function signature and the Chinese phrase '自动布线'. The name itself also conveys the purpose. However, it does not explicitly differentiate from sibling tools like clear_routing or import_auto_route_json_file, relying on the name for distinction.

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?

The description provides no guidance on when to use this tool versus alternatives. It only mentions the default behavior when no parameters are passed, but does not explain scenarios where auto-routing would be preferred over manual routing or importing route files, nor any prerequisites like having a PCB document open.

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