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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive, and the description adds substantial behavioral context: independent fetching per source, per-value citations, spread calculation, methodological rather than error-based differences, and resilient handling of down sources. This goes well beyond the structured annotations.

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?

Every sentence earns its place: function, concrete examples, use cases, interpretation caveat, expected output, and failure behavior. The most important action and scope are front-loaded, and the description is dense without being bloated.

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 read-only comparison tool with no output schema, the description covers what the result contains (values, citations, spread, definitions), how to interpret differences, and what happens when sources fail. An agent has enough context to select and invoke 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 description coverage is 100%, so the schema already documents indicator, country, and period. The description reinforces the single-indicator/single-country scope and gives indicator examples, but does not add meaningfully beyond what the input schema already provides. Baseline 3 is appropriate.

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 ('Fetch...from EVERY official source...independently') and resource ('one indicator for one country'), with concrete examples and the side-by-side plus spread output. Clearly distinguishable from siblings like get_indicator or get_series, which retrieve single series rather than cross-source comparisons.

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?

Explicitly says when to use: when sources disagree, when you need to know which official number to cite, or to assess methodological gaps. It gives clear context but does not name alternative sibling tools or state when not to use it, so it stops just short of full routing guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral context: data sources (World Bank, IMF DataMapper API), current vintage, and the fact that each value carries its own citation. No contradictions with annotations.

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 well-structured and efficient: purpose, indicator list, sources, and use case are all covered in a compact block. Every sentence adds value and 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 simple single-parameter, read-only snapshot tool with no output schema, the description gives a complete picture: what indicators are returned, where the data comes from, and how results are cited. An agent has enough information to select and invoke it 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?

The input schema fully documents the only parameter (country: ISO3/ISO2 code or English name), so schema coverage is 100%. The description adds no additional parameter semantics, but none are needed.

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 clearly states this is a one-call snapshot for a country's headline economic picture and enumerates the exact indicators included (GDP, inflation, unemployment, etc.). It distinguishes itself from sibling tools like get_indicator or get_series, which target individual indicators or series.

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 explicitly states the ideal use case: 'Ideal for country briefs and report openers.' This provides clear context for when an agent should choose this tool, though it does not explicitly discuss alternatives or when not to use it.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, indicating safe, non-destructive, idempotent behavior. The description adds that it returns observations and citation as text, providing useful behavioral context beyond annotations.

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?

Two sentences, each providing key information: what the tool does and what it returns. No extraneous words, front-loaded with the most important information.

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?

Given the existence of an output schema (not shown but indicated), the description does not need to detail return structure. It mentions observations and citation, which is sufficient for a simple fetch operation. Could add more on expected usage context but adequate.

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?

Only one parameter 'id' with 0% schema description coverage. The description compensates by specifying the expected format ('indicator/<key>/<ISO3>'), which adds essential semantic meaning beyond the bare schema.

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 clearly states it fetches full data for a result id from search, with specific format 'indicator/<key>/<ISO3>'. It distinguishes from search (which returns ids) by providing full data, and from similar tools like get_indicator by specifying return of observations and citation.

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 description explicitly states this tool is for result ids returned by search, implying usage after search. It does not provide explicit when-not or alternatives, but the sibling context and timing imply appropriate usage.

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

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

Annotations already carry readOnlyHint=true, idempotentHint=true, and destrructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the two-regime rate regime, temporal coverage ('any date since 1999'), and the promise that output states method and citations explicitly. No contradiction with the annotations.

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?

Three sentences with zero waste: the main operation and sources are front-loaded, the output behavior (explicit method/citations) earns its sentence, and the date-format instruction is placed last where it reads as a takeaway. Every sentence adds information; nothing is repeated from the schema or title.

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 no output schema, the description carries the return-value burden and addresses it by stating the conversion result includes explicit method and citations. It covers what, which sources, which currencies, which dates, and how to format dates. Minor gaps remain around edge cases (unsupported codes, weekend dates for ECB) but nothing an agent needs for correct invocation is missing.

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?

While schema coverage is 75%, the description adds meaning the schema lacks: it maps from/to ISO codes into two concrete currency classes (the ~30 ECB majors vs the ~90 World Bank currencies like BBD, XCD, JMD, KES), and it clarifies the date parameter's dual format semantics and temporal reach. The 'amount' parameter remains implicitly defined (the number to convert), which is a minor gap at this coverage level.

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+resource ('Convert an amount between currencies') and goes further by naming the two official rate sources (ECB daily, World Bank annual-average). It is immediately distinguishable from siblings like inflation_adjust (inflation adjustment) and get_series/get_indicator (data retrieval), so an agent can tell what this tool uniquely does without opening the schema.

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 description gives clear usable context: it tells the agent which date format to pass ('YYYY-MM-DD' for daily, 'YYYY' for annual-average) and ties each format to a currency class (~30 ECB majors vs ~90 World Bank currencies). It stops short of explicit exclusions or routing to alternatives such as inflation_adjust, but the invocation context is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, lowering the burden. The description adds useful behavioral context: results are official values and include a full citable reference. The schema's strict_source parameter already documents the fallback behavior, so no contradiction or hidden side effect is left unaddressed.

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?

