flatin.es — new builds and local data in Spain

Server Details

New-build homes on sale in Spain, buying costs, non-resident tax and local open data.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over the last 24 hours
Last Tested: 2026-11-09 12:28
Transport: Streamable HTTP · MCP 2025-11-25
URL
ChatGPT: –
Claude: –

TDQS

A3.7/5.0

Scored 2026-10-30 05:31 across 6 tools

Disambiguation3/5

The set has clear separations for new builds and the two tax calculators, but compare_places, place_facts, and ibi_rate overlap in providing municipal indicators. compare_places and place_facts are distinguishable by multi-place comparison vs single-place differentiation, but ibi_rate is also an indicator that compare_places can include, creating a real boundary ambiguity.

Naming Consistency3/5

All names use snake_case, which is readable and consistent at the character level. However, the structures vary: compare_places is verb-led while the rest are noun phrases, and newbuilds_in_place uses a prepositional phrase unlike the others. This is mixed convention rather than a predictable verb_noun pattern.

Tool Count5/5

Six tools is well within the appropriate range for a Spain property data and cost server. Each tool targets a recognizable data area: comparison, place facts, new builds, IBI, purchase costs, and non-resident tax. The count is not bloated and does not feel thin.

Completeness4/5

The surface covers the core advertised workflows: comparing places, retrieving place facts, listing new builds, and estimating IBI, purchase costs, and non-resident tax. Minor gaps remain, such as a way to discover which municipalities or buyer zones are published, and there is no standalone tool for detailed new-build lookup beyond the capped list.

Available Tools

6 tools

compare_placesCompare 2–4 places in Spain on local dataA

Read-onlyIdempotent

Inspect

Side-by-side latest figures for 2–4 municipalities (provinces of Alicante, Málaga, Valencia, Murcia) or buyer zones: housing prices (MIVAU), rent (SERPAVI), IBI, population, income, tourist lets, foreigners, air quality and more — at most 12 indicators per call. Each figure has its unit, period, level (municipality, or province when the place has none), source credit and date, and station or point of interest with distance. Only places whose flatin.es page is published get figures; every answer links the flatin.es pages.

Name	Required	Description
`locale`	No	Language of names and page links; default en.
`places`	Yes	2 to 4 places: a municipality of the provinces of Alicante, Málaga, Valencia or Murcia (name, slug, 'province/municipality' or 5-digit INE code) or a buyer zone (costa-blanca, costa-del-sol); prefix 'municipio:' / 'zona:' to disambiguate.
`indicators`	No	Up to 12 indicator keys; default: mivau_valor_tasado_total, rent_m2_median, ibi, padron29005, income_person, vt_viviendas, vt_pct, foreign_total, share_65plus, aq_no2_annual, aq_pm25_annual, tourist_occ_pct. Keys whose source terms do not allow export answer 'not_available' (the value is on the page).

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses genuinely useful behavior: per-figure unit, period, level fallback to province when a municipality has none, source credit and date, station distance, and the 'not_available' result for export-restricted indicators. It also notes that answers link the source pages, so an agent knows the return payload shape.

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

Conciseness4/5

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

The scope and indicator list are front-loaded and the caveats come after, with no filler sentences. It is dense—one long run-on sentence—but every clause carries information an agent uses.

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?

With no output schema, the description carries the burden of describing returns and does so: per-figure metadata, province-level fallback, 'not_available' sentinel, and source links. Combined with annotations declaring a safe read-only operation, an agent has everything needed to call it correctly.

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?

Schema description coverage is 100%, so the baseline is 3. The description largely restates what the schema already documents (default indicator list, place formats, export-restricted keys), adding the level-fallback nuance but little else beyond structured data.

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

Purpose4/5

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

The description opens with a specific verb+resource ('Side-by-side latest figures for 2–4 municipalities... or buyer zones') and enumerates the indicator families covered. It is clearly a multi-place comparison tool, but it never names the sibling tools (place_facts, ibi_rate, purchase_costs) an agent might otherwise pick, so sibling differentiation is left implicit.

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

Usage Guidelines4/5

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

