StatsMapped Public Data

query_data

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.

Input Schema

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

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 23, 2026

addedInput schema / properties / council

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Council"
+}

addedInput schema / properties / stat_key

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Stat Key"
+}

First observedOct 9, 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 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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All StatsMapped Public Data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.