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

Adds substantial context beyond the annotations: pricing ($0.50 per calculation in USDC via x402), free-tier semantics (verdict counted against the designs' 2 free calls per caller per UTC day), that any paid call answers in full, that a batch of up to 50 items is one payment, and that pdf: true appends a calculation sheet. These are exactly the cost and output-shape facts an agent needs before committing.

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 purpose is front-loaded in the opening clause, which is good. But the definition is a dense run-on that duplicates the entire input schema text already present in the schema descriptions, padding length without adding information.

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-param, nested-object, no-output-schema tool with readOnly annotations, the description covers what the answer contains, cost/free-tier behavior, batch semantics, and the pdf option. Minor gap: the lang parameter (15 languages) is not surfaced in the description, though the schema documents it fully.

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 100%, so the baseline is 3; the description largely restates the input schema verbatim rather than adding meaning. It does add one genuinely new semantic – items are 'always in full, paid per item' – but leaves the lang and spec/design alternative-resolution behavior to the schema alone.

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+resource and enumerates exactly what the calculation returns: tension per segment from either end, sidewall bearing pressure at bends, jam ratio, clearance and fill, against allowable limits with sources and the governing limit. This is clearly distinguishable from siblings like conduit_fill (fill only) or design_cable (design), which an agent can route 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?

Guidance is present for modes (free verdict vs full/paid, pdf adds a sheet, items batch always in full and paid per item), which tells the agent how to invoke at a chosen cost tier. However, it never says when to choose pull_cable over conduit_fill, tray_fill, or design_cable, so selection against siblings 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.