It states the operational envelope clearly ('2–4 places', 'at most 12 indicators per call') and a real constraint ('Only places whose flatin.es page is published get figures'), which tells an agent when this will fail. It gives no explicit when-not or alternative routing to the single-indicator siblings.

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

ibi_rateIBI property-tax rate of a Spanish municipalityA

Read-onlyIdempotent

Inspect

Yearly IBI urbana rate (% of cadastral value) of a municipality, with year, provisional flag, source (Ministerio de Hacienda) and the flatin.es page.

Name	Required	Description	Default
`locale`	No	Language of names and page links; default en.
`municipio`	Yes	Municipality: name, slug, 'province/municipality' or 5-digit INE code.

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already establish the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description adds genuine value by disclosing the return payload fields — year, provisional flag, and source (Ministerio de Hacienda) — plus the flatin.es page reference, which matters because no output schema exists. It stops short of noting rate-limit or coverage caveats.

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

Conciseness4/5

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

A single compact sentence with the resource definition front-loaded and the returned fields trailing. No filler sentences, though the trailing clause is a slightly dense list.

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

Completeness4/5

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

For a simple two-parameter lookup with no output schema, the description covers what the value means, what accompanies it (year, provisional flag, source), and points to the originating page. Combined with annotations covering the safety profile and a 100%-covered schema, the definition is essentially complete; only cross-tool routing guidance is absent.

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?

Schema description coverage is 100%, so both parameters (municipio with its four accepted forms, and the locale enum defaulting to en) are already fully documented in the schema. The description adds nothing beyond that, which is the expected baseline here.

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

Purpose4/5

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

States a specific verb+resource+scope: the yearly IBI urbana rate for a Spanish municipality, expressed as % of cadastral value. This is unambiguous and highly specific. It does not differentiate itself from siblings like purchase_costs or non_resident_tax, so it falls short of a 5.

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

Usage Guidelines2/5

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

No statement of when to use this tool versus alternatives such as purchase_costs or non_resident_tax, and no preconditions or exclusions. Usage must be inferred purely from the tool name and the property-tax definition.

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

newbuilds_in_placeNew builds on sale in a place (Spain)A

Read-onlyIdempotent

Inspect

New-build developments on sale in a municipality, buyer zone or province of the flatin.es catalogue: at most 25 per call, sorted by name, no pagination — the full list is on the linked flatin.es page. Facts are the developer's own, latest check only, with attribution.

Name	Required	Description
`place`	Yes	Municipality (name, slug, 'province/municipality' or 5-digit INE code), buyer zone (costa-blanca, costa-del-sol) or province; prefix 'provincia:' / 'zona:' to disambiguate.
`locale`	No	Language of names and page links; default en.
`bedrooms`	No	Bedrooms wanted; 4 or more means 4+.
`max_price`	No	Highest budget in euros, VAT included: the price from must not exceed it. Must not be below min_price. Developments without a published price are left out.
`min_price`	No	Lowest budget in euros, VAT included. A development matches when its published price range overlaps [min_price, max_price]; with only a price from, that price must be at least min_price. Developments without a published price are left out.
`delivery_by`	No	Completion by the end of this year (this year to this year + 4); ready-to-move-in developments always match.
`max_beach_km`	No	Straight-line km from the development's own location to the nearest beach, rounded up to 1, 2, 5 or 10; only when the site offers the beach filter.

TDQS

A4/5.0

Behavior5/5

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

Beyond the annotations, the description discloses operationally important traits: at most 25 results per call, sorted by name, no pagination, full list available on the linked page, and that facts come from the developer with only the latest check and attribution. These are exactly the kinds of behavioral and data-quality details an agent needs before calling.

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?

The description is compact and front-loaded: resource and scope first, then result cap, sort order, pagination behavior, and data provenance. Every clause carries useful information with no wasted prose.

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

Completeness4/5

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

For a seven-parameter read-only listing tool with full schema coverage and no output schema, the description covers scope, result limits, and data freshness well. It could say a bit more about the shape of returned development facts, but it is largely complete for selection and invocation.

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?

