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

With no annotations, the description carries the full burden and does disclose two important traits: the returned fields per zone and that the call is paid ($0.005 via x402/USDC) — a cost signal an agent must know before invoking. It omits error/empty-result behavior, rate limits, and pagination semantics beyond the limit default.

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-loading with 'Use when...' is good, but the clause 'the exact zone name the other routes expect' is repeated almost verbatim in the second sentence, which is real waste in a two-sentence description. The pricing sentence earns its place.

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?

The description covers return fields and cost, which compensates for the missing output schema and annotations. However, it promises turning 'a city or a country' into a zone name while the search parameter is defined as a substring match against the zone name only, so country names would often not match — an unresolved ambiguity for a 3-parameter tool.

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 schema already documents limit, offset, and search with examples, making 3 the baseline. The description adds only light framing ('searches the full IANA list', 'every zone sitting at a given offset right now') without clarifying matching syntax or the offset format beyond what the schema shows.

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 and resource ('searches the full IANA list') and names exactly what each result carries: UTC offset, abbreviation, local time, DST state. It also separates itself from the time_convert/time_now siblings by framing itself as the zone-name lookup the other routes expect.

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?

Two clear entry conditions are given: 'when an agent has a city or a country and needs the exact zone name' and 'to find every zone sitting at a given offset right now'. It falls short of a 5 because the alternative routes (time_convert, time_now) are referenced collectively rather than by name, and no when-not condition is stated.

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