Free no-auth tools for Spain: validate IBAN, EU VAT check (VIES), Modelo 303 sums, Veri*factu dates.
Scored across 6 tools
Each tool targets a distinct resource or operation: VAT return summation (calculate_modelo_303), general VAT/IRPF computation (calculate_vat), EU VAT number lookup (check_vat_number), deadline information (get_obligation_dates), IBAN validation (validate_iban), and Spanish tax ID validation (validate_spanish_tax_id). Descriptions explicitly clarify boundaries and limitations, so an agent can select correctly.
All tool names use snake_case and follow a consistent verb_noun pattern (calculate_, check_, get_, validate_), with clear and predictable naming throughout.
Six tools is well-scoped for a focused set of Spanish tax/accounting utility functions; each tool earns its place without redundancy.
Covers core calculations and validations (VAT, IBAN, Spanish tax ID, EU VAT lookup, key deadlines), but notable gaps remain for a Spanish tax toolkit, such as other tax models (111, 115, 130) and a broader tax calendar. These are workaroundable but limit full lifecycle coverage.
Add up the boxes (casillas) of the Spanish quarterly VAT return Modelo 303 with the formulas printed on the official AEAT form: 27, 45, 46, 64, 66, 87, 69 and 71. Input are the tax amounts (cuotas) per box, e.g. {"09": 17430, "29": 9870}. It only sums what it is given: it does not decide which rate or deduction applies and it is not a tax return.
| Name | Required | Description | Default |
|---|---|---|---|
| casillas | Yes | Box number -> amount. Accepted: 152, 167, 03, 155, 06, 09, 11, 13, 15, 158, 170, 18, 21, 24, 26, 29, 31, 33, 35, 37, 39, 41, 42, 43, 44, 58, 76, 65, 77, 110, 78, 68, 108, 70, 109 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, and the description reinforces that with 'it only sums what it is given,' confirming a side-effect-free, closed-world computation. It additionally discloses which formulas drive the output and that no tax determination occurs, adding real context beyond the annotations, though it says nothing about error behavior on unknown or missing box keys.
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?
Three sentences, front-loaded with the action, then the accepted box list, then the example and the scope caveat. Every sentence carries information, though the inline enumeration of eight box numbers is slightly dense and could have been left to the schema.
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 single-parameter, no-output-schema computation tool with readOnlyHint annotations, the description covers purpose, input shape, the formulas applied, and the negative scope. The one gap is the return shape (which computed boxes the agent gets back), which the absence of an output schema leaves unstated.
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% and the nested casillas object already lists all accepted box numbers, so the baseline is 3; the description adds a concrete input example ({"09": 17430, "29": 9870}) and clarifies the values are cuotas per box. This meaningfully disambiguates the expected key format beyond the schema's terse 'Box number -> amount'.
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 precise verb (add up), the exact resource (the boxes/casillas of Spanish quarterly VAT return Modelo 303), and the rule set used (AEAT form formulas for boxes 27, 45, 46, 64, 66, 87, 69, 71). An agent can distinguish this pure-arithmetic tool from the unrelated sibling utilities (check_vat_number, validate_iban, get_obligation_dates) immediately.
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?
Explicitly delimits scope: 'it only sums what it is given: it does not decide which rate or deduction applies and it is not a tax return,' which tells the agent when this tool is and is not the right call. It does not, however, name any alternative tool or workflow for the cases it excludes, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the taxable base, VAT (IVA) amount, optional recargo de equivalencia and optional IRPF withholding from an amount. By default importe is the taxable base (sin IVA). With incluye_iva=true, importe is the TOTAL with VAT already included and the base is derived backwards (quitar IVA / reverse VAT). It only applies the rates it is given: it does NOT decide which VAT or IRPF rate applies to a case.
| Name | Required | Description | Default |
|---|---|---|---|
| irpf | No | IRPF withholding rate in %, e.g. 15, 19. Default 0 | |
| importe | Yes | Amount: taxable base, or total with VAT if incluye_iva=true | |
| recargo | No | Recargo de equivalencia rate in %, e.g. 5.2, 1.4, 0.5, 1.75. Default 0 | |
| tipo_iva | Yes | VAT rate in %, e.g. 21, 10, 4, 0 | |
| incluye_iva | No | True if `importe` already includes VAT (reverse calculation) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true so safety is covered. Beyond that, the description adds meaningful context: the default interpretation of `importe`, the reverse-calculation mode, and the strict 'only applies given rates' constraint. It does not describe the output structure, but no output schema exists, so more could have been said about returned fields.
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?
Three tight sentences, front-loaded with the operation and immediately followed by the mode logic and scope limit. No filler; every sentence 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?
Given five parameters, 100% schema coverage, and no output schema, the description is largely complete for correct invocation. The remaining gap is that it never describes what the response returns (base, VAT, IRPF amounts), which an agent needs to interpret the 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 already 100%, so parameter docs are mostly redundant. However, the description adds real semantic value the schema text only partially covers: that `importe` is the base by default and becomes the VAT-inclusive total when incluye_iva=true, which is a non-obvious default behavior.
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 gives a precise verb (Compute) and enumerated outputs (taxable base, VAT amount, recargo, IRPF withholding), and the title/body tie it specifically to Spanish IVA/IRPF. This distinguishes it clearly from siblings like calculate_modelo_303 (a specific tax form) and check_vat_number.
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 clearly states the two operation modes (base-first default vs. reverse with incluye_iva=true) and explicitly delimits the tool's scope with 'it does NOT decide which VAT or IRPF rate applies.' The negative scope is helpful, though it does not point to a sibling for rate determination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an EU VAT number in the European Commission's VIES registry. Returns what the registry says: whether the number exists and, where the member state publishes it, the name and address. It draws NO tax conclusion. VIES is often down; that is reported as disponible=false, which is NOT the same as an invalid number.
| Name | Required | Description | Default |
|---|---|---|---|
| pais | No | ISO country code (e.g. DE); omit when the number carries its prefix | |
| numero | Yes | VAT number, with or without country prefix |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds genuinely non-obvious context: VIES is unreliable, downtime surfaces as disponible=false, and a third-party registry's answer is not a tax determination. These are failure-mode and semantic caveats an agent cannot derive from annotations or 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?
Three tight sentences, front-loaded with what the tool does, then what it returns, then the two critical caveats. Zero filler; every sentence carries decision-relevant 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?
With no output schema, the description compensates by describing return content (existence, and member-state-dependent name/address) and the special disponible=false signal. Nothing an agent needs to call and interpret this tool is missing.
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 both parameters (pais, numero) are already documented in the schema, including the prefix rule. The description adds no parameter-level detail beyond that, 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?
States a specific verb and resource (look up an EU VAT number in the European Commission's VIES registry) and is clearly distinct from sibling accounting/validation tools like validate_iban. An agent knows exactly what domain question this tool answers.
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?
Gives strong contextual guidance on interpretation – 'It draws NO tax conclusion' and how to read an outage (disponible=false is not an invalid number). It does not explicitly name alternatives or state when-not-to-use versus siblings, 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.
Deadlines from the published Spanish rules: Veri*factu (RD 1007/2023, dates of RD-ley 15/2025) and mandatory B2B e-invoicing (RD 238/2026, counted from the ministerial order, provisional while the order is a draft). Information about the rules, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
| forma | Yes | sociedad = company paying Impuesto sobre Sociedades; autonomo = self-employed | |
| mas_8_millones | No | Turnover above 8 million EUR last year | |
| factura_a_empresas | Yes | Invoices other businesses or professionals in Spain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so safety and closed-world scope are covered. The description adds real value beyond that: it flags that the e-invoicing dates are provisional 'counted from the ministerial order' while the order is a draft, and that output is 'information about the rules, not advice' – important caveats for relying on the answer.
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, no filler. The purpose and legal basis are front-loaded, and the provisional/not-advice caveats are packed economically at the end.
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 read-only lookup tool with annotations covering safety and required params covering input, the definition is essentially complete. It does not describe the shape of the returned deadline data, but with no output schema that gap is minor and the description signals the domains the dates span.
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%, including the enum semantics for forma and the meaning of factura_a_empresas, so the schema does the heavy lifting. The description adds only tacit context (which regimes the answers pertain to) and no per-parameter detail beyond the schema; 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 resource (Spanish compliance deadlines) and names the exact regimes (Veri*factu, mandatory B2B e-invoicing) with their legal citations. This clearly separates it from the calculation/validation siblings (calculate_modelo_303, check_vat_number, validate_iban), though the phrasing leads with the rules rather than a crisp verb+object like 'returns deadline dates for a taxpayer profile'.
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 required taxpayer-profile parameters (forma, factura_a_empresas), but the description never states when to reach for this tool versus a sibling, nor any prerequisites or exclusions. No alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether an IBAN is well formed: country length (SWIFT IBAN registry) and ISO 13616 check digits. For Spanish IBANs also the two account check digits (DC) and the bank (entidad) with its BIC from the Banco de España registry. A 20-digit Spanish account number (CCC) is converted to its IBAN. Pure arithmetic: it does NOT confirm that the account exists or who owns it.
| Name | Required | Description | Default |
|---|---|---|---|
| iban | Yes | IBAN or 20-digit Spanish account, spaces allowed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description adds substantive behavior: it is pure arithmetic against registry data, it discloses which registries are consulted (SWIFT, Banco de España), and it explicitly caps its own guarantees by saying it does not verify account existence or ownership. That last point is exactly the kind of limitation an agent needs and is not available anywhere in the structured fields.
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?
Three dense sentences, front-loaded with the core check and then narrowing to the Spanish-specific behavior and the limitation. Every clause carries information; nothing is restated from the name or 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?
For a single-parameter, read-only validation tool, the description covers inputs, checks performed, and limits. The only gap is that, with no output schema, it never indicates the shape of the result (e.g., valid/invalid plus reasons), which an agent may need to interpret the response.
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 baseline is 3. The description goes beyond the schema by clarifying that a 20-digit Spanish account (CCC) is accepted and internally converted to its IBAN, and that spaces are tolerated, which disambiguates the single parameter's accepted 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?
States a specific verb (validate/check) and resource (IBAN), then enumerates exactly which checks are performed: SWIFT country length, ISO 13616 check digits, and Spanish DC/entidad/BIC. This is clearly distinct from siblings like check_vat_number, so an agent can route correctly without opening any schema.
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 gives a clear context of use (well-formedness validation) and draws an explicit boundary: it does NOT confirm the account exists or who owns it. It also notes the CCC-to-IBAN conversion path. It stops short of naming alternatives or stating when-not-to-use conditions, so it is strong but not fully routing-aware.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Two modes in one input. If valor is only 1-8 digits, computes the DNI check letter and returns the full 8-digit-plus-letter DNI (digits are left-padded with zeros). If valor is a full document, validates its check character: DNI (8 digits + letter), NIE (X/Y/Z + 7 digits + letter) or CIF (entity letter + 7 digits + check digit or letter, with the entity type per Orden EHA/451/2008). Tolerates spaces, dots, dashes and an ES prefix. Pure arithmetic: it does NOT confirm the document exists, is active or belongs to the person who gave it.
| Name | Required | Description | Default |
|---|---|---|---|
| valor | Yes | 1-8 digits, or a full DNI/NIE/CIF |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only establish readOnlyHint=true and openWorldHint=false; the description goes well beyond by disclosing the precise semantics of each branch, the tolerated input noise (spaces, dots, dashes, ES prefix), and an explicit negative scope statement that it does NOT confirm the document exists, is active, or belongs to the caller. That last clause is exactly the kind of caveat that prevents an agent from over-trusting the result.
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?
Three densely packed sentences, front-loaded with the organizing idea ("Two modes in one input") so the agent knows the branching logic before reading details. Every clause carries operative information; nothing is filler or 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?
There is no output schema, and the description compensates by stating what each branch returns (the derived check letter / full 8-digit-plus-letter DNI vs. a validity determination). Combined with the mode selection rules and negative scope, an agent has everything needed to call it and interpret the 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% (baseline 3), but the description substantially enriches it: it defines the two accepted input classes, the exact accepted document formats, zero-padding behavior, and separator/prefix tolerance that the schema's one-line "1-8 digits, or a full DNI/NIE/CIF" does not convey.
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+resource: it computes or validates the check character of a Spanish DNI, NIE or CIF. That resource is narrow enough to be instantly separable from the sibling tools (validate_iban, check_vat_number, calculate_vat), which target different identifier families.
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?
Explicitly frames usage around input shape: "If `valor` is only 1-8 digits... If `valor` is a full document...", which tells the agent exactly which behavior to expect for a given call. It stops short of naming alternatives or stating when-not to use it, so it earns a 4 rather than a 5.
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.
calculate_vatvalidate_spanish_tax_idcalculate_modelo_303check_vat_numberget_obligation_datesvalidate_ibanSpanish e-invoicing with VeriFactu (AEAT): issue invoices, manage customers, validate NIFs.
8 invoice/payment tools; 5 free, no login. IBAN, bank changes, Peppol. Paid VAT and invoice review.
Free EU VAT, IBAN and bol.com commission tools for marketplace sellers
Italian tax + anti-fraud: CF, P.IVA, IBAN, ATECO, IMU, F24, FatturaPA, NIS2. 23 free + 5 with key.
Add one secure layer between your agents and this server.