Schema description coverage is 100%, so all seven parameters are already well documented in the schema. The description adds no meaningful parameter semantics beyond echoing the place types that the schema already explains in detail.

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

Purpose4/5

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

The description clearly states a specific resource and scope: new-build developments on sale in a municipality, buyer zone, or province in the flatin.es catalogue. It is immediately understandable, though it does not explicitly differentiate itself from the unrelated sibling tools such as purchase_costs or ibi_rate.

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

Usage Guidelines3/5

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

Usage is implied by the scope (new builds in a Spanish place) and the cap/no-pagination constraint is stated. However, there is no explicit when-to-use/when-not-to-use guidance or named alternative among the sibling tax and comparison tools.

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

non_resident_taxSpanish non-resident income tax (IRNR, modelo 210)A

Read-onlyIdempotent

Inspect

Yearly IRNR of a non-resident owner of a Spanish home: imputed income (1.1 % or 2 % of the cadastral value for days not let) and rental income (EU/EEA: 19 % net of expenses; others: 24 % on gross rent). Every line cites its law and check date; rules pending validation (RDL 29/2026) are listed, not applied. An estimate, not tax advice.

Name	Required	Description
`locale`	No	Language of names and page links; default en.
`revised`	Yes	true if the cadastral value was revised in a general valuation in force in the tax year or the ten previous ones (1.1 % instead of 2 %, LIRPF art. 85.1). The RDL 29/2026 extension to revisions since 2012 is not in force yet: older revisions are false.
`days_let`	No	Days let in the tax year (owned all year; the previous calendar year, 365 or 366 days); required when rent_eur_year > 0.
`eu_resident`	Yes	Tax resident of another EU/EEA state with tax information exchange (19 %, expenses deductible) — else 24 % on gross rent.
`rent_eur_year`	No	Rent received in the year, whole euros; default 0.
`expenses_eur_year`	No	Deductible expenses linked to the letting (only EU/EEA residents may deduct them); default 0.
`cadastral_value_eur`	Yes	Valor catastral of the property (IBI receipt), whole euros.

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already establish a safe, idempotent, closed-world read, and the description adds genuinely new behavioral context: every output line cites its law and check date, rules pending validation under RDL 29/2026 are listed but not applied, and the result is an estimate rather than advice. That is disclosure beyond what the structured fields provide.

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

Conciseness4/5

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

Purpose is front-loaded in the opening clause and every sentence carries tax-relevant content with no filler. The first sentence is dense with parenthetical rates, which slightly slows parsing but does not waste words.

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

Completeness4/5

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

With no output schema, the description usefully signals the shape of the result (line items with law citations) and the pending-rule handling, and the parameters are fully documented in the schema. It stops short of describing the output structure or units in detail, but for a read-only calculator it is close to complete.

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?

Schema description coverage is 100%, so both the 1.1%/2% revised-value logic and the 19%/24% residency split are already documented per-parameter. The description restates those rates at a high level but adds no syntax, format, or edge-case 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.

Purpose5/5

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

States a specific verb and resource — computing yearly IRNR for a non-resident owner of a Spanish home — and spells out the two income branches (imputed and rental). This is clearly distinct from all siblings (ibi_rate, purchase_costs, newbuilds_in_place, compare_places), which none touch income tax.

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

Usage Guidelines3/5

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

The domain (a non-resident owning a Spanish home) is implied by the description, but there is no explicit when-to-use framing, no prerequisites, and no reference to alternatives. The closing 'An estimate, not tax advice' is a caveat, not usage guidance.

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

place_factsWhat sets a Spanish municipality apart, with for/against rulesA

Read-onlyIdempotent

Inspect

For one municipality published on flatin.es (currently the provinces of Alicante, Málaga, Valencia, Murcia; comparisons use all of Spain): the indicators where it clearly differs from its province, Spain or its neighbours (rank, provincial median, Spanish percentile — only when at least 80% of applicable places have data), and fixed for/against rules on published data (prices, affordability in years of income, rent share of income, empty homes, crime per resident and with seasonal population, distances, fibre). Every number has its period and source. Not an opinion.

