calc

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

With no annotations at all, the description carries the full disclosure burden and does well: exactness semantics (fractions/radicals preserved), the full-precision decimal result, the verbatim-copy-never-round contract, and named-step referential scoping. Missing: whether it is pure/side-effect free, the output envelope besides the decimal precision, and any error behavior for bad expressions.

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?

Dense but front-loaded correctly — exactness first, then the capability catalogue, then usage protocol. The function catalogue in the middle is a long list, yet each entry names a real built-in and several carry signatures, so it earns its space. A tighter grouping of the built-ins would improve scannability.

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 a 3-parameter, nested-object, no-annotation, no-output-schema tool, this is close to sufficient: invocation protocol, function discovery, multi-step semantics and result-handling contract are all present. The one remaining hole is `defs`, which is undocumented in both description and schema despite being a nested object.

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 the schema already documents all three parameters, setting the baseline at 3. The description does add real meaning beyond the schema: step ordering and cross-step references in steps, and the ternary form of composite functions. But defs is never explained anywhere, and expr usage is only exampled.

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 opens with a precise verb+resource: "Evaluate a math expression exactly", and immediately names the differentiators (exact fractions, symbolic radicals) that separate it from a plain calculator. The catalogue of built-in function families and the included signature examples make the tool's scope unmistakable.

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?

It gives concrete routing rules for the main ambiguities: use functions() to list names, help("name") for a signature, N(expr, digits) for numeric evaluation rather than norm_cdf, and one multi-step call instead of several. It also prescribes copying the full-precision decimal verbatim. No sibling tools exist, so no alternative-tool exclusions are needed, which caps nothing here and is the only reason it is not a 5.

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