DatoQA — Economic Indicators

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

Annotations already declare read-only, idempotent, closed-world and non-destructive, so safety is covered. The description adds genuine new context that annotations cannot express: the catalog is static and does not guarantee current availability, so the agent should inspect response status and freshness.

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 sentences, front-loaded with what is returned before the usage rules, and every sentence carries actionable content. Slightly dense with compound clauses, but no wasted 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?

Awareness/discovery tool with an output schema that carries return details, so the description need not document fields. It covers purpose, call/skip conditions, and the static-vs-available caveat; only explicit pagination or size expectations are absent, which is minor for a catalog.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. Schema coverage is 100% for the empty object, and the description correctly signals it is called with no arguments.

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?

It names a specific resource and enumerates exactly what the catalog returns (scope, allowed tool names, source IDs, endpoint, access policy), which distinguishes it from the data-retrieval siblings. The phrase 'this thematic MCP' is mild jargon but does not obscure the purpose.

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 states when to call it (no arguments, when setting up the connection), when to skip it (when the desired tool and inputs are already known), and the narrow secondary use (resolving missing identifiers or coverage). This is a complete usage policy.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely new behavioral context: source flags, missing cells, units and evidence are retained, and the data is not real-time or independently verified. It stops short of describing rate limits or output shape.

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?

A single dense block covering indicators, scope, caveats and the sibling alternative, with no filler sentences. It is front-loaded with the resource list, though the long parenthetical qualifiers for each series make the opening slightly heavy.

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 values need not be described, and the description covers scope, source caveats and the country-code prerequisite. Remaining minor gaps (ordering of 'latest' observations, interaction between limit and frequency) are handled by the schema.

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 all four parameters, including enum values and examples (FR, EL). The description reinforces the frequency/adjustment semantics of the series but adds no syntax or constraint beyond what the schema provides, so the baseline 3 applies.

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 names the exact resource and its three series (HICP inflation, unemployment, real GDP growth) plus the geographic and temporal scope (EU/EFTA, since 2020), which is more specific than most siblings. It does not open with a clear verb like 'retrieve', reading as a noun phrase, so the action itself is implied rather than stated.

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 names the sibling to use for country codes ('Use list_economic_indicators for countries') and states exclusions ('not real-time or independently verified'). That gives clear routing context, though it never explicitly contrasts with get_us_economic_indicators, the closest non-EU alternative.

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, non-destructive, closed-world behavior, so the bar is low. The description adds genuinely new context: the digest attests snapshot integrity only, not factual truth, and the record must be 'currently available' (i.e. still retained).

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 compact sentences with zero filler; the retrieval scope leads and the important integrity caveat is attached immediately afterward.

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?

An output schema exists, so return values need no explanation, and the annotations cover the safety profile. The only meaningful omission is disambiguation from get_record, which would help an agent choose between two similarly named retrieval tools.

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 with 100% schema description coverage, which already explains that the id comes from a DatoQA data response and returns the retained snapshot. The description adds little beyond that baseline, though 'currently available' reinforces the retention precondition.

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 a precise resource: the retained source JSON snapshot plus its SHA-256 digest. It does not, however, contrast itself with the sibling get_record, so an agent cannot tell from the description alone which of the two to call.

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?

Usage is implied rather than stated: 'for a currently available record' signals that the record must still be retained, and the integrity-vs-truth caveat hints at provenance use cases. There is no explicit when-to-use / when-not-to-use rule and no alternative (e.g. get_record) is named.

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/non-destructive safety, so the description correctly spends its budget on traits annotations cannot convey: null values mean missing rather than zero, current- vs constant-dollar series are not interchangeable, and the returned definitions are provenance-original but not independently verified. This is substantive, non-redundant behavioral context.

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?

Six tight sentences, front-loaded with purpose and scope, followed by routing, unit caution, null semantics, and a provenance caveat. Each sentence adds a distinct, actionable fact with no 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?

