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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context beyond them: no eval()/dynamic code execution, a 32 KB payload cap, 60 RPM rate limit, auth via '?demo=true' or L402 (40 sats), and HTTP 400 on invalid input. These are exactly the runtime constraints an agent needs and cannot get from structured fields.

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?

Front-loaded with the core purpose and keeps usage guidance and constraints in a compact block; nearly every clause carries a distinct fact (capabilities, alternative, limits, auth, error). It is dense to the point of a run-on sentence, which slightly hurts readability, but there is little outright waste.

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?

An output schema exists so return values need not be explained, and the description covers auth, rate/size limits, error behavior, and the alternative tool. The only completeness gap is the inaccurate precision default, which undermines the one parameter detail it does supply.

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 would be 3, but the description actively conflicts with the schema: it says precision_digits 'defaults to 2_decimals' while the schema documents 'defaults to 8_decimals when omitted', and it names the input 'math_formula' whereas the schema property is 'expression'. Contradictory defaults and a mismatched key name risk incorrect invocation, so it scores below baseline.

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 concrete verb+resource ('Strict Shunting-Yard AST arithmetic parser... evaluates algebraic formulas and computes exact financial NPV, Newton-Raphson IRR, Kelly criterion, and dataset stats'), giving a precise scope an agent can recognize. It also explicitly distinguishes itself from the sibling evaluate_ab_statistical_significance. The capability set is clear without opening the 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?

Explicit when-to-use clause ('Use when computing exact arithmetic formulas, cashflow NPV/IRR, or descriptive statistics without LLM floating-point guesswork') plus an explicit alternative and the condition that routes to it ('for running two-sample A/B hypothesis tests, use evaluate_ab_statistical_significance instead'). Nothing 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.