UK Data: Eurostat EU statistics

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

Annotations already cover read-only/idempotent safety, and the description adds genuinely new behavioral context: the Eurostat source dataset, the data vintage caveat (recent quarters get revised), and a cost of 1 credit. It does not describe the shape or ordering of what comes back, but the credit/revision notes are the operationally important extras.

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 what is measured, followed by the default behavior, then use-case examples, source, caveat, and cost. Every clause carries information an agent would otherwise have to guess; nothing is padding.

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 three-parameter, annotation-covered, no-output-schema tool, it covers measurement definition, scope, default mode, source, revisions, and cost. Only slight gap is that the returned structure (a quarterly series of percentage changes) is implied rather than stated.

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 geo codes, n, and the quarter/year enum are already documented in the schema. The description reinforces the default comparison mode (previous quarter) and the geographic scope, but adds no syntax or edge-case detail beyond the schema, 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?

Names the exact measure (real GDP growth, seasonally and calendar adjusted, chain-linked volumes) and the exact population (one European country or EU/euro area), with the specific verb of returning quarterly changes. It is clearly separable from siblings like eu_house_price_growth, eu_inflation_rate, or next_gdp_release.

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 use cases in natural-language form ("is the German economy growing", "is Italy in recession") and states the default mode of comparison, which tells an agent when this tool fits. It does not explicitly route away from alternatives such as next_gdp_release or other Eurostat indicators, so it stops short of a full when/when-not specification.

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 this a safe, idempotent read (readOnlyHint, idempotentHint, destructiveHint=false), so the description earns credit for what they don't cover: the exact source dataset (Eurostat gov_10q_ggdebt), the Maastricht consolidated definition, and the caveat that quarterly ratios differ from annual EU deficit-procedure figures. The stated 1-credit cost is also useful operational 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?

Well front-loaded: the metric, geography, and units come first, followed by the use-case framing, source, and caveat. The audience phrase ('for investors, students and reporters') is mild padding but does convey the question shape the tool answers.

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 three-parameter read with no output schema, the description supplies source, definition, units, and the key interpretation caveat, which is enough to call it correctly and interpret the number. It doesn't say what the response actually looks like (a single value or a series of n quarters), a minor remaining 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 description coverage is 100%, so geo codes, the n range, and the PC_GDP/MIO_EUR units are already fully documented in structured fields. The description restates the default unit but adds no syntax or format detail beyond the schema, 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?

States a specific resource (general government gross debt), scope (one European country, quarterly), and both output units with the default called out. An agent can distinguish this from eu_government_deficit or eu_gdp_growth on the face of the description alone.

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 example questions ('how big is Greece's or Italy's national debt') give implied usage context, and the note about quarterly vs annual figures in EU deficit procedures hints at the boundary with deficit tools. But it never names an alternative sibling or states a when-not-to-use condition, so an agent must infer routing.

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, idempotent and open-world behavior, so the description's job is to add context — and it does: the underlying dataset (gov_10dd_edpt1, EDP notifications from April and October), annual-only granularity, provisional latest year, and a 1-credit cost. What it omits is any note on how aggregates like EU27_2020 or EA behave versus single countries.

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 core definition and sign convention are front-loaded, followed by example intent, provenance, temporal caveats and cost in a tight sequence. Every clause carries information; the parenthetical cost note is the only element that could be trimmed.

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 supplies the one piece needed to interpret results — negative means deficit, expressed as a percentage of GDP. The dataset provenance and provisional-year warning round out the picture, leaving only minor gaps about aggregate/country coverage.

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 both `n` and `geo` fully documented in the schema itself, so the schema already does the heavy lifting. The description only adds the framing “one European country” and the deficit sign convention, which is useful but does not extend parameter meaning beyond the structured fields.

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 metric (annual general government deficit/surplus as % of GDP), states the unit and the sign convention, and pins it to a named Eurostat dataset. It is clearly distinguishable from siblings such as eu_government_debt_ratio or eu_gdp_growth, though it never explicitly contrasts itself with them.

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?