An output schema exists, so return-value format is covered, and the description supplies the data-quality and unit caveats an agent needs. Its one omission is distinguishing this tool from the other get_*indicators siblings, which matters for correct tool selection.

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 baseline is 3. The description goes beyond the schema by clarifying that the GDP indicator variants carry different units and are not interchangeable, which helps disambiguate the indicator enum values, and by defining the meaning of nulls in the result.

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: 'Annual historical series for one World Bank country and indicator,' with an explicit temporal scope (1960 to last completed year). It is clear what the tool returns, but it does not distinguish itself from the closely-named siblings get_economic_indicators, get_indicators, or get_us_economic_indicators, which an agent might otherwise confuse it with.

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 routes the agent to list_historical_indicators for keys and list_countries for countries, which is genuine prerequisite guidance. It also instructs the caller to pick the GDP variant explicitly and warns the two are not interchangeable. However, it offers no when/when-not framing relative to the other get_*indicators siblings.

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 annotations (readOnly, idempotent, non-destructive), it discloses data-freshness limits ('five completed years only, not real-time'), null-handling semantics ('Null is missing, never zero'), a provenance/verification caveat ('Not independently verified'), and the metadata returned. These are exactly the behavioral traits structured annotations cannot express.

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?

Telegraphic sentences, each front-loaded with a distinct fact and no filler: scope, sibling routing, freshness limit, return contents, null semantics, verification caveat. Nothing is redundant with the schema.

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, the description need not explain return values, yet it still signals what metadata accompanies the series. Combined with the freshness, null, and provenance caveats, an agent has enough to call it correctly, only lacking explicit differentiation from the other indicator tools.

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% and both enum parameters are fully documented in the schema, so the baseline is 3. The description adds the five-year window and mentions units/definitions/producers, but provides no extra syntax or format detail for country, language, or indicator beyond what the schema already carries.

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 names a concrete verb+resource: annual population, GDP in current USD, and CPI inflation sourced from World Bank WDI. The scope ('worldwide economies', 'five completed years only') is specific. It does not, however, explicitly distinguish itself from close siblings like get_economic_indicators, get_historical_indicators, or get_us_economic_indicators, so sibling differentiation is left implicit.

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 explicit routing guidance ('Use list_countries for supported three-character codes') and states the indicator can be omitted for all three series, which is a clear usage condition. It lacks when-not-to-use guidance relative to the neighbouring indicator/economic tools, so it stops short of full alternative coverage.

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, non-destructive, closed-world reads, so the safety profile is covered. The description adds meaningful traits beyond that: data starts in 2010, no carry-forward for missing dates, not real-time, source/decimals/evidence retained, and the data is free at the Bank of Canada. This is useful scoping context an agent needs.

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?

Dense and front-loaded, leading with the resource and unit before defaults and constraints. Nearly every clause carries a constraint or caveat, though the run-on structure packs several distinct rules into one sentence.

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 the description need not explain return values, and annotations cover the safety profile. The description still supplies the temporal bounds, default behavior, mutual exclusion, and data-fidelity caveats an agent needs to call this 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 100%, so the schema already documents all three parameters, including the year/date mutual exclusion. The description reinforces unit and default semantics but adds little the schema does not already say, so 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?

Clearly states the resource and verb scope: returns Canadian overnight_target or bank_rate policy rates in percent. The series and unit are explicit, and the 'not retail loan quotes' qualifier narrows it against other rate-like tools. It does not explicitly name sibling tools (e.g., list_interest_rate_series), so differentiation is implied rather than stated.

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 concrete default behavior (latest published numeric observation) and explains the optional year vs. exact date parameters are mutually exclusive. The warning against inferring missing dates or announcement/effective dates is strong when-not guidance. It stops short of naming an alternative tool to use for other cases.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real context: only unexpired records are returned, provenance and a verification level accompany them, and source/schema validation must not be read as independent factual verification. That epistemic caveat is exactly the kind of trait annotations cannot express.

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 sentences, purpose first and caveat second, with no filler. The second sentence is slightly terse given it introduces a nuanced distinction, but it 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?

