mcp-facturacion-electronica-es

Overview Schema Source Related Servers Discussions Admin

Es Generate Qr Verifactu

es__generate_qr_verifactu

Generate the VERI*FACTU QR code required by Spanish tax regulation (HAC/1177/2024) as a base64 PNG, encoding the AEAT verification URL from invoice data.

Instructions

Genera el código QR obligatorio VERI*FACTU (HAC/1177/2024 Art. 10) como PNG en base64.

Encodes la URL de verificación de la AEAT: https://www2.agenciatributaria.gob.es/wlpl/TIKE-CONT/ValidarQR?...

Input Schema

TableJSON Schema

Name	Required	Description
`nif`	Yes	NIF del emisor.
`size_px`	No	Tamaño del QR en píxeles (por defecto: 200).
`invoice_date`	Yes	FechaExpedicionFactura en YYYY-MM-DD.
`total_amount`	Yes	ImporteTotal de la factura (con IVA incluido).
`invoice_number`	Yes	NumSerieFactura.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.8.0Aug 26, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

First observedv0.0.1May 14, 2026

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses the output format (PNG in base64) and the encoded URL, which is useful. However, it does not mention whether the QR is generated locally, whether any network call is made, or what the output schema contains beyond the base64 PNG.

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 description is concise and front-loaded with the core purpose and regulation. The second sentence adds the encoded URL context. It is slightly truncated (ends with '...'), which is a minor structural flaw, but overall it is efficient and focused.

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

Completeness3/5

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

The tool has an output schema and 100% parameter coverage, so the description need not explain return values or parameters in depth. However, with no annotations, the description could have clarified whether the QR generation is offline or calls AEAT, and how the output is returned. The core purpose is clear, but behavioral context is thin.

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 schema already documents all parameters. The description adds the context that these fields map to the AEAT QR URL, but it does not add meaning beyond the schema's field descriptions. Baseline 3 is appropriate.

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?

The description clearly states the tool's purpose: generating the mandatory VERI*FACTU QR code as a base64 PNG, and cites the specific regulation (HAC/1177/2024 Art. 10). It also names the encoded AEAT verification URL, which distinguishes it from sibling tools that handle records, submission, or status queries.

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 description implies the tool is for generating the QR code for a specific invoice, but it does not explicitly state when to use it versus alternatives like es__generate_verifactu_record or es__submit_verifactu_to_aeat. The regulatory citation and QR-specific wording provide context, but no explicit when/when-not guidance is given.

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