Spanish non-resident tax on a home in Spain: Modelo 210 estimate, deadlines, town cadastral data
Scored across 3 tools
Each tool targets a clearly distinct sub-task: computing the tax amount, determining filing deadlines, and looking up municipal cadastral values/rates. The descriptions even explain the hand-off between town_cadastral_data and estimate_modelo_210, so an agent can sequence them without misselection.
estimate_modelo_210 follows a verb_noun pattern, but modelo_210_deadlines and town_cadastral_data are noun phrases with no verb, so the set mixes conventions. Names remain readable and domain-specific, but there is no predictable pattern across the three.
Three tools match the narrow scope of a Modelo 210 simulator companion, each earning its place (rate lookup, estimate, deadlines). It is on the thin side, but for this focused domain it is reasonable rather than excessive or trivially minimal.
The core workflow is covered end to end: obtain the imputed-income rate from cadastral data, estimate the tax per owner, and learn the filing window. Minor gaps exist around edge cases such as regional regimes (País Vasco/Navarra excluded) and no tool for retrieving or validating an already-filed return, but the stated simulator purpose is well served.
Use this when a non-resident owner of a home in Spain asks how much Modelo 210 (Spanish non-resident income tax on the property) they owe for a tax year. Works out each owner's tax on the imputed income of the days the home wasn't let and on the rent, as CasitaTax's simulator does, and returns the method, the sources and a link that opens the simulator with the same answers.
| Name | Required | Description | Default |
|---|---|---|---|
| rent | No | For rented or part: the rent received for the whole home during the tax year, in euros, before expenses. | |
| owners | No | Number of owners, 1 to 6, with equal shares. Default 1. | |
| revised | No | Whether the town's cadastral values were revised collectively and in force since the year the rules require (town_cadastral_data tells). Default unknown: the tax is then a range. | |
| expenses | No | For rented or part, owners resident in the EU or the EEA: the deductible expenses of the rented period for the whole home, in euros. Ignored for others, who are taxed on the gross rent. | |
| language | No | Language of the CasitaTax pages linked in the answer: da, de, en, es, fr, nl, no, fi or sv. Default en. | |
| tax_year | No | Tax year (the year the income relates to). Default: the latest year whose rules are final. | |
| occupancy | Yes | unrented: not let during the tax year (own use, empty); rented: let all year; part: let part of the year. | |
| residence | Yes | Where the owners live for tax purposes: eu (a country of the EU, or Iceland, Norway, Liechtenstein), uk (United Kingdom), other (anywhere else). One value for all the owners. | |
| rented_days | No | For occupancy part: the number of days the home was let during the tax year. | |
| shares_percent | No | Each owner's share of the home in percent, when the shares differ (e.g. [60, 40]); they add up to 100. Replaces owners. | |
| cadastral_value | Yes | The home's valor catastral in euros, for the tax year: on the IBI receipt (total, not just the land or the building). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive behavior, so the safety profile is covered. The description adds real value by disclosing the return shape (method, sources, a simulator link carrying the same answers) and the imputed-income-plus-rent computation. It doesn't mention that the result becomes a range when cadastral revision status is unknown — that caveat lives only in the schema.
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 'use this when' trigger, followed by what it computes and returns. No filler, no restatement of the title.
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?
Despite 11 parameters and no output schema, the description covers both the input situation and what comes back (method, sources, deep link), so an agent can decide and call correctly. Remaining detail is fully carried by a 100%-covered schema.
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 each of the 11 parameters is documented in-schema with enums and defaults, so baseline 3 applies. The description only echoes the occupancy/rent split conceptually and adds no format, default, or interdependency detail beyond 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?
It names a specific verb (estimate the tax owed) and resource (Modelo 210 non-resident income tax), and the scope is narrow enough to separate it from modelo_210_deadlines (dates) and town_cadastral_data (cadastral values). It also states the computation model — imputed income for unlet days plus rent, split per owner.
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 opening clause gives an explicit trigger condition: a non-resident owner of a Spanish home asking how much Modelo 210 they owe for a given year. No when-not cases or sibling alternatives are named, though the schema's reference to town_cadastral_data hints at the pairing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks when a Spanish Modelo 210 (non-resident income tax) is due for a home in Spain: not let, let all year, let part of the year, or sold. Returns each return's filing window, the direct debit's last day, whether the window is open today, what filing late costs, and the sources (Orden HAC/623/2026 changed the windows from tax year 2026).
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language of the CasitaTax pages linked in the answer: da, de, en, es, fr, nl, no, fi or sv. Default en. | |
| sale_date | No | For sold: the day of the sale (the deed), YYYY-MM-DD. Without it, the rule is given without dates. | |
| situation | Yes | not_rented: the home wasn't let (own use, empty); rented: let all year; rented_part_of_year: let some of the year; sold: the home was sold. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the bar is lower, yet the description still discloses the return payload (filing window, direct debit last day, open-today flag, late-filing cost, sources) and a regulatory caveat (Orden HAC/623/2026 changed windows from tax year 2026). It does not state what happens without sale_date, but the schema does.
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 trigger condition first and the return contents after; every clause carries information. The nested parenthetical and situation list make it dense but not wasteful.
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?
There is no output schema, and the description compensates by enumerating what is returned, including the late-filing penalty and source citation. Combined with full schema coverage and safety annotations, an agent has what it needs; only edge-case behavior (e.g., missing sale_date output shape) is left implicit.
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 schema already documents situation, sale_date and language including enum meanings and the fallback when sale_date is omitted. The description adds no parameter meaning beyond that, 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 specific verb and resource ('when a Spanish Modelo 210 ... is due') and scopes it to a home in Spain across four enumerated situations. That is clearly distinct from the sibling estimate_modelo_210, which computes an amount rather than a filing window.
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?
'Use this when someone asks when ... is due' plus the four enumerated situations gives a concrete trigger condition. It does not explicitly rule out alternatives or name the sibling tools, so it stops 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.
Use this when someone needs to know about a Spanish town's cadastral values: the year of its last general revaluation, whether that means the 1.1% or the 2% imputed-income rate for a tax year (pass the revised value to estimate_modelo_210), and its urban IBI rate on homes. From the Catastro's statistics and the Ministerio de Hacienda's open data; País Vasco and Navarra aren't covered.
| Name | Required | Description | Default |
|---|---|---|---|
| ine | No | The town's 5-digit INE code, instead of town and province (e.g. 29069 for Marbella). | |
| town | No | The municipality's name, in Spanish or in the regional language (e.g. Marbella, Jávea or Xàbia). Not a district or an urbanisation: the town it belongs to. | |
| language | No | Language of the CasitaTax pages linked in the answer: da, de, en, es, fr, nl, no, fi or sv. Default en. | |
| province | No | The town's province (e.g. Málaga, Alicante, Illes Balears, Santa Cruz de Tenerife), or its 2-digit code. Needed with town. | |
| tax_year | No | Tax year (the year the income relates to). Default: the latest year whose rules are final. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-open-world and non-destructive, so the safety profile is covered; the description adds real context on top: the upstream sources (Catastro statistics and Ministerio de Hacienda open data) and a hard coverage limitation that would otherwise cause silent bad answers for Basque and Navarran towns. It does not discuss response shape, but annotations plus the enumerated outputs carry most of that burden.
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 that opens with the trigger and packs output fields, sourcing, downstream use and coverage caveats into one pass with no filler. It reads as a slightly run-on nested construction, which costs a little scannability, but every clause carries information.
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 five-parameter, all-optional lookup with no output schema, the description covers what comes back, where it comes from, and where it stops being valid. The one notable gap is that with zero required parameters it never says an identifier (ine, or town plus province) is effectively mandatory to get a result.
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 goes beyond the schema by tying tax_year to the concrete consequence of the 1.1% versus 2% rate choice, which explains why the parameter matters rather than just what it is. It still leaves the ine-vs-town/province selection entirely 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?
States a specific resource (a Spanish town's cadastral values) and enumerates exactly what is returned: last general revaluation year, the resulting 1.1% vs 2% imputed-income rate, and the urban IBI rate on homes. It also positions itself against the sibling by naming estimate_modelo_210 as the consumer of the computed value, so an agent can tell the two apart without opening schemas.
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?
"Use this when someone needs to know about..." gives an explicit trigger, and the description states a concrete handoff ("pass the revised value to estimate_modelo_210"), which clarifies the division of labour with that sibling. It adds a geographic exclusion (País Vasco and Navarra aren't covered), though it never frames a genuine alternative tool to prefer instead.
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.
estimate_modelo_210modelo_210_deadlinestown_cadastral_dataNew-build homes on sale in Spain, buying costs, non-resident tax and local open data.
Immediate home report for a building or flat in Spain: 22 checks from official public sources.
Spanish invoicing (Verifactu/TicketBAI), bookkeeping, bank and tax returns for autónomos and SLs.
Run your rentals in Spain from your AI assistant: SES filings, VeriFactu invoices, rent, taxes.
Add one secure layer between your agents and this server.