Public statistics for Ireland and the UK: housing, crime, health, economy, welfare, with caveats.
Scored across 6 tools
Each tool maps to a clearly distinct intent: area listing, dataset/area querying, ranking/comparison, metric definition, notable changes, and chart scene data. The descriptions explicitly route ambiguous cases between compare, query_data, and explain_metric, so an agent can select the right tool.
All names are snake_case and mostly follow verb_noun, but 'compare' is a bare verb and 'notable_changes' is a noun phrase rather than a verb-led action. These are minor deviations within an otherwise readable and predictable naming set.
Six tools is well within the appropriate range and each covers a distinct part of the public-data workflow: discovery, querying, comparison, definitions, alerts, and scene data. There is no obvious redundancy or missing scale concern.
The surface covers the core lifecycle for public statistics: area discovery, dataset discovery/detail, history, ranking and registered comparisons, metric definitions, notable changes, and a chart scene. Minor gaps may exist around broader multi-area series extraction or arbitrary exploration, but the registry-backed comparison limitation is explicit and workable.
Use when the question is how areas rank or compare on a stat, or whether two stats can be compared
fairly. For one area's own figures use query_data.
Four modes, depending on which arguments are given -- consolidates what
were four separate tools (rank_areas, list_comparisons, get_comparison,
check_comparability) behind one, since they are all really "how does this
stat compare" at different scopes. Exactly one mode's arguments should be
given; mixing arguments from different modes (e.g. both `stat_key` and
`pair_key`, or only one of `stat_key_a`/`stat_key_b`) raises an error
rather than silently guessing which mode was meant.
1. `stat_key` alone (no `pair_key`, no `stat_key_a`/`stat_key_b`): ranks
every area at one geography level by its latest figure for that stat,
for one country -- e.g. "which counties have the highest median sale
price" (country="ireland"). `stat_key` comes from `query_data`'s
dataset-listing mode, for the SAME country. `level` omitted uses this
ranking's own default level; pass one of that dataset's own
`compatible_levels` for a different one -- a level this ranking
doesn't have registered returns an empty list rather than an error.
Where the underlying stat has no honest per-area denominator (crime,
homelessness, live_register and similar -- StatsMapped's own
RANKING_NO_DENOMINATOR_STATS), each row's `rate_per_1000` is the real
figure to rank/compare by, not `latest_value`, which is a raw count
dominated by area population size. Always carry forward every entry
in `caveats` when using a row in an answer.
2. `pair_key` alone: full detail for one registered comparison pair --
each axis's label, unit and publisher, the correlation stats (r, rho,
and a leave-one-out sensitivity range naming the single most
influential area), and caveats. `pair_key` comes from mode 4's own
response, for the SAME country.
3. Both `stat_key_a` and `stat_key_b` given: does StatsMapped have a
registered, hand-vetted comparison between these two stats? Registry-
backed only -- never computes a fresh correlation for an arbitrary
pair. Both stat_keys come from `query_data`'s dataset-listing mode,
for the SAME country. `verdict` is one of `"SUPPORT"` (a real,
hand-vetted registered pair with no open caveats -- may be treated as
a confirmed relationship), `"QUALIFY"` (hand-vetted, but the evidence
carries real caveats -- e.g. no robustness check for outliers, or an
unverified geography-level join; read `uncertainty` and `reasons`
before presenting it as confirmed), `"REJECT"` (a real structural
impossibility or a human-vetted "no" -- the two stats share no
geography level at all, or a reviewer rejected this exact pairing),
or `"INSUFFICIENT"` (not registered, not ruled out either --
StatsMapped genuinely hasn't vetted this pair; never treat this as
"probably comparable"). `uncertainty` names 4 separate dimensions
(data_quality, comparability, statistical_strength,
causal_strength) -- `causal_strength` is always `"not_established"`,
since no comparison here implies causation regardless of verdict.
`comparable` (DEPRECATED, kept only for callers that haven't
migrated) collapses `verdict` to the old 3-way yes/no/unknown --
`"yes"` for both `SUPPORT` and `QUALIFY` (both mean "hand-vetted",
the old `comparable` meaning this field has always carried; the
caveats a `QUALIFY` pair carries live in `uncertainty`/`reasons`,
not in demoting `comparable`), `"no"` for `REJECT`, `"unknown"` for
`INSUFFICIENT`. Prefer `verdict` directly when you need to
distinguish a fully-confirmed `SUPPORT` from a caveated `QUALIFY`.
Read `reasons` before presenting any answer other than `"SUPPORT"`
as unqualified.
4. None of the above given: lists every registered cross-dataset
comparison pair for one country -- e.g. "median sale price vs new
dwelling completions per 1,000 residents". A small, hand-curated set,
not an arbitrary-pair engine: pass one of the returned `pair_key`
values to mode 2 for the real correlation and axis detail.
`level` is only meaningful together with `stat_key` (mode 1); giving
it without `stat_key` raises rather than silently dropping it and
falling through to mode 4's unrelated pair listing.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | ||
| country | No | ireland | |
| pair_key | No | ||
| stat_key | No | ||
| stat_key_a | No | ||
| stat_key_b | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly: it discloses error behavior on ambiguous arguments, that an unregistered level returns an empty list instead of an error, that `rate_per_1000` must be used over `latest_value` for no-denominator stats, that caveats must be carried forward, and that `causal_strength` is always 'not_established'. The deprecated `comparable` field's mapping to `verdict` is spelled out, which is exactly the kind of non-obvious contract an agent could otherwise get wrong.
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 numbered mode structure is excellent and the 'use when' clause is front-loaded, but the text is long and repeats 'for the SAME country' three times and re-explains the deprecated `comparable` collapse at length. Individual sentences earn their place, yet some of the detail could be tightened without losing semantics.
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 six-parameter, four-mode tool with zero annotation support, the description supplies everything an agent needs: mode dispatch rules, failure modes, key provenance, return-field interpretation, and caveat handling. An output schema exists, yet the description still explains the field semantics an agent cannot infer from structure alone.
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 0%, so the description must compensate and it does: every one of the six parameters is given meaning, valid-value provenance, and interaction rules (which combinations are legal, which raise, which are ignored). Mode 3's `verdict` enum values are defined individually with actionable interpretations, going well beyond what a bare schema could convey.
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+resource framing ('how areas rank or compare on a stat') and immediately enumerates the four distinct modes it serves, so an agent knows exactly what it returns for a given argument combination. It also names the sibling `query_data` as the tool for a single area's figures, making it distinguishable from alternatives in one sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: 'For one area's own figures use `query_data`', then states the argument combination that selects each of the four modes and warns that mixing arguments raises an error rather than guessing. It also explains where each key value comes from (`stat_key` from query_data's dataset-listing mode, `pair_key` from mode 4) and that `level` is only valid alongside `stat_key`, so when-not-to-use is covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the question is what a metric means or how it is measured; for a figure use query_data.
Definition, methodology and standing caveats for ONE stat ('ireland' or
'united-kingdom') -- never a current figure. Call this when the question is
about what a metric MEANS or how it's measured ("how is the claimant count
defined", "is this a mean or a median"), not about a specific area's value --
`query_data`/`compare` already answer that. `stat_key` comes
from `query_data(country=...)` for the SAME country.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ireland | |
| stat_key | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well: it discloses that the tool returns definitions, methodology, and standing caveats for one stat and never returns a current figure. It also states the `stat_key` provenance constraint, though it does not discuss error behavior or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and appropriately sized, with the core distinction stated in the first line. It repeats the what-means/how-measured guidance and the `query_data` alternative, which is useful but slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not explain return values, and it still fully covers the nature of the response, the exclusion of current figures, and the prerequisite for `stat_key`. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It identifies permitted country values ('ireland' or 'united-kingdom'), explains that `stat_key` comes from `query_data(country=...)`, and enforces that both must use the SAME country; it does not document the schema default, which keeps it from a 5.
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 resource and purpose: definition, methodology, and standing caveats for ONE metric. It explicitly distinguishes this from getting a figure via `query_data` and from area comparisons via `compare`, so an agent can choose it 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 gives explicit when-to-use and when-not-to-use guidance: use for meaning/methodology questions, not for a specific area's current value. It names the alternatives (`query_data`, `compare`) and the condition that selects them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when asked for a chart, still or short clip of a figure you can cite: returns the data to DRAW one scene, nothing rendered.
Today one scene exists, "ireland-builds" (Ireland's homes
granted permission, with a commencement notice and completed, by quarter from 2018Q1). The licence DIFFERS BY STAGE (see `licence.stages`): a stage whose licence is unconfirmed or
ShareAlike is withheld (its cells are absences, not zeros) and the licence line names its holder. You get rows, a table twin, alt text, notes, `absences` (a missing figure is a typed
absence, never a zero), the licence block, `scene_hash`, a `receipt` and the canonical URL. YOU draw it, and the last frame must match the table. Print the `scene_hash` and the licence
`line` in the first, middle and last frame, quote only numbers that are in `rows`, do not loop, and keep the "stages are not a cohort" note. `purpose` is "analytical" (default) or
"promotional": a promotional use of a source whose licence forbids advertising is refused (licence_refused). `vintage` (ISO date) omitted = the current data; an earlier vintage is
not stored and returns unknown_vintage. Example: get_scene(scene_id="ireland-builds").
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ireland | |
| purpose | No | analytical | |
| vintage | No | ||
| scene_id | No | ireland-builds |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly: it explains licence-by-stage withholding, absences versus zeros, promotional-licence refusal, unknown vintage behavior, and the returned artifacts including rows, table twin, alt text, notes, absences, licence block, scene_hash, receipt, and canonical URL.
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 first sentence is front-loaded and the description is dense with operational constraints rather than filler. It is long, but most sentences carry necessary behavioural or licence information; the agent-facing drawing instructions are useful though slightly overpacked.
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 fully explained, but the description still covers the key artifacts and failure modes. The main gap is the undocumented country parameter and the absence of explicit sibling routing guidance.
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 0%, so the description must compensate. It explains purpose modes and the licence_refused outcome, explains vintage omission and unknown_vintage, and gives a scene_id example, but it never mentions the country parameter at all.
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: it returns the data needed to DRAW one scene and explicitly says nothing is rendered. It also names the existing scene and makes the chart/still/clip use case concrete, so an agent can distinguish it from query or comparison tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear triggering condition: use when asked for a chart, still, or short clip of a citable figure. It also explains purpose and vintage constraints, but it does not explicitly name sibling alternatives such as query_data or compare where those might be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need the ids and names of the areas (counties, local authorities, districts) to pass to
query_data.
List every geography at one boundary level, for one country ('ireland'
or 'united-kingdom'). `level` defaults to "county" (Ireland's 26 counties);
the UK's own primary level is "lad" (local authority districts), not
"county". Other levels exist per country (e.g. Ireland's "local_authority",
"garda_division") -- see a dataset's own `compatible_levels` from
`query_data` for which levels a given stat is actually published at.
Returns each area's `id` (used by `query_data`'s area-scoped modes,
always paired with the SAME `country`), `name` and `level`. Slim by default;
`include_parents=True` adds each area's `parents` (the regions it sits in)
and Irish-language name.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | county | |
| country | No | ireland | |
| include_parents | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses defaults (level='county', country='ireland'), the slim-by-default return shape, and exactly what `include_parents=True` adds. It doesn't cover error behavior or whether unknown levels raise or return empty, which is the remaining gap.
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 use case and tightly scoped, with every paragraph carrying distinct information. It is slightly dense with parenthetical asides (multiple level examples, Irish-language note) that could be trimmed, but nothing is 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?
For a 3-optional-param lookup tool with an output schema, the description covers trigger, scope, defaults, level semantics across both countries, and the shape of the result set. Nothing an agent needs to invoke it correctly 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 coverage is 0% and the schema has no enums, so the description must compensate and largely does: it names the valid countries ('ireland' or 'united-kingdom'), gives the default and UK-specific meaning of `level`, and explains `include_parents`. It stops short of enumerating valid levels, deferring to `compatible_levels` instead.
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+resource (list areas at a boundary level for a country) and frames the purpose in terms of what the output feeds into: 'ids and names ... to pass to `query_data`'. An agent can distinguish list_areas from query_data/compare/explain_metric without opening 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?
Opens with an explicit 'Use when you need...' trigger and points to the alternative path for level discovery: 'see a dataset's own `compatible_levels` from `query_data`'. It also handles the country/level selection edge case (UK's primary level is 'lad', not 'county').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the question is what changed lately, which figures moved most, or what is new; for one area's full history use query_data.
Returns statistical movements databeat flagged as notable, not verdicts on what they mean; limit is 1 to 50 (default 8), and stat_key or geography_id narrows the list.
Ireland and united-kingdom. Cite StatsMapped (https://statsmapped.com) as the source. Source: GET /{country}/api/v1/alerts/notable.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| country | No | ireland | |
| stat_key | No | ||
| geography_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it states results are flagged movements, not verdicts, gives limit bounds and default, explains filters, supported countries, and citation requirements. It does not mention authentication or pagination behavior, but the core behavioral semantics are disclosed.
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 usage condition and sibling alternative are front-loaded, followed by behavioral caveats, parameters, countries, and source. It is slightly cluttered by the endpoint URL and citation instruction, but every sentence contributes.
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 an output schema exists, the description does not need to explain return values, and it covers purpose, usage, filters, supported countries, and semantics sufficiently. Minor gaps remain around exact filter value formats and supported country casing.
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 0%, so the description must compensate. It does for three parameters: `limit` range/default, `country` support for Ireland and united-kingdom, and `stat_key`/`geography_id` as narrowing filters. It does not specify formats or valid values for the filter parameters, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns statistical movements databeat flagged as notable. It also distinguishes itself from `query_data`, which is for one area's full history, so an agent can choose correctly without opening 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?
Explicitly names the triggering questions (what changed lately, which figures moved most, what is new) and the alternative for full histories. This is clear when-to-use guidance with a named exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need to find which datasets exist, which exist for one area, or the figures and history
for one area and dataset (or a council planning view). For what a metric means use explain_metric;
for how areas rank use compare.
Three modes, depending on which of `area_id`/`dataset` are given (plus a planning mode, `council`, described last) --
consolidates what were three separate tools (list_datasets,
list_area_datasets, get_dataset_for_area) behind one, since they are all
really "how do I get data" at different levels of specificity:
1. Neither `area_id` nor `dataset`: lists every dataset (stat) StatsMapped
tracks for one country ('ireland' or 'united-kingdom'), with its key,
human label, and which geography levels it can be shown at. Ireland and
the UK track genuinely different datasets -- call this first for the
right country before assuming a stat_key exists there, to find the
right `stat_key` for `compare`'s ranking mode.
2. `area_id` given, `dataset` omitted: lists every dataset available for
that one area (e.g. "county:kerry" for Ireland, "uk:lad:e09000033" for
the UK), with its latest figure, year-on-year change, and caveat labels
only (not full caveat text -- use mode 3 for the full detail on any one
dataset that matters). Pass `stat_key` (from mode 1) to list only that
stat's series for the area: a full listing is tens of KB, one stat is a
few hundred bytes. `area_id` comes from `list_areas`; `country`
must match whichever country that call used, or this simply 404s
("unknown geography").
3. Both `area_id` and `dataset` given: full detail for one dataset in one
area -- the latest figure, a written summary, full caveat text, and (if
`history_months` is set) recent history. `dataset` is a `series_key`
from mode 2's own response. `history_months` means actual months of
history (0 = everything) -- e.g. 24 returns 2 years of an annual
series, not 24 years. `country` must match `area_id`'s own country. A stat key from mode 1 is also
accepted as `dataset` when the area has exactly one series for it (the reply says `resolved_from_stat_key`);
with several, the error names the series keys to use.
4. `council` alone (an Irish council slug, e.g. "cork-city-council"; country "ireland" only; no other argument): that council's planning
applications by year received -- count, grant and refusal share of decided applications, median days to a decision -- with source, licence,
the last data date, a receipt, plain notes, and typed `absences` instead of zeros. A council the national planning feed has stopped carrying
(for example Cork City, last record 2025-11-04) says `status: "stopped_reporting"`: a low recent figure is a feed gap, not fewer applications.
Example: query_data(council="cork-city-council").
`dataset` and `history_months` are only meaningful together with
`area_id` (and, for `history_months`, `dataset` too, since it only
applies to mode 3); giving either without its real precondition
raises rather than silently dropping the argument and dispatching to
the wrong mode.
| Name | Required | Description | Default |
|---|---|---|---|
| area_id | No | ||
| council | No | ||
| country | No | ireland | |
| dataset | No | ||
| stat_key | No | ||
| history_months | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: response size differences (tens of KB vs a few hundred bytes), that mode 2 returns caveat labels only versus mode 3's full text, 404 behavior on country/geography mismatch, `resolved_from_stat_key` in replies, typed `absences` instead of zeros, and `status: "stopped_reporting"` meaning a feed gap rather than a real drop. These are exactly the non-obvious traits 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?
Front-loaded with a use-when sentence and a sibling cross-reference before the mode list, so an agent can act on the first two lines alone. The remaining prose is dense but each clause carries a distinct operational fact; the only minor blemish is the slight mismatch between 'Three modes' and the four numbered items, which the parenthetical already disclaims.
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 six-parameter, four-mode, zero-annotation tool, nothing an agent needs is missing: mode selection, argument provenance, failure modes, response shape hints, and a worked example (`query_data(council="cork-city-council")`). An output schema exists, so the description is not obliged to specify return fields, yet it still flags the notable ones (`absences`, receipt, `resolved_from_stat_key`).
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 0% across 6 params, yet the description defines every one: `area_id` provenance and format examples ('county:kerry', 'uk:lad:e09000033'), `country` must match the area/list_areas call, `dataset` is a `series_key` from mode 2, `stat_key` from mode 1 with the single-series fallback, `history_months` as literal months with 0 = all, and `council` as an Ireland-only slug.
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 opening sentence states a specific verb and resource ('find which datasets exist... the figures and history for one area and dataset') and immediately distinguishes itself from the two nearest siblings, `explain_metric` (metric meaning) and `compare` (ranking). The mode enumeration makes the tool's full capability surface explicit rather than leaving it to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit routing rules: 'For what a metric means use `explain_metric`; for how areas rank use `compare`', then defines each of the four modes by which arguments are present. It also tells the agent to call mode 1 first for the right country before assuming a stat_key exists, and warns that supplying `dataset`/`history_months` without their preconditions raises rather than silently mis-dispatching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
notable_changesget_scenelist_areas1 field changedInput schema / properties / include_parentsAdded value: +{
+ "default": false,
+ "title": "Include Parents",
+ "type": "boolean"
+}query_data2 fields changedInput schema / properties / councilAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Council"
+}Input schema / properties / stat_keyAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Stat Key"
+}compareexplain_metriclist_areasquery_dataUK public data by area: house prices, crime, deprivation, schools and more, each figure cited.
Read-only Irish public data for AI assistants: stats, weather, transport, law, property and maps.
Irish rent, rent limits, house price comps (IE, NL, EU), housing report. x402/MPP paid.
Query UK Parliament, elections, crime stats, ONS census data, and national archives
Add one secure layer between your agents and this server.
