mcp-facturacion-electronica-es

Overview Schema Source Related Servers Discussions Admin

Es Submit To Face

es__submit_to_face

Submit a XAdES-signed Facturae XML to Spain's FACe e-invoicing gateway using B2B API. Requires administrative, accounting, and management codes; includes a two-step confirmation for safe submission.

Instructions

Envía un XML Facturae firmado con XAdES a FACe a través de la API REST B2B de FACe v2.

FACe = Punto General de Entrada de Facturas Electrónicas. Autenticación JWS (RS256 + x5c) per FACe-manual-api-integradores.pdf s2.3: requiere FACE_ENV y AEAT_CERTIFICATE_PATH (+ AEAT_CERTIFICATE_PASSWORD).

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
`xml`	Yes	XML Facturae con firma XAdES.
`management_body`	Yes	Código OrganoGestor de FACe.
`accounting_office`	Yes	Código OficinasContables de FACe.
`confirmation_token`	No	Token de la respuesta awaiting_confirmation previa.
`administrative_unit`	Yes	Código UnidadTramitadora de FACe.

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.3/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the two-phase human-in-the-loop behavior, the authentication mechanism, and the fact that the first call returns an awaiting_confirmation response. It does not explicitly state that the second call is the actual submission, but that is clearly implied by 'para ejecutar el envío real'. It could add details about side effects or idempotency, but the core behavioral traits are well covered.

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 compact and front-loaded with the core action, then expands the acronym, then gives authentication context, then the human-in-the-loop flow. Every sentence earns its place. It loses one point because the authentication details are dense and could be slightly more structured, but overall it is efficient and well-organized.

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 tool has an output schema, so return values are already documented. The description covers the essential context: what FACe is, how authentication works, and the two-step confirmation flow. It does not mention error cases or what happens if the token is invalid, but for a submission tool with an output schema, the provided context is strong. A 4 is warranted because it is nearly complete for an agent to invoke correctly.

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 five parameters. The description adds context for confirmation_token (explaining it comes from a prior awaiting_confirmation response) and for xml (specifying it must be XAdES-signed), which is useful. However, it does not explain the meaning of administrative_unit, accounting_office, or management_body beyond their schema descriptions, so the baseline of 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 states a specific verb ('Envía'), a specific resource (XML Facturae firmado con XAdES), and a specific destination (FACe via API REST B2B v2). It also expands the acronym FACe, which disambiguates it from sibling tools like es__submit_verifactu_to_aeat and es__submit_sii_batch. The human-in-the-loop confirmation flow further distinguishes it from other submission tools.

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 explicitly explains when to call without confirmation_token (to get a summary and token) and when to call again with confirmation_token (to execute the real send). It also names the authentication requirements (JWS RS256 + x5c, FACE_ENV, AEAT_CERTIFICATE_PATH, AEAT_CERTIFICATE_PASSWORD), which are prerequisites an agent must know before invoking. 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.