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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description is free to add execution semantics — that figures come from Wai's code and are exact, and that percentages follow the key name. The only notable omission is what happens with an unknown id or malformed inputs.

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 action and scope, and the anti-hallucination instruction is placed at the end where it lands. The exactness claim and the "answer with returned numbers" sentence overlap slightly, costing a bit of tightness.

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 two-parameter tool with a free-form nested inputs object and no output schema, the definition should say more about the return value and about resolving calculator ids and required keys. It covers the core invocation and the exactness guarantee, but discovery and failure modes are left unexplained.

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 adds a small hint about percentage semantics in key names. It does not explain how an agent discovers which input keys a given calculator accepts, which is the main semantic gap for a free-form nested object.

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?

"Run one Wai calculator by its id with its input keys and values" gives a specific verb (run) and resource (a single calculator), which separates it from the list-style sibling wai_calculators. It stops short of naming that sibling explicitly, so an agent still has to infer where calculator ids come from.

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 instruction to answer with returned numbers rather than a pre-call estimate is a real usage constraint, and "by its id" implies you need an id first. However, there is no explicit when-to-use/when-not guidance and no pointer to the sibling tool that supplies calculator ids or their required input keys.

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