Two concrete example questions (“what is France's budget deficit”, “which countries break the 3% rule”) make the intended usage obvious, and the “annual only” constraint plus provisional-latest-year caveat define the boundary of valid use. It stops short of naming an alternative tool for quarterly or non-EU data.

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, so the description earns credit for what they cannot say: results are tariff averages so an individual contract may differ, data is published with a multi-month lag, taxes are included by default, and the call costs 1 credit. Return shape is not described, but no output schema exists and the caveats cover the main behavioral risks.

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?

Roughly ninety words, front-loaded with the metric and its scope, then the routing examples, then source and caveats. Every sentence carries information an agent would otherwise have to guess; nothing is padding.

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 single-metric statistical lookup with fully documented parameters and no output schema, the description supplies scope, defaults, caveats, provenance and cost. An agent can decide to call it and interpret the result without further context.

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, but the description adds real meaning: the half-year cadence explains what the 'n' most-recent-periods parameter counts, and 'all taxes included by default' explains the default state of the tax parameter. It does not restate the geo code list, which the schema already handles well.

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 metric, unit (per kWh), geography (one European country), granularity (every half-year) and population (households using 2,500-5,000 kWh/yr). This clearly separates it from siblings such as eu_house_price_growth, eu_inflation_rate or trade_tariff without opening a 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?

Two concrete example questions ('how much does electricity cost in Germany per kWh', 'where is power cheapest in Europe') anchor when to reach for it, and the schema's geo note scopes it to EU/EFTA/candidate countries with no UK. No explicit when-not-to-use or named alternative tool is given, so it falls short of a 5.

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, open-world behavior, so the description only needs to add operational context. It usefully adds that the latest quarter is often provisional and that calls cost 1 credit, but says nothing about response ordering, country coverage limits per call, or error behavior for unsupported geos.

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 metric and scope, then caveats, then cost; every clause adds information. The audience clause ('for buyers, movers and investors') is the one mildly decorative element.

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 does enough: it establishes that output is a quarterly series of annual % changes, that levels are not returned, and that the newest point may be revised. A brief note on result shape (e.g., rows of period plus value) would close the remaining 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. The description reinforces the dwellType default ('all dwellings (default), new or existing') and implies that n counts quarters ('quarter by quarter', 'latest quarter'), but adds no syntax or edge-case guidance beyond the schema's own parameter 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?

States a specific metric (annual % change in house prices), a specific unit of observation (one European country, quarter by quarter), and a scope filter (all/new/existing dwellings). The Eurostat prc_hpi_q source and the 'European country' constraint implicitly separate it from the sibling house_price_index without needing to name it.

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 usage context ("are house prices rising in Portugal or the Netherlands", for buyers, movers and investors) and an explicit limitation that it returns rates of change, not euro prices, which steers the agent away from using it for price-level questions. It stops short of naming an alternative tool for price levels or citing a named sibling.

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

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

Annotations already declare this read-only, idempotent, open-world and non-destructive. The description adds genuinely useful context beyond them: the underlying dataset, the flash-estimate caveat for the newest month, and a 1-credit cost. It says nothing about return shape or units beyond '% change', which is a gap given there is no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the metric definition, then audience, then source, then coverage caveats and cost. Dense and information-bearing throughout; no filler sentences to cut.

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 two-parameter read-only indicator lookup with no output schema, the description covers metric definition, source, geographic limits, flash-estimate behavior, and cost. Only the returned series format (e.g., month labels, value precision) is left unstated, which is a minor omission.

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 `geo` (codes, EU27_2020/EA variants, no UK) and `n` (1-100, default 12) are already documented. The description reinforces geo semantics ('one European country or the EU / euro area') but adds no format or edge-case detail beyond the schema, so 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?

Names the exact metric (HICP all-items annual % change), the geography, the Eurostat dataset (prc_hicp_minr), and the year-over-year definition. An agent can distinguish it from siblings like eu_gdp_growth or eu_unemployment_rate without opening a 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?

Provides concrete usage framing ('what is inflation in Germany right now') and explicit coverage boundaries: EU/EFTA/candidate countries, not the UK or the US. It does not explicitly route to alternative siblings (e.g., national CPI tools), but the scope constraints give clear when-to-use/when-not-to-use signals.

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, open-world), but the description adds substantive behaviour: a semi-annual publication cadence, the upstream dataset, an explicit coverage gap for five named countries, and a per-call cost of 1 credit. Those are things an agent cannot infer from annotations and directly affect whether a call is worth making.

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 metric, cadence, units and source are front-loaded in the first sentence, and the coverage caveat follows logically. The first sentence is dense (three concepts stacked), but every clause carries information an agent needs, and the credit note is terse.

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 three-parameter read tool with no output schema, the definition covers scope, units, cadence, provider and known data gaps — enough to call it correctly and interpret empty results. It does not describe the shape of returned values (e.g. time-period labels alongside amounts), which is the only remaining 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 schema already defines geo, currency and n, including the NAC/PPS expansions that the description restates. The description's contribution is limited to reinforcing that EUR is the default and that values are monthly gross, while the n parameter (most recent half-years) is left entirely to the schema. 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?

