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

Goes well beyond the readOnly/idempotent annotations: it discloses the answer's shape (a band, not a point), the model's assumptions and their warnings (drum turns, sheath, uniform start, no chemistry), that a supplied calibration replaces the band, and the commercial trait that every call is paid at $5.00 via x402 with no free allowance, including per-item billing in list mode. That payment behavior is invisible in the annotations and is exactly what an agent needs before calling.

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 core answer is front-loaded in the first clause, but the body is a single semicolon-chained paragraph that mixes outputs, warnings, standard comparison, input recital and pricing with no visual hierarchy. The input enumeration largely repeats the schema's own description string, so several lines do not earn their place twice.

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 and a deeply nested, free-form input, the description carries the full burden and does: it enumerates the returned band, the 50/20/10/5 % cases, the curve, the per-temperature times with sources, notes and warnings, plus the AEIC CS8-20 comparison for MV. Cost, calibration override and list-mode billing are all covered.

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 free-form 'input' object is only meaningful through this text: ranges and defaults for tempC (20–80, default 70), target (0.01–0.9, default 0.1), byproduct, compound, heatupH, the 'both or neither' coupling of startPpm/targetPpm, and the calibration sub-fields with fallback behavior. It loses a point only because the same block is duplicated verbatim in the schema's own input description rather than adding fresh meaning.

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 precise verb and resource: how many days an XLPE core stays in the oven until a given share of crosslinking by-product remains, and names the mechanism (Fick diffusion) and coefficient sources. It also explicitly distances itself from standards ('never a standard's result') and from the AEIC printed value, so an agent can tell exactly what this returns versus a generic cable-design sibling.

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?

Applicability is implied rather than stated: MV up to 46 kV, XLPE cores before the metallic sheath, calibration when a factory measurement exists. There is no explicit 'use this when…' or 'do not use when…' and no routing to or from siblings other than design_cable as an input format reference.

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