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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description adds behavior that structured fields cannot: ambiguity is flagged with alternative readings rather than silently guessed, with worked examples ('03/04/2026: March 4 or 3 April?'). It also discloses pricing and quota (first 25 calls/day free, then $0.001 per call via x402), which is material to whether an agent should batch calls.

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 format list is front-loaded and dense, and every sentence carries information (capabilities, ambiguity handling, use case, pricing). It is a single packed block with no headers or line breaks, which makes the cost note easy to skim past, but there is no filler text.

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?

With an output schema present, return structure needn't be described, and the description covers capability scope, ambiguity policy, batch limit, and cost. The main residual gap is error handling for unconvertible values, which is presumably in the output schema but not signposted; otherwise the definition is sufficient to call the tool correctly.

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 75%, so the schema carries most of the load, but the description still adds meaning: it explains why date_order matters (disambiguating 03/04/2026) and illustrates the numeric ambiguity (45000 as Excel date vs Unix seconds) that the auto-detection in numeric_format resolves. The 100-item cap is echoed from maxItems but tied to the batching behavior rather than restated blindly.

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 specific verb and resource ('Detect and convert up to 100 mixed timestamps to UTC ISO 8601') and enumerates exactly which formats are handled (Unix s/ms/µs/ns, Excel serial, FILETIME, ISO 8601, RFC 2822, YYYY/MM/DD, month-name). It is unambiguous what the tool does. It does not, however, differentiate itself from the sibling parse_date_text or timezone_convert, so an agent must infer the boundary from the batch/normalize framing.

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?

'Use for cleaning CSV, log and spreadsheet data' gives a concrete usage context that implies batch, messy-data input. There is no explicit when-not guidance and no sibling is named as an alternative (e.g. parse_date_text for single free-text dates), so routing still requires inference, but the positive guidance is clear.

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