Read-only Irish public data for AI assistants: stats, weather, transport, law, property and maps.
Scored across 7 tools
Mostly distinct: search is cross-source discovery, fetch retrieves by id, ireland_call executes a named source operation, and nearby is a composite point lookup. Some overlap remains because ireland_call contains search/get operations, and nearby duplicates several underlying calls, but the descriptions guide selection reasonably well.
The set mixes bare primitives such as search, fetch, and nearby with ireland_* meta tools, and the prefixed group itself mixes verbs (call, describe) and nouns (about, catalogue). The names are still readable and largely interpretable, but the convention is mixed rather than consistent.
Seven tools is well scoped for an aggregator gateway: catalogue, describe, call, search, fetch, nearby, and about each have a clear role. The large operation surface is intentionally multiplexed through ireland_call rather than exposed as dozens of tools.
The surface covers discovery via catalogue/search, schema inspection via describe, execution across many Irish data sources via ireland_call, retrieval via fetch, composite geospatial lookup via nearby, and meta/help via about. For an Ireland data gateway, this is a complete lifecycle with no obvious dead ends.
Fetch the full text of a search result by its id, e.g. 'cso:F1001', 'oireachtas:bill/2024/12', 'legislation:2018/7/s2' or 'data-gov-ie:moby-bikes'.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id from search, '<source>:<key>'. | |
| max_tokens | No | Result budget in tokens (default 2000). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the behavioral fact that this returns 'full text' from heterogeneous source namespaces, but says nothing about truncation when max_tokens is hit, rate limits, or other runtime behavior.
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 front-loaded sentence with the verb and resource stated first, followed by a compact enumeration of id examples. Every element earns its place; there is no boilerplate or 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?
With an output schema present, return-value explanation is unnecessary, and annotations plus 100% schema coverage handle safety and parameters. The description supplies purpose and id format, leaving only minor gaps (truncation behavior for max_tokens, explicit routing versus 'search').
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 goes beyond the schema's generic '<source>:<key>' by giving four concrete id examples spanning different namespaces ('cso:', 'oireachtas:', 'legislation:', 'data-gov-ie:'), which materially helps the agent construct a valid id.
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 a specific verb ('fetch') and resource ('the full text of a search result') and specifies the selector ('by its id'), so the agent knows this retrieves document content rather than finding documents. It implicitly distinguishes itself from the 'search' sibling by referencing 'a search result', but never names or contrasts that alternative explicitly.
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 implied rather than stated: the phrase 'by its id' plus 'of a search result' signals the id must come from a prior search call. There is no explicit when-to-use, when-not-to-use, or named alternative among the siblings (search, ireland_describe, nearby).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Licence, attribution, status URL and how to enable typed toolsets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered without the description. The description adds only a content inventory, disclosing nothing about the response shape or any side effects beyond what the annotations and output schema 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?
A single short fragment with no filler, and the most decision-relevant item (licence, attribution) leads. It loses a point only for being an unanchored phrase rather than a complete sentence, which slightly weakens front-loading of intent.
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 zero parameters and an output schema present, there is little the agent needs beyond knowing this is a static informational endpoint. The description is sufficient for that, though it never explicitly states that no arguments are needed or that the output is documentation-style prose.
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 per the rubric the baseline is 4. There is no parameter syntax for the description to clarify, and it correctly says nothing about inputs.
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 is a noun phrase listing the payload's contents (licence, attribution, status URL, how to enable typed toolsets) rather than a verb+resource statement of what the tool does. It is distinguishable from siblings like ireland_describe or ireland_catalogue, but an agent must infer that this is a server-metadata/introspection tool from the title 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?
No explicit when-to-use or when-not-to-use guidance is given, and no sibling alternative is named. The enumerated content does imply the triggering conditions (need licence/attribution/status info or help enabling typed toolsets), which is enough for implied but not stated usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a source operation with args. Bad args return the expected schema and an example. Operations by source: cso: cso_search_tables, cso_get_table_metadata, cso_get_data, cso_area_profile; lobbying: lobbying_search_returns; paygap: paygap_search_reports; council-budgets: council_budgets_list_years, council_budgets_get; ncse: ncse_search_datasets, ncse_get_dataset, ncse_query_datastore; world-bank: worldbank_get_indicator, worldbank_ireland_profile; eurostat: eurostat_search_datasets, eurostat_get_data, eurostat_compare_ie_eu; ecb: ecb_get_series, ecb_interest_rates, ecb_exchange_rate; pobal: pobal_deprivation_search; oireachtas: oireachtas_search_members, oireachtas_search_bills, oireachtas_get_debates, oireachtas_search_questions, oireachtas_get_votes; geohive: geohive_boundaries_at_point, geohive_locate, geohive_list_layers, geohive_query_layer; wikidata: wikidata_place, wikidata_entity; data-gov-ie: datagov_search_datasets, datagov_get_dataset, datagov_query_datastore; cro: cro_search_datasets, cro_get_dataset, cro_query_datastore; kohesio: kohesio_search_projects, kohesio_get_project; smart-dublin: smartdublin_search_datasets, smartdublin_get_dataset, smartdublin_query_datastore; met-eireann: met_get_forecast, met_get_observations, met_get_warnings; nta: nta_get_realtime_summary, nta_get_trip_updates; legislation: legislation_list_acts, legislation_get_act, legislation_get_section; ppr: ppr_search_sales, ppr_price_stats; irish-rail: rail_find_station, rail_get_departures; luas: luas_get_forecast, luas_list_stops; eirgrid: grid_get_status; marine: marine_get_buoys; opw-water: water_find_stations, water_get_level; planning: planning_search, planning_get; census-areas: census_small_area_at; epa: epa_wfd_search, epa_wfd_waterbody, epa_bathing_locations, epa_bathing_alerts, epa_bathing_measurements; heritage: heritage_monuments_near; environment-sites: protected_sites_at, protected_sites_near; ted: ted_search_tenders, ted_get_notice; bikes: bikes_networks, bikes_stations_near; failte-ireland: failte_search; tfi-static: tfi_static_search_stops; gsi: groundwater_vulnerability_at; logainm: logainm_search_places; cross: list_sources, ireland_snapshot, nearby.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Operation arguments. | |
| source | Yes | Source id. | |
| arguments | No | Alias of args. | |
| operation | Yes | Operation name. | |
| max_tokens | No | Result budget in tokens (default 2000). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: failed argument validation is non-fatal because it returns the expected schema plus an example, telling the agent it can safely retry with corrected args. It does not explain the max_tokens truncation behavior or how errors surface beyond that hint.
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 correctly — the core verb and behavior come first, then the catalog. But the catalog is roughly 90 operation names in one sentence, and since ireland_catalogue and ireland_describe exist as siblings, much of it may be redundant bulk that crowds out guidance on when to use this tool instead.
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 explained, and the enumerations cover source and operation values. What is missing for a dispatcher of this complexity is where per-operation argument schemas can be discovered before the first call, though the schema-on-error behavior partially compensates.
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 adds real meaning to the two required parameters: the schema only says 'Source id' and 'Operation name', while the description enumerates the exact valid values for both. That is meaningful disambiguation the schema lacks. The max_tokens budget parameter and the args/arguments aliasing are left to the 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 first sentence states a specific verb and resource: run a source operation with args. The following catalog makes the capability surface concrete by mapping each source id to its operations, so an agent knows exactly what this tool can dispatch. It does not, however, distinguish itself from siblings like ireland_describe or ireland_catalogue, which likely surface the same operation list.
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 implied by the catalog: pick a source, pick one of its operations, pass args. The note that bad args return the expected schema and an example implies probing is acceptable, but there is no explicit statement of when to use this versus ireland_describe (to inspect an operation) or ireland_catalogue (to browse sources), and no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sources and their operations, grouped by domain: stats, transport, environment, energy, economy, law/politics, places/property. Start here.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Only this domain. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that results are grouped by domain and include operations, but says nothing about result size, pagination, or freshness — useful but modest added 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?
Two short sentences, zero filler, with the resource and grouping stated first and the call-to-action last. Every clause earns its place.
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-value explanation is not required, and the description covers purpose plus entry-point role. The only gap is guidance on what to do with the catalogue once retrieved (i.e., which siblings to call next), which would make it fully self-sufficient.
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% and the single domain parameter has a fully enumerated schema description. The description's domain list mirrors the enum rather than adding new semantics such as interaction with grouping or whether omitting it returns everything, 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?
States a concrete verb and resource (lists sources and their operations) plus the grouping dimension (domain), so the agent knows exactly what comes back. It does not explicitly distinguish itself from siblings like ireland_about or ireland_describe, but the catalogue framing is unambiguous.
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?
"Start here" is an explicit entry-point directive, which is the most important usage signal for a discovery tool. It gives no explicit when-not or named alternative, 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.
Argument JSON schema, description and an example for one source operation.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source id, e.g. 'cso'. | |
| operation | Yes | Operation, e.g. 'cso_get_data'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description's only added content is the return payload (schema, description, example), which overlaps with the existing output schema, and it says nothing about auth, rate limits, or failure behavior.
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?
It is a single short sentence with no waste, but it is an incomplete fragment whose key information (the action) must be inferred, so brevity here shades into under-specification rather than concision.
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 explained, and annotations cover safety, leaving purpose and routing as the description's job — both are underdeveloped for a tool that must be chosen over three other ireland_* siblings.
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% and both parameters are documented in-schema with concrete examples ('cso', 'cso_get_data'). The phrase 'one source operation' is consistent with source+operation 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?
The description names the resource (one source operation) and what it yields (argument JSON schema, description, example), so the intent is inferable, but it is a noun-phrase fragment with no verb for the action. It does not distinguish itself from near siblings like ireland_catalogue or ireland_call, which also deal with source operations.
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?
There is no statement of when to use this tool versus ireland_call, ireland_catalogue, or ireland_about. The agent must infer that this is the introspection step preceding a call, with no explicit guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For a WGS84 point in Ireland: county, local authority, constituency, electoral division, small area and settlement (GeoHive), the nearest Met Éireann station and forecast, recorded monuments within 500 m (SMR) and NPWS protected sites at the point. Not live observations, river levels, buoys, bikes or populations: use ireland_call for those.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude, e.g. 53.3498. | |
| lon | Yes | Longitude, e.g. -6.2603. | |
| hours | No | Forecast hours to include. | |
| max_tokens | No | Result budget in tokens (default 2000). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-derivable context: the geographic constraint (Ireland-only, WGS84), the data provenance (GeoHive, SMR, NPWS), the 500 m search radius for monuments, and the warning that results are not live observations. It does not mention caching, freshness windows, or behavior for points outside Ireland, which keeps this at 4.
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, front-loaded with the result scope, then the exclusion/routing clause. The long enumeration is dense but each item is decision-relevant, so little is wasted; the only minor cost is that it reads as a catalogue rather than a terse directive.
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 formatting need not be described, and the description covers the dataset union, coordinate frame and scope well. The residual gap is what happens for coordinates outside Ireland and whether output is truncated by the token budget — relevant given the max_tokens parameter, though hinted at.
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 the baseline is 3. The description lifts it by specifying the coordinate reference frame (WGS84) and the Irish coverage area, which the schema's bare lat/lon numbers and bounds do not convey. Forecast hours and token budget are already fully documented in the 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 enumerates exactly what is returned for a WGS84 point in Ireland: administrative units (county, local authority, constituency, electoral division, small area, settlement via GeoHive), the nearest Met Éireann station and forecast, SMR monuments within 500 m, and NPWS protected sites. An agent can tell precisely what this tool produces without opening the schema, and the sibling ireland_call is explicitly named for other data types.
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 both sides of the routing decision: what is in scope, and an explicit exclusion list ("Not live observations, river levels, buoys, bikes or populations") paired with the alternative to use instead (ireland_call). This is exactly the when/when-not/alternative structure that lets an agent pick the right sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across Central Statistics Office (CSO) PxStat, National Council for Special Education open data, World Bank Indicators for Ireland, Eurostat Statistics API, Pobal HP Deprivation Index, Houses of the Oireachtas Open Data API, Wikidata Query Service, data.gov.ie (Ireland's open data portal), Companies Registration Office open data, Kohesio EU-funded projects, Smart Dublin open data (Dublin local authorities), Irish Statute Book (eISB) via ELI, EPA Ireland open data, EU Tenders Electronic Daily (TED). Returns ids like 'cso:F1001' to pass to fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to look for, e.g. 'population by county' or 'housing bill 2024'. | |
| max_tokens | No | Result budget in tokens (default 2000). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the set of upstream data sources queried (open-world scope made concrete) and the return shape ('ids like cso:F1001'). It does not mention pagination, result limits beyond max_tokens, or empty-result behavior.
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 handoff sentence ('Returns ids ... to pass to fetch') is well placed at the end and earns its keep. The bulk of the text is a 14-item comma-separated source list that is informative for scope but reads as a run-on enumeration rather than front-loaded, prioritized 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?
For a 2-parameter federated search tool with an output schema present, the description covers scope, sources, and the id format needed to chain into fetch, which is the key integration detail. Missing pieces are minor: no result-count expectations or behavior when a provider is unavailable.
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% and both parameters (query, max_tokens) are documented in the schema with examples and ranges. The description adds no parameter-level meaning beyond the schema – it does not explain query syntax, provider scoping, or how max_tokens interacts with multi-source results. Baseline 3 is appropriate when the schema carries the load.
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 clear verb ('Search') and resource (Irish public data) and enumerates the 14 federated sources, which pins down scope precisely. It also distinguishes itself from the sibling 'fetch' by stating it returns ids 'like cso:F1001' that are then passed to fetch. However, the enumeration substitutes for a description of what the search actually does (keyword matching? full text?), so it is clear but slightly thin on capability.
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 implies the correct workflow by saying ids are 'to pass to fetch', which is a useful chaining hint. It gives no explicit when-to-use guidance relative to siblings such as ireland_call, ireland_catalogue, or nearby, nor any when-not-to-use or scoping conditions. Usage is therefore implied rather than instructed.
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.
ireland_call1 field changedInput schema / properties / argumentsAdded value: +{
+ "additionalProperties": true,
+ "description": "Alias of args.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}fetch1 field changedOutput schema / additionalPropertiesPrevious value: -{}New value: +trueireland_about1 field changedOutput schema / additionalPropertiesPrevious value: -{}New value: +trueireland_call2 fields changedInput schema / properties / args / additionalPropertiesPrevious value: -{}New value: +trueOutput schema / additionalPropertiesPrevious value: -{}New value: +trueireland_catalogue1 field changedOutput schema / additionalPropertiesPrevious value: -{}New value: +trueireland_describe1 field changedOutput schema / additionalPropertiesPrevious value: -{}New value: +truenearby1 field changedOutput schema / additionalPropertiesPrevious value: -{}New value: +truesearch1 field changedOutput schema / additionalPropertiesPrevious value: -{}New value: +truefetchireland_aboutireland_callireland_catalogueireland_describenearbysearchOfficial UK, US and Australia public datasets as filtered CSV, REST API and MCP for AI agents.
data.gov.ie MCP — Ireland's national open-data portal (CKAN API).
Public statistics for Ireland and the UK: housing, crime, health, economy, welfare, with caveats.
Local government intelligence for AI agents.
Add one secure layer between your agents and this server.