The description names a specific metric and scope: 'Statutory monthly gross minimum wage in one European country', with the unit basis (gross, monthly), cadence (January and July) and underlying source (Eurostat earn_mw_cur). An agent can distinguish this cleanly from neighbouring Eurostat siblings such as eu_unemployment_rate or eu_inflation_rate 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 supplies a concrete usage example ('what is the minimum wage in Germany or Spain') and a clear negative case: countries without a national statutory minimum (Italy, Austria, Denmark, Finland, Sweden) return no values, which prevents a wasted call. It stops short of naming an alternative tool for those cases, so no explicit routing is provided.

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 establish that this is a safe, read-only, idempotent, non-destructive lookup with open-world coverage. The description adds real context beyond that: the 1-credit cost, the fact that the newest month may be unpublished for some countries, and the ILO definition caveat. Still, it says nothing about the shape or ordering of the returned series, which matters for a time-series tool.

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 text is compact and front-loaded: measure, then unit, then geography, then audience, then caveats, then cost. Every sentence carries useful information, and the definition is slightly dense but never padded.

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 three-parameter statistical lookup with no output schema, the definition covers units, coverage, source, definition caveat, publication lag and cost, which is enough for correct invocation. The one gap is that it never describes the shape of the response series (for example, date/value pairs), though this is minor for a simple read-only 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 description coverage is 100%, so all three parameters (n, geo, sex) are already documented in the schema and the baseline is 3. The description adds only light framing: it clarifies that only one country or aggregate is covered per call, and that the sex filter is optional.

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 measure (monthly, seasonally adjusted unemployment rate), a unit (% of labour force aged 15-74), a geography (one European country, EU, or euro area) and its source dataset (Eurostat une_rt_m). The explicit age band 15-74 implicitly distinguishes it from the sibling tool eu_youth_unemployment_rate, so the agent can choose between them.

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 anchors usage with a concrete example question ("what is unemployment in Spain") and a target audience, and it explains the ILO-vs-national-claimant distinction, which tells the agent when this data may not match national sources. What it does not do is explicitly route to the sibling eu_youth_unemployment_rate, or say when not to use this tool.

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 open-world, so the safety profile is covered. The description adds real context beyond that: seasonality adjustment, the Eurostat dataset of origin, the fact that some countries publish youth figures quarterly or with a lag so recent months may be null, and the 1-credit cost. That is exactly the kind of operational 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?

Front-loaded with the core definition, then source, then the data-lag caveat, then cost. Dense with parentheticals but each sentence carries distinct information; nothing is padding.

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 two-parameter read-only time series with no output schema, the description conveys the measure, unit, adjustment, source and the main data-quality pitfall. Only the exact return shape (monthly series length, field names) is unstated, which is minor for such a simple 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%, with the geo codes, EU27/EA aggregates and the n range already fully documented in the schema, so baseline 3 applies. The description adds only a light recommendation on n ('ask for 4 or more months') and the 'one European country' scoping, which is useful but marginal against the schema's own detail.

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 gives a specific resource and unit: 'Monthly unemployment rate for people under 25 (seasonally adjusted, % of the under-25 labour force) in one European country', plus the source dataset une_rt_m. The age restriction distinguishes it implicitly from the sibling eu_unemployment_rate, but that sibling is never named, so the agent must infer the split.

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 provides an example question ('how high is youth unemployment in Spain or Greece') and a practical instruction to 'ask for 4 or more months' because recent data may be null. However, there is no explicit when-not guidance or routing to eu_unemployment_rate for the all-ages rate, so the sibling choice is left implicit.

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