StatsMapped: Irish statistics (CSO, county & council data)

Overview Schema Source Related Servers Discussions Admin

query_data

Retrieve Irish and UK statistics by county or council: list datasets, view area-level figures, or get a dataset's latest value, caveats, and history.

Instructions

Three modes, depending on which of area_id/dataset are given -- 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:

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.
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). area_id comes from list_areas; country must match whichever country that call used, or this simply 404s ("unknown geography").
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.
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.

Input Schema

TableJSON Schema

Name	Required	Default
`area_id`	No
`country`	No	ireland
`dataset`	No
`history_months`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.0Sep 26, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden. It discloses the three modes, what each returns (including caveat labels vs. full caveat text), error behavior ('404s' for country mismatch, 'raises' when preconditions are violated), and the nuanced meaning of history_months (0 = everything, actual months not years). This is thorough and transparent.

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

Conciseness5/5

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

Although long, the description is efficiently structured with numbered modes and a clear hierarchy. It front-loads the main concept (three modes) and then details each mode. Every sentence adds necessary information; there is no fluff or repetition. The formatting (numbered list, bullet-style details) makes it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for an agent to call correctly: it covers all three modes, parameter dependencies, error conditions, and the meaning of history_months. The output schema exists, so return values are defined elsewhere. No essential behavioral or contextual information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

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: every parameter (area_id, dataset, history_months, country) is explained in the context of each mode, with examples (e.g., 'county:kerry', 'uk:lad:e09000033') and constraints (dataset only meaningful with area_id, history_months only in mode 3). This far exceeds what the raw schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Three modes' and explicitly names what the tool does: consolidates three former tools into one for querying data at different specificity levels. It distinguishes from siblings by referencing list_areas (source of area_id) and compare (which uses stat_key from mode 1). The purpose is unambiguous and well-scoped.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance per mode: 'call this first' for mode 1, mode 2 for a specific area, mode 3 for full detail. It also states prerequisites (area_id from list_areas, country must match) and warns that mismatches cause errors. Alternatives like compare and explain_metric are implicitly referenced, but the routing among the three modes is crystal clear.

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

Deploy Server