mcp-facturacion-electronica-es

Overview Schema Source Related Servers Discussions Admin

Es Query Verifactu Status

es__query_verifactu_status

Check the final VERI*FACTU registration status after a deferred submission, confirming whether the invoice was accepted, accepted with errors, or cancelled before continuing.

Instructions

Consulta el EstadoRegistro de un registro VERI*FACTU ya enviado.

(ConsultaFactuSistemaFacturacion / ConsultaLR.xsd). Use esta tool tras un resultado 'deferred' de es__submit_verifactu_to_aeat, esperando retry_after_seconds, para confirmar el estado final (Correcto / AceptadoConErrores / Anulado) antes de encadenar el siguiente registro. Requiere AEAT_ENV, AEAT_CERTIFICATE_PATH y AEAT_CERTIFICATE_PASSWORD, igual que es__submit_verifactu_to_aeat.

Input Schema

TableJSON Schema

Name	Required	Description
`nif`	Yes	NIF del obligado a la emisión (ObligadoEmision).
`name`	Yes	Nombre/razón social del obligado a la emisión.
`invoice_date`	Yes	Fecha de la factura consultada, YYYY-MM-DD (determina PeriodoImputacion).
`num_serie_factura`	No	NumSerieFactura a filtrar (omitir para consultar todo el período).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.8.0Aug 26, 2026

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

changedInput schema / properties / invoice_date / description

Previous value: -"Fecha de la factura consultada, YYYY-MM-DD (determina PeriodoImputacion)."New value: +"Fecha de la factura consultada, YYYY-MM-DD (determina\nPeriodoImputacion)."

addedInput schema / properties / num_serie_factura / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / num_serie_factura / default
```
Added value: +null
```

changedInput schema / properties / num_serie_factura / description

Previous value: -"NumSerieFactura a filtrar (omitir para consultar todo el período)."New value: +"NumSerieFactura a filtrar (omitir para consultar\ntodo el período)."

removedInput schema / properties / num_serie_factura / type
```
Removed value: -"string"
```

changedOutput schema / (root)

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

Addedv0.7.0Aug 14, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses that the operation is a query ('Consulta') implying read-only behavior, and it lists the required authentication environment variables (AEAT_ENV, AEAT_CERTIFICATE_PATH, AEAT_CERTIFICATE_PASSWORD). It also states the expected final states it will return. However, it does not explicitly mention error handling or side effects, but the 'consulta' semantics and workflow coverage are sufficient. A minor gap is not stating whether repeated calls are safe or how to handle non-final states, but overall it is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: it starts with the purpose, then gives the precise usage trigger and next steps, and finally lists the required environment variables. Each sentence is purposeful and no filler is present. It is front-loaded with the core action, making it easy for an agent to quickly understand the tool's role.

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?

The description covers the essential context for correct invocation: it explains when to call (after deferred result), what to wait for (retry_after_seconds), and what to expect (final states). It also states the required environment variables. Since an output schema exists (though not shown), return value details are likely handled there. The only minor omission is guidance on repeated calls or handling unexpected states, but overall it is complete for an agent to use correctly in the described workflow.

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% – each parameter already has a description explaining its meaning (NIF, name, invoice_date, num_serie_factura). The tool description does not add any new information about the parameters; it merely restates the workflow context. Since the schema already documents the parameters well, the description adds no additional value here, meeting the baseline of 3.

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 verb 'Consulta' (query) and the resource: the registration status (EstadoRegistro) of an already-sent VERI*FACTU record. It also references the specific XSD schema, which further pinpoints the operation. This clearly distinguishes it from siblings like es__submit_verifactu_to_aeat (submit) and es__cancel_verifactu_record (cancel), making it unambiguous what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage guidance: use this tool after a 'deferred' result from es__submit_verifactu_to_aeat, wait for retry_after_seconds, and confirm the final state (Correcto / AceptadoConErrores / Anulado) before proceeding. It also mentions required environment variables identical to the sibling submit tool, which helps the agent prepare. This is clear when-to-use guidance with no ambiguity.

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