An output schema exists, so return shape need not be restated, and annotations cover safety. The description still supplies the unexpired-only constraint and the verification caveat, leaving only tool-selection guidance missing. It is sufficient for correct invocation, marginally short of complete.

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% with a single well-documented id parameter (opaque, exact reuse, no invention), so the schema already carries full semantics. The description adds nothing about the id's format or origin, making the baseline 3 correct.

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 ('Get an unexpired record') and adds what comes with it (provenance, explicit verification level). It does not differentiate itself from adjacent siblings like get_evidence, get_indicators, or catalog, and 'record' stays abstract, so an agent cannot fully tell it apart from those without opening the schemas.

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 never says when to reach for this tool versus alternatives, nor gives a precondition (e.g., it needs an id previously returned by a data response). The second sentence is an interpretive caveat about verification, not usage guidance. No alternatives among the many sibling get_* tools are named.

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 read-only, idempotent, non-destructive behavior, so the description is not obligated to repeat safety semantics. It adds genuine behavioral context the annotations cannot convey: retained source decimals, missing values, preliminary/revision footnotes, evidence preservation, and the caveat that values are not independently verified.

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 paragraph is dense but front-loaded with the series definitions, then defaults, then disclaimers. Every sentence carries information; the only mild cost is that it reads as one run-on block rather than clearly separated sentences.

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-value detail is unnecessary, and the description fully covers the three indicators, their units, the period-selection rules, and the important caveats about revision footnotes and non-real-time data. An agent has everything needed to call and interpret this 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 a baseline of 3 applies. The description goes beyond the schema by attaching domain meaning to each enum value (CPI-U NSA 1982-84=100, SA percent of civilian labor force 16+, SA thousands of payroll jobs) and restating the limit/period exclusivity, which helps an agent choose the right indicator.

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 names a specific verb and resource (US BLS monthly indicators) and enumerates the three series with their exact units and seasonal adjustments, so the agent can distinguish it from get_economic_indicators or list_us_economic_indicators without consulting any 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?

It explains the default (last 12 periods), the limit vs period mutual exclusivity, and adds explicit negative guidance ('Not real-time, a percent inflation rate or monthly job creation'), which prevents misuse. It stops short of naming when to prefer the sibling list_us_economic_indicators or get_economic_indicators, leaving that to the schema.

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?

The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. Beyond that, the description adds useful data-shape context: aggregated regions are excluded, and coverage/missing values vary by indicator. This is meaningful transparency for a list endpoint, though it does not cover fields like pagination or freshness.

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 three short, front-loaded sentences with no filler. The primary purpose comes first, followed by the exclusion rule and the data-quality caveat, all of which earn their 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?

Given the low complexity, empty input schema, rich annotations, and the existence of an output schema, the description is nearly complete: it states what is listed, what is excluded, and how coverage varies. It does not explain how the list interacts with sibling indicator tools, but that is a minor gap for this zero-parameter lookup.

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?

There are zero input parameters, so parameter semantics are not applicable. Per the rubric, a zero-parameter tool receives a baseline of 4 when the schema is effectively empty and the description does not need to document 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 ('List') and a precisely scoped resource ('economies and territories available for annual indicators'), and it adds an exclusion rule that further narrows the resource. This clearly distinguishes it from sibling tools that list indicators, topics, sources, or holiday regions.

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 the tool's usage context by mentioning annual indicators, but it does not explicitly state when to use it versus alternatives or what prerequisites exist. An agent can infer that it is meant for discovering valid economy/territory entries for annual indicators, but no alternatives or exclusions are named.

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 the safe read-only, idempotent, non-destructive profile, so the description's job is to add context, and it does: latest published periods, source definitions, units, collection status, and the EL-vs-GR country-code convention. These are genuinely useful behaviors not derivable from 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 short sentences with no filler, and the source/scope constraint is front-loaded. Slightly terse to the point of ambiguity about whether it lists codes or series, but there is no padding to trim.

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?

An output schema exists, so return-value detail can be omitted, and zero params keep the surface small. However, the description never makes explicit what the tool actually enumerates (indicators vs country codes), leaving the core resource under-specified for a catalog-style 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?

The tool takes no parameters, so there is nothing for the description to compensate for; baseline 4 applies. The country-code convention note is an extra courtesy but not required by 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?

The description reads as a noun phrase describing a dataset ('Eurostat EU/EFTA country codes and monthly/quarterly economic series since 2020') rather than stating a clear verb+resource. It does differentiate from World Bank siblings via the Eurostat scope and the Greece=EL note, but it never clarifies how this 'list' tool differs from the sibling get_economic_indicators.

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?

