Verify a claimed statistic against the official source

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is clear. The description adds significant non-obvious behavioral context: the honesty contract (cannot_verify rather than guessing), fallback semantics (fallback_used=true, permanent-lack fallback judged normally), and as_of vintage resolution behavior. These go well beyond what annotations alone reveal.

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 description is front-loaded with the core purpose and each subsequent sentence earns its place: outputs, honesty contract, as_of support, and the publishing use case. It is dense but efficient, with no filler or tautology.

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 tool with 8 parameters, a complete input schema, an output schema, and rich annotations, the description covers the essential edge cases: source-down behavior, no-published-value cases, fallback restrictions, and historical vintage checks. An agent has everything needed to call it correctly and interpret its results.

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 baseline is 3. The description reinforces as_of and strict_source but does not add parameter-level meaning beyond what the schema already provides. It does not need to compensate for undocumented parameters.

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 states a specific verb ('Check') and a clear resource (a claimed economic figure against the official statistical series), and enumerates concrete outputs: verdict, official value, difference, diagnostics, and citation. It is unequivocally clear about what the tool does, but it does not explicitly differentiate from siblings such as verify_claims or compare_sources, so it stops one point short of a full 5.

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 an explicit use case: 'Use this before publishing any economic statistic in a report, brief, or article.' It also describes distinct modes (as_of for historical IMF-vintage checks, strict_source for reproducibility). However, it does not name alternative tools or state when not to use this one, so it lacks the exclusions needed for a 5.

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