Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@verifactu-qr what's the VeriFactu QR URL for NIF 89890001K, invoice 12345678&G33, date 01-01-2024, amount 241.4?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
URL del código QR tributario de VeriFactu (AEAT) y validación de NIF/CIF/NIE — sin dependencias, en una sola línea.
Herramienta en Python para generar la URL que debe llevar el QR obligatorio de las facturas españolas (RD 1007/2023 · Orden HAC/1177/2024) validando antes NIF, número de serie, fecha e importe, con los códigos de error oficiales de la AEAT (2001-2006). Incluye CLI y servidor MCP para agentes de IA.
Mantenido por Plataforma IA, consultora de automatización con IA para pymes en Madrid y toda España. Guía de plazos y preparación: VeriFactu 2027 para pymes.
pip install verifactu-qr # solo librería + CLI (0 dependencias)
pip install "verifactu-qr[svg]" # + exportar el QR a SVG (segno)Related MCP server: mcp-europe-business
$ verifactu-qr qr --nif 89890001K --numserie "12345678&G33" --fecha 01-01-2024 --importe 241.4
https://www2.agenciatributaria.gob.es/wlpl/TIKE-CONT/ValidarQR?nif=89890001K&numserie=12345678%26G33&fecha=01-01-2024&importe=241.4
# entorno de pruebas, sistema que NO remite registros (no VERI*FACTU) y QR en SVG
$ verifactu-qr qr --nif 89890001K --numserie "12345678&G33" --fecha 01-01-2024 --importe 241.4 \
--pruebas --no-verifactu --svg qr.svg
$ verifactu-qr validar 89890001K
VALIDO: 89890001K (DNI)from verifactu_qr import build_qr_url, nif_valido, url_consulta_json
url = build_qr_url(
nif="89890001K",
numserie="12345678&G33", # se codifica como 12345678%26G33 (URL encoding UTF-8)
fecha="01-01-2024", # o un datetime.date
importe=241.4, # o "241.40", Decimal
verifactu=True, # False -> .../ValidarQRNoVerifactu
entorno="produccion", # o "pruebas"
)
print(url)
print(url_consulta_json(url)) # añade &formato=json para parsear la respuesta de la AEATErrores con el código oficial: QRError.code ∈ {2001 NIF inválido, 2002 nº de serie demasiado
largo, 2003 caracteres no permitidos, 2004 fecha inválida, 2005 importe inválido, 2006 importe
demasiado largo}.
{
"mcpServers": {
"verifactu-qr": { "command": "verifactu-qr-mcp" }
}
}Herramientas expuestas: verifactu_qr_url, validar_identificacion_fiscal, url_consulta_json.
Probarlo a mano:
$ printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' | verifactu-qr-mcpCubre: los 4 parámetros obligatorios del QR (nif, numserie, fecha, importe), las 4
URLs base (producción/pruebas × VERI*FACTU/no verificable), el URL encoding con la misma
semántica que java.net.URLEncoder (el detalle que más falla: & → %26, espacio → +), la
validación con dígito de control de NIF/NIE/CIF y los códigos de error de la AEAT.
No cubre: la huella (hash) de encadenamiento de registros, la firma electrónica XAdES, el
envío SOAP de registros ni el diseño/maquetación del QR dentro del PDF (30-40 mm, nivel M).
Para eso, ver pyverifactu o verifactu en PyPI.
Aviso: herramienta no oficial, sin vinculación con la AEAT. Verifica siempre el resultado con el portal de pruebas de la AEAT antes de producción.
Real Decreto 1007/2023, de 5 de diciembre (BOE-A-2023-24840).
Orden HAC/1177/2024, arts. 20 y 21 (contenido del QR: NIF, serie y número, fecha, importe).
AEAT, «Características del QR y especificaciones del servicio de cotejo» (sede electrónica).
Los tests incluyen el vector de ejemplo oficial de la AEAT
(nif=89890001K, numserie=12345678&G33 → 12345678%26G33, fecha=01-01-2024, importe=241.4).
PYTHONPATH=src python -m unittest discover -s tests -vMIT — úsalo libremente en tu software de facturación.
verifactu-qr builds the URL that Spanish invoices must embed in their mandatory tax QR code
(VeriFactu, RD 1007/2023) while validating the Spanish tax ID, invoice number, date and amount,
returning the official AEAT error codes. Zero dependencies, plus a CLI and a stdio MCP server so
AI agents can generate compliant QR URLs. Maintained by Plataforma IA,
an AI automation consultancy based in Madrid, Spain.
Añade formato=json a una URL de QR para consultar el servicio de la AEAT en JSON (no va dentro del QR).
| Name | Required | Description | Default |
|---|---|---|---|
| url_qr | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure alone. It does disclose the transformation (adding formato=json) and a meaningful constraint (the result is not embedded in the QR), but it is silent on whether a network request to AEAT is actually made, what is returned, or any auth requirement, leaving ambiguity for a service-querying tool.
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 sentence with the action front-loaded ('Añade formato=json a una URL...'), and the parenthetical constraint earns its place by preventing misuse. Nothing is padded.
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 one-parameter tool with no output schema and no annotations, the description covers purpose and transformation but omits what the call returns (a modified URL vs. service data) and expected input format. Adequate but with clear gaps given structured fields carry none of the load.
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?
There is one parameter (url_qr) at 0% schema description coverage. The description identifies the input as 'una URL de QR', which matches the field name and adds a little meaning, but gives no format, encoding, or validation guidance for that string.
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 concrete action on a concrete resource: it appends 'formato=json' to a QR URL so the AEAT service is queried in JSON. This goes beyond restating the name. It does not, however, explicitly name or contrast itself with siblings like verifactu_qr_url, so the agent must infer the split from the trailing parenthetical.
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 only implied: the note '(no va dentro del QR)' tells the agent that the modified URL is for querying the service rather than for embedding in the QR, which hints at when to reach for this versus the QR-generating sibling. There is no explicit when-to-use/when-not statement or named alternative, so it stays at the implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comprueba si un NIF, NIE o CIF español tiene formato y dígito de control correctos.
| Name | Required | Description | Default |
|---|---|---|---|
| identificacion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the check covers both format and check digit and is inherently a non-mutating verification, which is useful. It does not state the return value (e.g., boolean vs. error message), how malformed input is surfaced, or whether it rejects empty strings, so key operational behavior is left implicit.
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?
One front-loaded sentence with zero filler. Every clause earns its place by naming the operation, the identifier types, and the two validation dimensions.
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 simple single-parameter validation tool the description covers the essential purpose, but there is no output schema and no annotations, so return semantics should have been stated and are not. An agent knows what to send but not what to expect back.
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 0% and the single 'identificacion' parameter has no schema-level description, so the description must compensate. It usefully identifies the accepted input domain (NIF, NIE, CIF), but adds no format guidance (spaces, hyphens, casing, length) to help construct a valid value.
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 specific verb ('Comprueba si') and a precise resource set (NIF, NIE, CIF) plus the exact validation scope (formato y dígito de control). It is unambiguous about what the tool checks, but it never differentiates itself from the sibling tools, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the validation semantics: an agent can infer it should call this when it needs to verify a Spanish tax identifier. However, there is no explicit when-to-use statement, no mention of when not to use it, and no pointer to any alternative among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Genera la URL del código QR tributario de una factura española (VeriFactu, RD 1007/2023 y Orden HAC/1177/2024) validando NIF, número de serie, fecha e importe.
| Name | Required | Description | Default |
|---|---|---|---|
| nif | Yes | NIF del obligado a expedir la factura (9 caracteres) | |
| fecha | Yes | fecha de expedición en formato DD-MM-AAAA | |
| entorno | No | por defecto produccion | |
| importe | Yes | importe total, punto decimal, máximo 12 enteros y 2 decimales | |
| numserie | Yes | serie y número de factura, máximo 60 caracteres | |
| verifactu | No | true si el sistema remite los registros a la AEAT (VERI*FACTU); por defecto true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does disclose one concrete behavioral trait: the inputs are validated ('validando NIF, número de serie, fecha e importe'). However it says nothing about failure behavior when validation rejects an input, whether any network/registry call occurs, or auth requirements, leaving meaningful behavioral gaps.
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 verb first and the resource immediately after; the regulatory citations are dense but arguably earn their place by anchoring the output to a legal standard. No filler or redundant sentences, though the clause structure is somewhat packed.
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 and no annotations, the description does identify the return value (a QR URL) and the validated inputs, which is the core an agent needs. The optional entorno and verifactu parameters, which materially change the generated URL, are left entirely to the schema, so it is not fully complete for a regulatory tool.
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 all six parameters including formats (DD-MM-AAAA, 9 chars, 60 chars) and defaults. The description merely restates the four validated parameters and adds no syntax or constraint 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Genera la URL del código QR tributario de una factura española', grounded in named regulations (VeriFactu, RD 1007/2023, Orden HAC/1177/2024). An agent understands exactly what is produced. It does not explicitly differentiate itself from the sibling url_consulta_json, which is also a URL generator, so it stops 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the purpose — the agent can infer it is used when a VeriFactu QR URL is needed. There is no explicit when-to-use/when-not-to-use, no prerequisites, and no naming of the sibling url_consulta_json as the alternative, which is a real routing risk given both tools emit URLs.
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.
v0.1.0url_consulta_jsonvalidar_identificacion_fiscalverifactu_qr_urlScored across 3 tools
The three tools target distinct operations: generating a VeriFactu QR URL, validating a Spanish tax ID, and appending format=json for AEAT JSON queries. The two URL-related tools (verifactu_qr_url and url_consulta_json) could be momentarily confused, but the descriptions clearly separate generation from query-format transformation.
Names mix Spanish and English and mix verb-first (validar_identificacion_fiscal) with noun-first patterns (verifactu_qr_url, url_consulta_json). Although all use snake_case, the underlying conventions are inconsistent, making the set feel ad hoc.
Three tools is on the thin side for the stated purpose, though the domain (VeriFactu QR generation) is narrow enough that a small surface is defensible. It borders on under-scoped.
The core generation and validation workflow is covered, but there is no tool to decode/parse an existing QR URL or validate a full invoice payload, leaving some notable gaps. The JSON-query helper partially compensates but the lifecycle feels incomplete.
Spanish e-invoicing with VeriFactu (AEAT): issue invoices, manage customers, validate NIFs.
Spanish Veri*factu invoicing: create invoices, expenses and VAT returns from your AI assistant.
Validate EU, UK, AU VAT numbers for AI agents. EU ViDA e-invoicing compliance.
Free no-auth tools for Spain: validate IBAN, EU VAT check (VIES), Modelo 303 sums, Veri*factu dates.