Usage is only implied through the source scope: an agent can infer it is the right choice when Eurostat/EU-EFTA data is wanted and World Bank data is not. There is no explicit when-to-use, when-not-to-use, or named alternative among the many siblings.

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 the safe read-only idempotent profile, so the description's remaining job is domain behavior. It adds real value here: coverage starting in 1960, preservation of missing years, and the explicit 'Not real-time' warning tell the agent what to expect from the data itself.

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?

A single front-loaded sentence with no filler; the key facts (count, provider, coverage, freshness) come first. The middle clause 'units, definitions via records, and latest collection status' is densely packed but still 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?

With an output schema present, return values need not be described, and the description covers what is listed, temporal coverage, and freshness. It is essentially complete for a zero-parameter listing tool, with the only gap being sibling differentiation.

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 takes zero parameters, so the baseline of 4 applies. The description correctly adds no parameter detail because there is none to add, keeping focus on dataset characteristics.

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 ('List') and resource ('twenty-two annual World Bank historical series'), including scope details like the 1960 start. It differentiates somewhat by naming the World Bank provider, but never explicitly contrasts with siblings like list_economic_indicators or list_us_economic_indicators, so an agent still has to infer the boundary.

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?

There is no explicit when-to-use guidance or mention of alternatives. 'Not real-time' is a data-freshness caveat rather than a condition selecting this tool over its many sibling listing tools. The agent must guess when to reach for this versus get_historical_indicators or list_economic_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?

Goes well past the annotations (readOnly/idempotent/closed-world) by describing what is returned — configured overnight_target and bank_rate definitions, collection status, coverage since 2010, latest observations, citation and freshness — and adds a critical caveat that a source_unavailable_or_stale status means configured definitions do not prove data availability. Also discloses provenance limits ('not independently verified') that the structured fields 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 core routing purpose and the no-argument call, then layers returns, usage, and caveats in a logical order. It is dense for a zero-param tool, but nearly every clause (scope exclusions, staleness caveat, provenance) carries distinct value, so little is wasted.

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?

Despite an output schema already existing, the description covers the essentials an agent needs: purpose, no-arg invocation, what comes back, the follow-up route to get_interest_rates, a staleness pitfall, and scope boundaries (Canada only, not retail/real-time). Nothing material 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?

Zero parameters, so the baseline is 4, and the description correctly reinforces this with 'Call with no arguments.' The schema at 100% coverage already documents the empty object, so no further parameter detail is 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?

States a specific verb and resource ('Discover the two Canadian policy-rate series') and clearly frames the tool as a directory that precedes get_interest_rates. An agent can distinguish it from the sibling get_interest_rates without opening either 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?

Explicitly says when to use it ('before get_interest_rates when the series key or year coverage is unknown'), how to call it ('no arguments'), and when to skip it ('skip this directory if those inputs are known'). The routing condition and exclusion are both stated, leaving nothing to inference.

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 read-only, idempotent, non-destructive behavior, but the description adds real data semantics beyond them: the fixed scope of three series, the ten-year rolling window, and unit caveats (CPI as index, payroll in thousands). 'Read source notes' signals where authoritative caveats live, which is useful context not present in structured fields.

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-loaded with the core purpose and contained in a few tight sentences with no filler. The telegraphic, comma-spliced style borders on choppy, but every clause carries 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?

An output schema exists, so return values need not be explained, and there are no parameters to document. The remaining burden is scope and data semantics, which the description covers via the ten-year window and unit notes; only the relationship to sibling retrieval tools is left unaddressed.

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 takes zero parameters, so there is nothing for the description to disambiguate and the schema-coverage baseline of 4 applies. The description's framing of what the fixed series set contains is a reasonable substitute for parameter context.

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 clear verb+resource: it surfaces three official BLS US monthly series with their units, seasonal adjustment and freshness. This is understandable on its own, but it never distinguishes itself from close siblings like get_us_economic_indicators or list_economic_indicators, so the agent cannot tell discovery-of-series from retrieval-of-values.

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?

'Rolling ten calendar years, not a full archive' gives a scope boundary that implicitly tells the agent when this tool is and isn't sufficient. However, no alternative tool is named and no explicit when-to-use condition is stated, so routing is left to inference.

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