Name	Required	Description	Default
`place`	Yes	A municipality of the provinces of Alicante, Málaga, Valencia or Murcia: name, slug, 'province/municipality' or 5-digit INE code.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context beyond annotations: the 80% data-coverage threshold for rankings, the inclusion of periods and sources, and the fixed nature of the for/against rules. It does not describe output structure in detail, but the added context is substantial.

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

Conciseness3/5

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

The description front-loads the municipality scope, which is good, but it is delivered as a single dense sentence with multiple parentheticals. The content is relevant, yet the structure is cluttered and harder to scan than necessary. It is not wasteful, but it could be clearer with shorter sentences.

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

Completeness4/5

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

There is no output schema, so the description must explain what is returned; it does so by listing indicator types, data-coverage rules, and source/period guarantees. For a read-only single-parameter tool, this is enough to call it correctly. The main missing piece is explicit guidance on when to prefer compare_places.

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?

Schema description coverage is 100%, and the schema already documents the accepted place formats and supported provinces. The description reinforces the single-municipality scope and mentions flatin.es publication, but adds no new syntax or constraints beyond the schema. Baseline 3 is appropriate when the schema carries the parameter meaning.

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

Purpose4/5

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

The description clearly states that it returns facts for one municipality: differing indicators and fixed for/against rules on published data. It also names the covered provinces and clarifies that every number has a period and source. It does not explicitly distinguish itself from the sibling compare_places tool, so it falls short of a 5.

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

Usage Guidelines3/5

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

Usage is implied by the phrase 'For one municipality published on flatin.es', which suggests this tool is for a single-place profile rather than multi-place comparison. However, it does not explicitly say when to use compare_places instead or name any exclusion criteria. The agent can infer the context but is not given clear routing instructions.

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

purchase_costsPurchase costs of a home in SpainA

Read-onlyIdempotent

Inspect

Taxes and fees of buying a home in Spain: VAT + stamp duty (AJD) for a new build or transfer tax (ITP) for a resale at the general rate of the tax territory, plus notary and land registry by the official scales. Every line cites its law, article and the date it was checked. An estimate, not tax advice.

Name	Required	Description
`place`	Yes	Where the property is in Spain: municipality or province name, 5-digit INE code of the municipality or 2-digit province code; 'province/municipality' or a 'municipio:' / 'provincia:' prefix to disambiguate.
`locale`	No	Language of names and page links; default en.
`new_build`	Yes	true — first sale by the developer (VAT + stamp duty AJD); false — resale (transfer tax ITP).
`price_eur`	Yes	Price in whole euros WITHOUT VAT (new build) or the deed price (resale): taxes are computed on it.
`mortgage_eur`	No	Loan amount, optional: in Spain the lender pays the mortgage AJD, notary and registration (Ley 5/2019).

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior: every output line cites law, article, and verification date, and it discloses that fees use 'the general rate of the tax territory' and 'official scales' rather than any negotiated figure.

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

Conciseness4/5

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

Three sentences, front-loaded with the purpose, with no filler. The legal-citation and disclaimer sentences are compact and additive, though the tax-component enumeration is somewhat dense for an opening clause.

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

Completeness4/5

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

With no output schema, the description does useful work by signaling an itemized, law-cited result. Combined with a fully documented 5-parameter schema covering the mortgage carve-out (Ley 5/2019), an agent has enough to call it correctly; only the return structure and estimation assumptions remain slightly under-specified.

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?

Schema description coverage is 100%, so place, locale, new_build, price_eur, and mortgage_eur are all fully documented in the schema. The description's tax-regime explanation largely restates the new_build schema text, adding little parameter-level detail beyond confirming that place drives the applicable regional rate.

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 precise resource (taxes and fees of buying a home in Spain) and enumerates the specific components computed: VAT + AJD for new builds, ITP for resales, plus notary and registry fees. This cleanly separates it from siblings like ibi_rate (annual property tax) and non_resident_tax.

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

Usage Guidelines3/5

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

