Skip to main content
Glama

flatin.es — new builds and local data in Spain

Spanish non-resident income tax (IRNR, modelo 210)

non_resident_tax
Read-onlyIdempotent

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.

Input Schema

NameRequiredDescriptionDefault
localeNoLanguage of names and page links; default en.
revisedYestrue 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_letNoDays let in the tax year (owned all year; the previous calendar year, 365 or 366 days); required when rent_eur_year > 0.
eu_residentYesTax resident of another EU/EEA state with tax information exchange (19 %, expenses deductible) — else 24 % on gross rent.
rent_eur_yearNoRent received in the year, whole euros; default 0.
expenses_eur_yearNoDeductible expenses linked to the letting (only EU/EEA residents may deduct them); default 0.
cadastral_value_eurYesValor catastral of the property (IBI receipt), whole euros.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources