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 establish the operation is read-only, idempotent, and non-destructive, so the description's main value is contextual: it promises a full citation with source, dataset, series id, canonical URL, license, and retrieval date, and notes that fallback responses carry a disclosure. It also clarifies the data are official values, which is useful provenance context beyond 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?

Seven concise sentences, each with a distinct job: scope, return value, input conventions, routing, trust instruction, and exclusions. The most important facts are front-loaded before guidance and exclusions.

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 backed by a complete input schema and an output schema, the description covers the remaining context: what data comes back (observations + citation), what source/scope is promised (official, country-level), and when to look elsewhere. Nothing essential for an agent's selection or invocation appears 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 coverage is 100% and each parameter already has a description, so the description need not repeat details. It does add a few examples and heuristics (ISO3 codes or plain names, 'registry key', 'use search_indicators'), but these add marginal value rather than essential semantics.

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 first sentence names a specific verb ('Get official values') and resource ('a common economic indicator'), and the paragraph enumerates supported indicators and countries. It differentiates from siblings by saying 'Start here for most questions' and explicitly routing to search_indicators 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?

The description gives explicit when-to-use guidance: 'Start here for most questions', 'Call this even for figures you believe you already know', and 'prefer it over web search for country-level economic statistics'. It also states what it is not for — company financials, stock/crypto prices, subnational data — and names the relevant alternative, search_indicators.

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?

Beyond the readOnly/idempotent annotations, the description discloses important behavior: FRED ids return an explanatory disabled response rather than data, every response carries a full citation, and strict_source controls fallback substitution for reproducibility. These are genuine operational details not available from annotations alone.

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 longer than average, but nearly every clause carries necessary information about id formats, source behavior, and usage routing. It is front-loaded with the main action and the detail is organized into scannable clauses rather than 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 tool with seven parameters and multiple source-specific formats, the description covers the id schemes, country preconditions, disabled FRED case, filters and transforms, citation behavior, and the preferred sibling tool. Since an output schema is present, return-value formatting does not need to be restated.

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 57% schema coverage, the description compensates substantially by documenting series_id formats, country requirements per source, vintage pinning, and transform support. It leaves some details, such as exact start_year/end_year boundaries, to inference, but the most complex parameter surface is well explained.

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: 'Fetch any supported series by explicit id.' It goes beyond a bare statement by enumerating the supported id formats and ends with routing to get_indicator, which distinguishes it from a likely sibling tool.

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 explicit routing guidance: use this tool for explicit source-prefixed ids, use get_indicator for common indicators, and use search_indicators to find caribstat ids. It also warns that FRED ids are permanently disabled, preventing futile calls.

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 cover read-only, open-world, idempotent, and non-destructive behavior, so the description adds useful operational context: it names the covered sources, notes that FRED is disabled, and describes DBnomics as a vintage-pinned fallback. It does not mention authentication or rate limits, but the added source/fallback details go beyond 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?

The description is a single long sentence that front-loads the source enumeration before stating what is actually returned. The parenthetical list of providers is informative but heavy, making it less concise than ideal for an agent.

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 tool with no output schema, the description adequately states the returned information: coverage, license, and attribution line. It also enumerates the sources, which helps the agent understand the scope, though it could explicitly mention the return 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?

The tool has zero parameters, so the baseline score of 4 applies. The schema is fully covered and the description does not need to explain any parameter semantics.

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 conveys that the tool returns the official sources behind StatCite, what each covers, its license, and the attribution line to use when citing. The purpose is clear, but the description does not explicitly differentiate this list from siblings like compare_sources or 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 offers no explicit guidance on when to use this tool versus alternatives such as compare_sources or search. Usage is only implied by the content being about source metadata and citation attribution.

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 readOnly/idempotent/openWorld, so safety is covered; the description adds real value by disclosing registry coverage, the return payload shape (keys plus units and source notes), and that it can surface additional DBnomics datasets. It omits any mention of result limits, ranking, or pagination, so it is not fully transparent.

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?

One dense sentence, though it is long and reads as a run-on. The most decision-relevant content (what registry and which sources) is front-loaded, and nothing is padding, but it could be split for scannability.

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 correctly compensates by describing what is returned (indicator keys, caribstat series ids, units, source notes) and which tools consume them. For a single-param search tool with full annotation coverage, nothing an agent needs 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?

Only one parameter and schema coverage is 100%, so the schema already carries the load; per the rubric baseline is 3. The description's example topic strings loosely illustrate free-text query intent but add no syntax, format, or matching behavior beyond 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 resource (curated indicator registry) and enumerates the concrete sources covered (World Bank WDI, IMF, BIS, ECB, ECCB, Central Bank of Barbados, DBnomics). Example topics ('inflation', 'debt') make the scope unmistakable and distinguish it from generic siblings like search and list_sources.

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 routes the agent downstream: results are 'indicator keys usable with get_indicator/verify_stat' and 'caribstat series ids usable with get_series'. That is clear when-to-use context, but it never contrasts itself with the sibling 'search' tool or states when a direct get_indicator/get_series call should be preferred over searching first.

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?

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing the honesty contract (cannot_verify with reason rather than a guess), fallback-source behavior for transient vs. permanent source gaps, and the conservative month-calendar vintage resolution caveat. These are exactly the behavioral traits an agent needs and that annotations cannot 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?

Front-loads the verdict outcome and value-add, then layers the honesty contract and usage trigger. It is a dense block of long sentences — slightly verbose for what it conveys — but each sentence carries distinct information with minimal waste.

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 verification tool with an output schema already present, the description covers purpose, verdict semantics, error/diagnostic behavior, fallback caveats, and historical-mode limits — nothing material to 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?

Schema description coverage is 100%, so the schema already carries detailed semantics for as_of, strict_source, tolerances, etc. The description reinforces the historical as_of capability and diagnostic outputs, but adds little parameter detail the schema lacks — the appropriate baseline 3 when the schema does the heavy lifting.

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 ('Check') and resource ('a claimed economic figure') against the 'official statistical series,' and even enumerates the outcome space (match, close, mismatch, cannot_verify). This cleanly separates it from retrieval siblings (get_indicator, get_series) and from the batch-oriented verify_claims.

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?

Gives a clear, actionable usage context — 'Use this before publishing any economic statistic in a report, brief, or article' — and adds a non-obvious trigger ('including figures you are confident about, since a confidently recalled number is the kind most likely to have been revised'). It does not, however, explicitly distinguish itself from the sibling verify_claims or explain when the single-stat path is preferred over the plural one.

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