calculate_copper_pour_current_drop

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description only needs to add context beyond that. It usefully discloses the computed quantities, the pass/fail threshold (current density <= 35.0 A/mm²), and the physical failure it guards against (delamination/blistering), giving the agent a clear model of what the call produces without stating a return format.

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 that front-loads the verb and the primary outputs before the standards and threshold clauses. It earns its length by conveying several distinct facts, though the trailing compliance/threshold clauses make it long enough to be worth splitting.

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 an 8-parameter computation with no output schema, the description names the outputs it returns (IR-drop, Joule heating, bottleneck current density) and the acceptance criterion, which is what an agent most needs. It stops short of describing result structure or units, but with annotations covering safety and the schema covering inputs, the remaining gap is minor.

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 100%, so every parameter is already documented in the schema with units and defaults. The description mentions bottleneck density but adds no syntax, units, or constraints beyond what the schema provides, so baseline 3 is correct.

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 ('Calculate') plus three concrete outputs (DC IR-drop, Joule heating dissipation, bottleneck current density) applied to a clearly scoped resource ('polygon copper pours and power busbars'). This scope distinguishes it from the sibling calculate_ipc2152_trace_current, which handles traces rather than pours/busbars, so an agent can route correctly without opening either 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?

The description anchors usage to standards (IPC-2152 Section 5.0, IEC 60092-352) and to a heavy-load/heavy-copper context, which implies when it applies. However, it never states when NOT to use it or names the sibling alternative (calculate_ipc2152_trace_current) for narrow-trace cases, so routing between the two is left to inference.

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