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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the description earns credit for adding the paid-call detail ($0.002 USDC via x402), which is genuine cost context. However, it does not disclose that the tool is multi-mode and that the mode is selected implicitly by which parameters are supplied, which is important behavior for a zero-required-param tool.

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?

A single dense sentence, front-loaded with the tool's identity and capability groups, with the cost caveat at the end. The parenthetical lists are long but each element carries information; nothing is redundant.

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 10-parameter, three-mode tool with zero required parameters and no output schema, the description omits the most critical thing: how to select a mode and which parameters each mode consumes. The agent cannot reliably construct a valid call from this description plus the sparse schema.

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 only 40% across 10 parameters, so the description must compensate, and it largely does not. It adds useful category detail (which unit families and date operations are supported) but never explains the core mapping of expr/value/from/to/date/date_op/days/months/years to a given mode, leaving mode selection ambiguous.

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 specific verb+resource ('Exact calculator') and enumerates three concrete capability families: math expressions, unit conversion, and date arithmetic. It does not, however, name or differentiate against obvious siblings such as unit_convert, convert, or dates_business_days, so the agent must infer overlap itself.

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?

Usage is only implied by listing capabilities; there is no explicit when-to-use, when-not, or alternative routing despite several siblings covering unit conversion and business-day date math. An agent gets a rough sense of scope but no guidance on choosing this over unit_convert or dates_business_days.

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