Four tight sentences with the core purpose front-loaded, followed by useful scope examples, return-value detail, and routing guidance. No filler; each sentence contributes to a clear mental model.

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 7-parameter tool with no output schema, the description covers the essential context: what it returns, input formats, and when to use it. Remaining details like transform options, fallback semantics, and year filters are fully specified in the schema, so nothing critical is missing.

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's comments about ISO3 codes/plain country names and indicator examples largely restate what the schema already provides, adding no significant parameter-level meaning beyond the structured definitions.

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 uses a specific verb ('Get'), a specific resource ('official values for a common economic indicator'), and a concrete deliverable ('observations plus a full citation'). It also differentiates itself from the sibling search_indicators by telling the agent to start here and route there when the indicator key is unknown.

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?

Explicitly says 'Start here for most questions' and names search_indicators as the alternative when the indicator key is uncertain, giving a clear decision rule. This is strong routing guidance even though it doesn't enumerate every sibling exclusion.

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

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

Annotations already signal read-only, idempotent, open-world, non-destructive behavior. The description adds materially beyond that: FRED ids return an explanatory disabled response and are never retrievable, country is required for certain prefixes, DBnomics supports dated editions for vintage-pinned reproducibility, transforms are supported, and every response includes a full citation. This gives agents critical behavioral expectations not derivable from annotations or schema.

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 dense but every sentence earns its place: purpose, id formats, required-country caveats, disabled FRED behavior, transform/year support, citation guarantee, and sibling routing. It is front-loaded with the main action and uses compact examples instead of rambling.

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 6-parameter read-only data fetch with no output schema, the description covers id construction, prerequisites, disabled paths, transforms, year filters, reproducibility, citation behavior, and tool preference. It does not specify output shape or date-filter edge cases, but the rich caveats make false assumptions unlikely. Slightly short of 5 due to no explicit statement of what a successful response actually contains aside from the citation note.

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?

With only 50% schema description coverage, the description compensates well: it explains the series_id syntax for worldbank, imf, dbnomics, and fred; states which prefixes need a country; and clarifies the strict_source behavior. It also names the transform values that match the enum. Minor gap: no explicit meaning or bounds for start_year/end_year, but the overall parameter picture is far stronger than the raw schema alone.

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?

Purpose is explicit and specific: 'Fetch any supported series by explicit id' names the verb, resource, and id-based access mode. It also distinguishes itself from get_indicator by framing this as raw series access, and the 'Prefer get_indicator' line clarifies its niche among siblings.

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 description gives clear usage context: when to use series ids by source, which prefixes require country, which ids are disabled (FRED), and when to prefer get_indicator. It does not enumerate all sibling alternatives or exhaustively say when not to use this tool, but the get_indicator guidance plus the explicit id-scoping is sufficient for most agent routing decisions.

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

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

Annotations already indicate a read-only, idempotent, non-destructive operation. The description adds valuable behavioral context by detailing the exact return values (adjusted amount, index values, formula, citation) and noting annual-average precision, which goes beyond the structured annotations.

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 concise, with two sentences that front-load the primary purpose, include an illustrative example, and convey key details about country support, return values, and precision. No redundant 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?