The scope implies usage (compute closing costs for a purchase) and the new_build distinction routes between the two tax regimes. However, there is no explicit guidance on when to use this versus compare_places or newbuilds_in_place, and no stated prerequisites or exclusions beyond the 'estimate, not tax advice' caveat.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 30, 2026

Changednewbuilds_in_place3 fields changed

changedInput schema / properties / max_price / description

Previous value: -"Budget in euros, VAT included: the price from must not exceed it. search_url uses the site's budget bucket rounded up (named in the answer). Developments without a published price are left out."New value: +"Highest budget in euros, VAT included: the price from must not exceed it. Must not be below min_price. Developments without a published price are left out."

changedInput schema / properties / max_price / minimum
```
Previous value: -1New value: +1000
```

addedInput schema / properties / min_price

Added value: +{
+  "description": "Lowest budget in euros, VAT included. A development matches when its published price range overlaps [min_price, max_price]; with only a price from, that price must be at least min_price. Developments without a published price are left out.",
+  "maximum": 100000000,
+  "minimum": 1000,
+  "type": "number"
+}

1 tool updateOct 28, 2026

Changednewbuilds_in_place4 fields changed

addedInput schema / properties / bedrooms

Added value: +{
+  "description": "Bedrooms wanted; 4 or more means 4+.",
+  "maximum": 20,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / delivery_by

Added value: +{
+  "description": "Completion by the end of this year (this year to this year + 4); ready-to-move-in developments always match.",
+  "maximum": 2100,
+  "minimum": 2000,
+  "type": "integer"
+}

addedInput schema / properties / max_beach_km

Added value: +{
+  "description": "Straight-line km from the development's own location to the nearest beach, rounded up to 1, 2, 5 or 10; only when the site offers the beach filter.",
+  "maximum": 10,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / max_price

Added value: +{
+  "description": "Budget in euros, VAT included: the price from must not exceed it. search_url uses the site's budget bucket rounded up (named in the answer). Developments without a published price are left out.",
+  "maximum": 100000000,
+  "minimum": 1,
+  "type": "number"
+}

2 tool updatesOct 28, 2026

Changedcompare_places1 field changed

changedInput schema / properties / indicators / items / enum

Previous value: -[
-  "ibi",
-  "padron29005",
-  "padron65032",
-  "mivau_valor_tasado_total",
-  "vt_viviendas",
-  "vt_plazas",
-  "vt_pct",
-  "rent_m2_median",
-  "rent_m2_p25",
-  "rent_m2_p75",
-  "income_person",
-  "income_household",
-  "income_uc_median",
-  "ftth_pct",
-  "mbps100_pct",
-  "gbps1_pct",
-  "g5_pct",
-  "foreign_total",
-  "foreign_gb",
-  "foreign_fr",
-  "foreign_de",
-  "foreign_nl",
-  "foreign_be",
-  "foreign_it",
-  "foreign_ro",
-  "foreign_ua",
-  "foreign_ru",
-  "foreign_ma",
-  "pop_total_censo",
-  "share_65plus",
-  "share_0_15",
-  "aq_no2_annual",
-  "aq_pm10_annual",
-  "aq_pm25_annual",
-  "aq_o3_days",
-  "clima_tmean_jan",
-  "clima_tmin_jan",
-  "clima_tmax_aug",
-  "clima_precip_year",
-  "clima_days_ge_30",
-  "clima_sun_hours",
-  "clima_prov_tmax",
-  "clima_prov_tmin",
-  "clima_prov_prec",
-  "crime_ttm_total",
-  "crime_ttm_violent",
-  "crime_ttm_home",
-  "crime_ttm_cyber",
-  "tourist_occ_pct",
-  "flood_t100_pct"
-]New value: +[
+  "ibi",
+  "padron29005",
+  "padron65032",
+  "mivau_valor_tasado_total",
+  "vt_viviendas",
+  "vt_plazas",
+  "vt_pct",
+  "rent_m2_median",
+  "rent_m2_p25",
+  "rent_m2_p75",
+  "income_person",
+  "income_household",
+  "income_uc_median",
+  "ftth_pct",
+  "mbps100_pct",
+  "gbps1_pct",
+  "g5_pct",
+  "foreign_total",
+  "foreign_gb",
+  "foreign_fr",
+  "foreign_de",
+  "foreign_nl",
+  "foreign_be",
+  "foreign_it",
+  "foreign_ro",
+  "foreign_ua",
+  "foreign_ru",
+  "foreign_ma",
+  "pop_total_censo",
+  "share_65plus",
+  "share_0_15",
+  "aq_no2_annual",
+  "aq_pm10_annual",
+  "aq_pm25_annual",
+  "aq_o3_days",
+  "clima_tmean_jan",
+  "clima_tmin_jan",
+  "clima_tmax_aug",
+  "clima_precip_year",
+  "clima_days_ge_30",
+  "clima_sun_hours",
+  "clima_prov_tmax",
+  "clima_prov_tmin",
+  "clima_prov_prec",
+  "crime_ttm_total",
+  "crime_ttm_violent",
+  "crime_ttm_home",
+  "crime_ttm_cyber",
+  "tourist_occ_pct",
+  "flood_t100_pct",
+  "afford_buy_years",
+  "afford_rent_pct",
+  "dwell_vacant_pct",
+  "dwell_sporadic_pct",
+  "crime_allanamiento",
+  "crime_usurpacion"
+]

Addedplace_facts

5 tool updatesOct 20, 2026
- First observedcompare_places
- First observedibi_rate
- First observednewbuilds_in_place
- First observednon_resident_tax
- First observedpurchase_costs

Related MCP Connectors

CasitaTaxA
com.casitatax
Spanish non-resident tax on a home in Spain: Modelo 210 estimate, deadlines, town cadastral data
Finance Government Data Real Estate
31
https://casitatax.com/mcp
HOUSINGFAXA
com.housingfax
Immediate home report for a building or flat in Spain: 22 checks from official public sources.
Real Estate Government Data Open Data
81
https://housingfax.com/mcp
Spain Open DataA
io.github.digvijaysingh-ai
Market sizing, prices, rents, crime and locations in Spain from INE and other public data
Open Data Government Data Location Services
131
https://spain-open-data-mcp-165703905656.europe-west1.run.app/mcp
EVS Property — Costa del Sol homesA
com.evsproperty.mcp
Homes for sale, long-term rentals and new builds on the Costa del Sol and in Málaga, Spain.
Real Estate Location Services
41
https://mcp.evsproperty.com/mcp

Related MCP Servers

pt.flatin/property-taxes
Real Estate Finance
devflatinpt
A
license
Not graded
quality
C
maintenance
Enables users to calculate Portuguese property purchase costs (IMT, stamp duty, deed/registration) and query annual IMI rates and costs for all 308 municipalities, with sourced figures.
Updated 2 months ago (2026-09-16 18:35 UTC)
MIT
catalogo-fuentes-publicas
Government Data Open Data Search
BquantFinance
A
license
B
quality
A
maintenance
Enables AI agents and developers to search and inspect Spanish public data sources, learn their endpoints and pitfalls, and retrieve ready-made data such as municipal profiles, economic indicators, company records, procurement, subsidies, and location reports.
Updated a month ago (2026-10-05 18:22 UTC)
13
130
Creative Commons Zero v1.0 Universal
Spain Open Data MCP
Government Data Open Data Location Services
digvijaysingh-ai
A
license
A
quality
B
maintenance
Enables answering business questions about Spanish places by resolving place names and returning population, household and income statistics down to municipality, district and census tract level from official INE data, cross-checked between sources with province, region and country benchmarks. Every figure is delivered with its publisher, dataset id, data year and retrieval date, alongside caveat checks for suppressed, stale, thin-sample or estimated values.
Updated 22 days ago (2026-10-18 10:59 UTC)
13
MIT
Spain Open Data MCP
Government Data Open Data Real Estate
gabicuesta
A
license
A
quality
B
maintenance
Enables AI assistants and agents to query Spanish public statistics from INE, official BOE publications, and Catastro property data via typed, read-only tools with structured, source-citable results.
Updated 8 days ago (2026-11-01 07:12 UTC)
8
MIT

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.

Resources

Need Help?