mcp-cfdi-mx

Overview Schema Source Related Servers Discussions Admin

Mx Seal Cfdi

mx__seal_cfdi

Seal a CFDI 4.0 Comprobante XML locally using your CSD key and certificate, or return it unsealed for a PAC to seal on your behalf.

Instructions

Seal (or deliberately not seal) a CFDI 4.0 Comprobante, PAC-agnostic.

sealing_mode="local" computes the cadena original via the actual SAT XSLT transform (resources/cadenaoriginal_4_0.xslt, with its utilerias.xslt and Pagos20.xslt includes resolved from resources/; any other complemento include a document might reference is not in Phase-1 scope and stubs to a no-op template — see SelloDigitalSigner's docstring), then computes Sello/NoCertificado/Certificado via mcp_einvoicing_core.digital_signature.SelloDigitalSigner — no local reimplementation of the signing algorithm.

sealing_mode="pac" returns xml unchanged: some PACs accept an unsealed, schema-valid CFDI and seal it on the emisor's behalf. This tool does not submit to any PAC — see the package README for the PAC-agnostic design.

CSD key material is always a file path, never accepted as plaintext key content in a tool argument.

Returns a dict with:

xml: the sealed (or, for "pac", unchanged) XML string
sealing_mode: echoes the mode used

Input Schema

TableJSON Schema

Name	Required	Description
`xml`	Yes	The unsealed CFDI 4.0 Comprobante XML, as returned by mx__build_cfdi/mx__build_pago
`key_path`	No	Path to the CSD's encrypted PKCS#8 DER private key (.key). Required when sealing_mode='local'.
`cert_path`	No	Path to the CSD's DER-encoded certificate (.cer). Required when sealing_mode='local'.
`key_password`	No	Passphrase for the private key. Required when sealing_mode='local'. This is a secret that transits the tool call as plain text — callers should source it from an environment variable or secrets manager reference on their side rather than hardcoding it, the same as cert_path/key_path are file references rather than inline key material.
`sealing_mode`	Yes	'local': compute Sello/NoCertificado/Certificado from the supplied CSD. 'pac': return the XML unchanged, for a PAC that seals on the emisor's behalf.
`no_certificado`	No	The CSD's 20-digit serial number from the SAT enrollment acknowledgment (acuse). Not derived from the certificate bytes — no confirmed algorithm exists for that derivation, see SelloDigitalSigner's docstring. Required when sealing_mode='local'.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Sep 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden, and it does so thoroughly: it discloses the SAT XSLT-based algorithm, the no-op stub limitation for out-of-scope complementos, the fact that PAC mode leaves XML unchanged, the no-PAC-submission design, and the rule that key material must be file paths. No annotation contradiction exists.

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 long but every sentence earns its place: purpose, mode-specific behavior, key-material policy, and return contract. It is front-loaded with the core purpose and uses clear mode blocks instead of burying the main behavior in prose.

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

Completeness5/5

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

For a tool with this complexity, the description is complete: it covers both modes, prerequisites for local sealing, the PAC passthrough behavior, scope limitations, and the return shape. The output schema exists, and the description still summarizes the return fields, so an agent has enough context to invoke the tool correctly.

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

Parameters5/5

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

The schema already documents all six parameters with 100% coverage, so the baseline is 3. The description adds substantial meaning beyond the schema: which parameters are required when sealing_mode='local', the no_certificado derivation caveat, the secret-handling guidance for key_password, and the expected provenance of the xml argument. This clearly exceeds the baseline.

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 opens with a specific verb+resource: 'Seal (or deliberately not seal) a CFDI 4.0 Comprobante'. It clearly names the two sealing modes and the PAC-agnostic scope, which distinguishes this tool from the sibling build/validate/verify tools in the same domain.

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?

It explicitly states when to use each mode: 'local' computes the seal from the CSD, while 'pac' returns the XML unchanged for a PAC that seals on the emisor's behalf. It also clarifies that the tool does not submit to any PAC. It stops short of naming sibling alternatives for later validation/verification, so it is not a perfect 5.

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

Deploy Server