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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that computation is 'Local' (no external calls) and, importantly, enumerates the four returned quantities with units — valuable since there is no output schema. It stops short of stating return structure or precision/rounding.

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?

Two tightly packed sentences: the first identifies the tool and its domain, the second lists the outputs. No filler, no restatement of the title, and the most identifying information leads.

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, the description correctly compensates by naming the return values and their units, and the eight parameters all carry defaults so the tool is callable with no arguments. It does not explain how microstrip vs stripline affects required inputs (e.g., whether spacing is only used for differential) or the response shape, which keeps it short of a 5.

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 88%, with units and reference values given inline for nearly every parameter (Er, copper weight, dielectric height, temp rise). The description adds no per-parameter meaning beyond that, so the baseline 3 for high schema coverage applies.

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 states a specific verb and resource — 'PCB transmission-line impedance & IPC-2152 trace current calculator' — and then enumerates exactly what it computes: microstrip/stripline Z0, edge-coupled Zdiff, propagation delay in ps/mm, and recommended width for a target impedance or DC current. This is far more specific than any sibling in the list, which are board analysis, routing, or payment/fab tools.

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 word 'Local' implies an offline, self-contained calculation with no board file or network dependency, which is useful context, but the description never states when to reach for this versus a board analyzer like analyze_kicad_pcb, nor any explicit exclusions or prerequisites. Usage is inferable from the calculator framing rather than stated.

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