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 read-only, idempotent, non-destructive, closed-world, so the description is free to add genuinely new behavior: a 1500-value per-call cap, differing results by account tier, truncation signalled via a truncated flag, and the presence of next_projection. This is exactly the kind of context 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?

Front-loaded with the outcome and the value cap, then the auth clause, then the two year behaviors. It wastes a modest amount of space: "Needs sign-in to EconDash" restates the earlier signed-in clause, and the country ISO code sentence duplicates the schema description.

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 still carries the return shape: same fields as get_indicator_series, plus next_projection and truncated. The cross-reference to a sibling's field set means the agent must consult that tool to know the exact payload, which is the only notable completeness gap.

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, but the description lifts it by explaining what omitting start_year/end_year does versus supplying them, including the range-and-truncation semantics that the schema's one-line field descriptions do not convey. It repeats the schema's ISO 3166-1 alpha-3 note for country, which adds nothing.

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?

"Returns the whole history of one indicator for one country or region" names a specific verb, resource, and scope, and immediately frames the distinction from get_indicator_series by volume (up to 1500 values). An agent can tell exactly what this call produces 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?

It states the access precondition (full data access vs. capped at get_indicator_series) and describes the two usage modes: no years for full history with the next projection, years for a bounded range. What it lacks is an explicit steer like "use get_indicator_series if you only need recent values" or an exclusion for indicators without projections, but the context is clear.

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, and the description corroborates the closed-world hint with a concrete list of known catalogue gaps. Beyond that it discloses the result cap ('up to 25 matches') and the exact fields returned (slug, name, unit, frequency, source, years covered), which the annotations do not cover.

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 purpose is front-loaded in the first clause, and every later sentence carries distinct load (trigger, return fields, downstream slug usage, coverage gaps). The long catalogue enumeration in sentence one is defensible for a keyword-search tool but is the bulkiest part and could be compressed.

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?

Although there is no output schema, the description names the returned fields and the result cap, explains what to do with the slug downstream, and pre-empts the most likely failed searches with an explicit exclusion list. For a two-parameter read-only search tool this leaves no material gap for an agent.

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 both parameters are documented in the schema and the baseline is 3. The description adds a small amount on top: 'up to 25 matches' reinforces the limit maximum, and the keyword list models the style of query expected. It adds nothing about the 2-character minimum or query length limit, so it is above baseline but not fully additive.

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 ('Searches the EconDash catalogue by keyword') and enumerates the domains covered, so an agent knows exactly what is searchable. It also distinguishes itself from retrieval siblings by stating that the returned slug is the input for get_indicator_series, compare_countries and get_indicator_details.

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 states the triggering condition explicitly: 'Use it when the user asks for a statistic for a country or region: its latest value, history or a comparison.' It also gives negative guidance — no individual shares, cryptocurrencies (except the Fear & Greed Index), tax rates, steel or the Baltic Dry Index — so the agent can rule the tool out rather than issue a doomed query.

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