Spain Open Data MCP

Resolve a Spanish place

resolve_place

Read-onlyIdempotent

Convert Spanish place names into INE codes and geographic levels (region, province, municipality, district, tract), returning best matches and alternatives for accurate data lookup.

Instructions

Find the INE code and level (CCAA, province, municipality, district, tract) for a place in Spain.

Use this first when a question names a place. Returns the best match first, with
alternatives (e.g. 'Valencia' is both a city and a province). Handles accents, Basque,
Catalan and Galician names, and common English names (Seville, Catalonia).
Neighbourhood names are not supported; use districts or tracts from `demographics`
or `income` with `sub_areas`.

Input Schema

Name	Required	Description	Default
`query`	Yes	Place name or INE code, e.g. 'A Coruña', 'Mérida, Badajoz', '08'.

Output Schema

Name	Required	Description
`data`	Yes
`checks`	No
`sources`	Yes
`confidence`	Yes	Lowest confidence across inputs: high, medium or low. Never state a conclusion more strongly than this.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.1Oct 17, 2026

addedOutput schema / $defs / Place / properties / official_name

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "INE's form of the name when it differs ('Palmas de Gran Canaria, Las').",
+  "title": "Official Name"
+}

First observedv0.1.0Oct 16, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: best match returned first with alternatives for ambiguous names ('Valencia'), and multilingual/accent handling. It doesn't discuss rate limits or result counts, but with an output schema present that gap is minor.

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?

Three short sentences, front-loaded with the core action, then usage, then the ambiguity/unsupported-input caveats. No filler and every sentence carries distinct information.

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?

An output schema exists so return values need not be restated, annotations cover the safety profile, and the single parameter is fully documented. The description covers entry conditions, ambiguity behavior, and an unsupported input class — nothing an agent needs to call this correctly is missing.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter and schema coverage is 100%, including examples ('A Coruña', 'Mérida, Badajoz', '08'), so the schema already carries the semantics. The description's mention of ambiguity is about results rather than the query parameter itself, so it adds little param-level detail. Baseline 3 applies.

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?

States a specific verb and resource: 'Find the INE code and level (CCAA, province, municipality, district, tract) for a place in Spain.' It even enumerates the output level taxonomy, so an agent can distinguish this geocoding/resolution tool from data-fetching siblings like demographics or income.

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?

Explicitly says 'Use this first when a question names a place', and names the when-not case with an alternative: neighbourhood names are unsupported, use districts or tracts from `demographics` or `income` with `sub_areas`. That is a direct routing rule to specific siblings.

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

Deploy Server