EconDash

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description adds genuine behavioral detail: each value carries its own period and chart link, projections are labelled, and codes lacking data are returned separately. That missing-data contract is the kind of thing an agent would otherwise have to discover by trial.

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 dense sentences, front-loaded with the core scope before the behavioral details. Every sentence carries information, though the middle sentence packs two distinct facts (period/chart link and projection labelling) into one semicolon-joined clause.

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?

There is no output schema, so the description has to convey the return shape, and it does: one value per entity plus its period and chart link, projection flagging, and a separate bucket for codes with no data. Nothing essential for calling or interpreting the result 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 all three parameters are already documented, including the 'omit for latest observed value' behavior for year and the ISO3 constraint for countries. The description restates the year-omission semantics but adds no syntax or constraint beyond the schema, which is the baseline case for a fully documented 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 states a specific verb and resource: returning a single indicator value across up to 20 countries for a chosen or latest year. This scope implicitly and clearly separates it from get_indicator_series (one country over time) and search_indicators, so an agent can route correctly 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 comparison framing (up to 20 countries, one value per country) implies when this tool is appropriate, and it explains what happens when year is omitted. However, it never names an alternative tool or an explicit when-not condition, so the routing guidance 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.

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds the useful list of returned metadata fields, but says nothing about error behavior for an unknown slug, auth requirements, or rate limits, so it only modestly exceeds the annotation baseline.

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 sentence, front-loaded with the verb and resource, with no filler. The long field enumeration is dense but every item is informative about the return shape.

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 is the only place return data is described, and it does enumerate the fields returned, including coverage and last-change time. It stops short of explaining failure modes for an invalid slug or how to obtain a valid one, which would complete the picture.

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 single parameter is fully documented with a slug example and pattern, so the schema carries the semantics. The description's 'for one indicator' restates cardinality without adding format or lookup guidance, matching the baseline for a fully-covered 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 states a specific verb and resource ('Returns ... for one indicator') and enumerates the metadata fields, so the agent knows exactly what this fetches. It does not, however, differentiate itself from siblings like get_indicator_series or search_indicators, so it falls short of a 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?

The description contains no when-to-use, when-not-to-use, or alternative guidance. The only routing hint ('Indicator slug from search_indicators') lives in the input schema, not the description, and nothing tells the agent when to prefer this over get_indicator_series.

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 read-only and idempotent, and the description adds substantial behavior beyond them: hard caps per frequency (30 annual, 40 quarterly, 120 monthly, 52 weekly, 250 daily), the truncation flag, projection labeling with a separate next_projection field, and the returned metadata (unit, source, licence, period range, chart link). That is exactly the kind of operational context annotations cannot carry.

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 behavior and frequency caps, then the mode selection, then return contents. It is dense but long; the parenthetical repetition of the year-coverage math ('about 30 years of annual data...') slightly duplicates the cap list already given.

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-shape burden and does so by naming the included fields (unit, source, licence, period range, chart link) and the next_projection field. An agent has enough to call it and interpret the result without further inference.

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 baseline is 3, and the description genuinely adds meaning: it explains the interaction between year and start_year/end_year, that year returns the last period of that year for monthly or quarterly data, and that country is an ISO 3166-1 alpha-3 code. It stops short of explaining the indicator slug format, which the schema already covers.

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?

Opens with a specific verb and resource ('Returns values of one indicator for one country or region') and states scope precisely enough to separate it from get_indicator_details or search_indicators. It does not explicitly name the sibling tools, so the differentiation must be inferred from the resource noun 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 clear conditional guidance for the three calling modes: no years = latest values, start/end_year = a range, year = a single value. That is strong within-tool routing, but it offers no explicit statement about when to prefer compare_countries or get_indicator_details instead.

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 and closed-world, so the safety profile is covered. The description usefully adds behavioral content beyond that: the returned values are ISO alpha-3 codes and the list deliberately includes World Bank aggregates such as WLD and EUU, which an agent would not guess.

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, zero waste. The core statement comes first and the clarifying detail about region codes follows, so an agent gets the essential fact immediately.

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 listing tool whose annotations already cover the safety profile, the description is nearly complete. With no output schema, it does describe the shape of returned values, though it could state whether the full list is always returned or whether results are paginated/limited.

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 — baseline 4 applies by rule.

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 ('Lists the countries and regional aggregates in EconDash') and specifies the identifier format returned (ISO 3166-1 alpha-3 with names). It is clearly distinguishable from siblings like compare_countries and get_indicator_series, though it never explicitly names an alternative.

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: this reads as a code-lookup/discovery tool, useful before calling compare_countries or get_indicator_series, but the description never says when to use it or when not to. No prerequisites or exclusions are given.

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 and closed-world behavior, so the safety profile is covered. The description adds genuinely useful behavioral detail beyond that: the result cap (25) and the exact fields returned (slug, name, unit, frequency, source, years covered), which matters because there is no output schema. Minor caveat: the schema's default limit is 10, so 'up to 25' describes the maximum rather than the typical response.

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 tight sentences: the first establishes what is searched, the second covers the return shape and the downstream handoff. Nothing is redundant and the most important information (what it does, what you get back) is front-loaded.

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 burden of describing return values, and it does so by listing the fields and the result cap. Combined with the annotations covering safety and the downstream-tool routing, an agent has what it needs; only the default-versus-maximum result count distinction is left slightly ambiguous.

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 both parameters are already documented (query with an example, limit with its range). The description adds only the 'by keyword' framing and the result ceiling, which the schema already implies via limit's maximum of 25. 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?

Specific verb (searches) plus a clearly scoped resource (the EconDash catalogue of economic, financial, demographic and social indicators) and the matching mechanism (by keyword). It is immediately distinguishable from the sibling retrieval tools, and the mention of the slug output further clarifies its role as the discovery entry point.

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 tells the agent that the returned slug is the input for get_indicator_series, compare_countries and get_indicator_details, which effectively establishes this as the tool to call first when the identifier is unknown. It stops short of an explicit 'use this instead of X when...' exclusion statement, so it is strong context rather than full routing guidance.

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