The tool has no output schema, so the description's mention of return values and precision is important. It covers the core function well, but does not mention potential limitations such as year range constraints or data availability, which would be useful for full completeness.

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 25% (country has a description). The description compensates by explaining amounts and years via the example and stating the default country. It does not detail each parameter individually, but the provided context is sufficient for a user to infer correct usage.

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 clearly states the tool converts a nominal amount between years using official CPI, with a concrete example ('what is 100 in 1995 money worth in today's money?'). This specific verb+resource combination distinguishes it from siblings like fx_convert, which handles currency conversion.

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 description implies when to use it (inflation adjustment for any country with CPI data, default USA) and provides an illustrative example. However, it does not explicitly mention alternatives or exclusions, such as using fx_convert for currency exchange rather than inflation adjustment.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond those annotations: it identifies the exact upstream sources, notes DBnomics as a vintage-pinned fallback, and explicitly states FRED is disabled. This gives an agent useful operational knowledge.

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 a single dense sentence that front-loads the core purpose and packs in the source list, fallback behavior, and disabled source. It is not bloated, though it could be slightly more readable if the source list were structured as a bulleted enumeration.

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 zero-parameter, read-only listing tool with no output schema, the description fully covers what the agent needs to know: what the tool returns, which sources are included, what licensing/attribution information is provided, and relevant caveats such as the fallback and disabled source.

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?

The tool has zero parameters and the schema is an empty object, so there is nothing for the description to clarify. The 0-parameter baseline of 4 applies, and the description does not introduce any param-related confusion.

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 clearly states the tool lists official sources behind StatCite, what each covers, its license, and attribution rules. It uses a specific verb+resource and is distinct from sibling tools like compare_sources, which implies comparison rather than a simple inventory.

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 description gives clear context: use this when you need the official source list, coverage, licenses, or citation/attribution lines. It does not explicitly name alternatives or exclusions, but the tool's narrow scope and zero-parameter interface make the intended usage obvious enough.

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

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

Annotations already cover safety (readOnly, idempotent, openWorld). Description adds that it returns result ids for passing to fetch and deep-research orientation, which goes beyond annotations without contradicting them.

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?

Two short, front-loaded sentences with no filler. Every word adds value.

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?

Given the simple tool (1 param, no nested objects), the description covers purpose, input, output (returned ids), and usage context. Output schema exists but isn't shown; the description partially compensates by noting the result format.

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 has one 'query' parameter with no description. Description adds free text examples, giving practical guidance. However, no format constraints (e.g., boolean operators) are mentioned, leaving slight ambiguity.

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?

Clearly states the action ('Search'), the resource ('official economic statistics'), and the method ('by free text'). Provides concrete examples. Distinguishes from sibling tools like get_indicator/get_series.

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?

Explicitly says 'Designed for deep-research connectors; for richer control use get_indicator / get_series', giving clear when-to-use and when-not-to-alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by specifying the return contents (indicator keys, units, source notes) and the curated source scope, going beyond what the annotations alone convey.

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 a single information-dense sentence that front-loads the tool's purpose and registry scope. The punctuation around the topic list is slightly awkward, but every part contributes meaning and there is no redundant filler.

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?

Given the low parameter count, no output schema, and straightforward search behavior, the description covers the essential context: source universe, query semantics, return format, and downstream tool integrations. It does not address pagination or result limits, but these are minor for this tool's simplicity.

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% and the query parameter already has a clear description with examples. The tool description adds value by listing specific searchable topics ('inflation', 'debt', 'unemployment', 'poverty') and clarifying the query's role as a free-text topic search, reinforcing rather than merely repeating the schema.

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 ('Search') and a well-scoped resource ('StatCite's curated indicator registry'), naming explicit sources (World Bank WDI, IMF DataMapper/WEO/Fiscal Monitor) and the ability to discover DBnomics datasets. It also clarifies what the tool returns — indicator keys usable with get_indicator/verify_stat — which helps distinguish it from the generic sibling 'search'.

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 description clearly implies when to use this tool: when looking up indicators by topic before retrieving them via get_indicator or verifying them with verify_stat. It gives concrete example topics and mentions dataset discovery, but it does not explicitly state when not to use it or contrast it with the generic 'search' sibling.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, and the description adds substantial behavioral context on top: the honesty contract ('never a guessed verdict'), error isolation ('reports its error in place without sinking the rest of the batch'), ordering ('results come back in input order'), and strict-source fallback behavior. This goes well beyond what annotations convey.

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 sibling distinction, then adds dense, non-redundant behavioral and usage details. Every sentence earns its place: batching rationale, verdict engine equivalence, honesty contract, batch limits, ordering, and error isolation are all useful and specific.

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 what the tool does, when to use it, how to batch claims, error behavior, fallback semantics, and output characteristics. Since an output schema exists, detailed return-value explanation is unnecessary, and nothing essential for correctly selecting or invoking this tool is missing.

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 adds meaningful context by explaining the claims array's purpose ('extract every checkable macro claim from the text'), the rationale for the 15-item cap ('free-tier subrequest budget'), and the batch behavior tied to strict_source. It does not deeply redefine each parameter, but it enriches the schema's already strong descriptions.

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 and resource: 'Fact-check a whole draft or report in one call' and explicitly contrasts itself with verify_stat by saying 'instead of calling verify_stat once per figure.' This clearly differentiates the batch tool from its sibling and tells an agent exactly what it does.

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 explicit when-to-use guidance by naming verify_stat as the alternative and explaining the batch approach. It also provides concrete usage limits and splitting instructions: 'Accepts 1–15 claims per call' and 'Split larger drafts into multiple calls of up to 15.'

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

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.