mcp-facturacion-electronica-es

Overview Schema Source Related Servers Discussions Admin

Es Submit Verifactu To Aeat

es__submit_verifactu_to_aeat

Submits a signed VERI*FACTU XML record to AEAT's real-time endpoint via mTLS using FNMT-RCM certificate. Handles deferred status with retry and confirmation token for human approval.

Instructions

Envía un registro VERI*FACTU firmado al endpoint en tiempo real de la AEAT mediante MTLS.

Usa el certificado FNMT-RCM. Requiere AEAT_ENV, AEAT_CERTIFICATE_PATH y AEAT_CERTIFICATE_PASSWORD. Si la respuesta trae parsed_response.status == 'deferred' (TiempoEsperaEnvio), espere retry_after_seconds y llame a es__query_verifactu_status para confirmar el EstadoRegistro final antes de encadenar el siguiente registro.

HUMAN-IN-THE-LOOP: llame sin confirmation_token para recibir un resumen de confirmación y un token; muéstrelo al usuario y vuelva a llamar con confirmation_token para ejecutar el envío real.

Input Schema

TableJSON Schema

Name	Required	Description
`nif`	Yes	NIF del remitente.
`xml`	Yes	Registro VERI*FACTU XML firmado.
`confirmation_token`	No	Token de la respuesta awaiting_confirmation previa.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.8.0Aug 26, 2026

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

addedInput schema / properties / confirmation_token

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Token de la respuesta awaiting_confirmation previa."
+}

changedOutput schema / (root)

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

First observedv0.0.1May 14, 2026

TDQS

A4.2/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full load, and it does so thoroughly: it discloses the mTLS requirement, FNMT-RCM certificate, required environment variables, the deferred-response behavior, and the two-phase confirmation flow where a call without confirmation_token returns a summary and token rather than executing the real send. This is critical non-schema information.

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 structured as a one-sentence purpose followed by two focused blocks on deferred response and human-in-the-loop flow. It is somewhat longer than minimal, but every sentence conveys behavior that an agent cannot get from the schema or annotations.

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?

Given the output schema and the absence of annotations, the description provides all essential surrounding context: environment/auth prerequisites, confirmation workflow, deferred handling, and follow-up tool. Whatever the output schema documents is not discussed, which is acceptable, and no critical gap is evident for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds value, especially for confirmation_token, explaining that it comes from an 'awaiting_confirmation' response and that a call without it returns a summary instead of executing the real send. It does not add new semantics for nif or xml, but the baseline is 3, and the token detail earns a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: 'Envía un registro VERI*FACTU firmado al endpoint en tiempo real de la AEAT mediante MTLS.' It clearly identifies the operation as submission to AEAT, distinguishing it from query/generate/validate tools. It does not explicitly contrast with sibling submission tools such as es__submit_to_face, though the resource and goal are unambiguous.

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

Usage Guidelines4/5

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

The description gives clear when-to-use guidance: send a signed VERI*FACTU record to AEAT, and if the response has parsed_response.status == 'deferred', wait retry_after_seconds and call es__query_verifactu_status. It also explains the human-in-the-loop call pattern. It lacks explicit when-not-to-use or alternative-tool exclusions, 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.