io.github.cmendezs/mcp-cfdi-mx
PYPI · MCP-CFDI-MX · SCANNED SEP 20
MCP server for Mexican electronic invoicing (CFDI 4.0, Pagos 2.0)
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security100
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs hatchling.build at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
- 2 of 29 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency48
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (Apache-2.0).Pass
- Actively maintained (last published 7 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability61
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 2183 tokens (~363/item across 6 items; 6 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management60
- Stability observed for 18 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 6 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 7 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
How do I install the io.github.cmendezs/mcp-cfdi-mx server?
io.github.cmendezs/mcp-cfdi-mx runs locally as a PyPI package, launched with uvx mcp-cfdi-mx. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · mcp-cfdi-mx
claude mcp add cmendezs-mcp-cfdi-mx -- uvx mcp-cfdi-mx
{
"mcpServers": {
"cmendezs-mcp-cfdi-mx": {
"command": "uvx",
"args": [
"mcp-cfdi-mx"
]
}
}
} {
"servers": {
"cmendezs-mcp-cfdi-mx": {
"command": "uvx",
"args": [
"mcp-cfdi-mx"
]
}
}
} codex mcp add cmendezs-mcp-cfdi-mx -- uvx mcp-cfdi-mx
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"cmendezs-mcp-cfdi-mx": {
"type": "local",
"command": [
"uvx",
"mcp-cfdi-mx"
],
"enabled": true
}
}
} openclaw mcp add cmendezs-mcp-cfdi-mx --command uvx --arg mcp-cfdi-mx
mcp_servers:
cmendezs-mcp-cfdi-mx:
command: "uvx"
args: ["mcp-cfdi-mx"] {
"McpServers": {
"cmendezs-mcp-cfdi-mx": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"mcp-cfdi-mx"
]
}
}
} assistant mcp add cmendezs-mcp-cfdi-mx -t stdio -c uvx -a mcp-cfdi-mx
{
"mcpServers": {
"cmendezs-mcp-cfdi-mx": {
"command": "uvx",
"args": [
"mcp-cfdi-mx"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 19 Sept 26 +16
- Malware scan: unverified → pass ▲ security
- 18 Sept 26 −15
- Malware scan: pass → unverified ▼ security
- 17 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 47 to 50. That category is still filling its 30-day observation window: 14 days of observed history at the previous scan, 15 at this one. The score rises as the window fills, whether or not the server changes.
- 15 Sept 26 +16
- Malware scan: unverified → pass ▲ security
- 14 Sept 26 −15
- Malware scan: pass → unverified ▼ security
- 13 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.
- 12 Sept 26 +15
- Tool safety: pass → unverified ▼ security
- Stability: 0.30 → unverified ▼ security
- Malware scan: unverified → pass ▲ security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- First check of Schema quality: unverified functional
- Package version: 0.4.0 → 0.4.1 functional
- 11 Sept 26 −15
- Malware scan: pass → unverified ▼ security
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 20 Sept 2026 · Analysed pypi/mcp-cfdi-mx@0.4.1
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | pypi |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | hatchling.build |
Background: Why install scripts are a supply-chain risk →
Dependencies 29 packages
| Packages resolved | 29 |
|---|---|
| Stale | 1 |
| No linked repository | 1 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
mx__build_cfdi Mx Build Cfdi ~317
Build a well-formed, unsealed CFDI 4.0 `Comprobante` XML (Ingreso or Egreso). `comprobante_data` is validated against `CFDIComprobante` — see that model for the full field list (`seller`/`buyer` as `MXEmisor`/ `MXReceptor`, `lines` as `CFDIConcepto`, `tipo_de_comprobante`, etc.). RFC fields are validated via `TaxIdentifier.validate_mx_rfc` as part of model construction; a malformed RFC is reported as a validation error, not a generated document. The output XML omits `Sello`/`NoCertificado`/`Certificado` — those three schema-required attributes are populated by `mx__seal_cfdi`, run afterward. `mx__validate_cfdi` run on this output is expected to report exactly those three attributes missing; that is not a bug in this tool. For `TipoDeComprobante="P"` (Complemento de Pagos), use `mx__build_pago` instead — this tool only builds Ingreso/Egreso Comprobantes. Returns a dict with: - ``xml``: the generated, unsealed CFDI 4.0 XML string - ``total``: the computed `Total` attribute (SubTotal - Descuento + traslados - retenciones)
| Name | Type | Req | Description |
|---|---|---|---|
| comprobante_data | object | yes | Fields matching the CFDIComprobante schema (Ingreso or Egreso only) |
Structured output declared, but exposes no named fields.
No examples provided.
mx__build_pago Mx Build Pago ~329
Build a well-formed, unsealed Complemento de Pagos 2.0 CFDI. Composes the fixed single-`Concepto` wrapper SAT's Guía de llenado de pagos mandates for a Pago-type `Comprobante` (`ClaveProdServ`, `ClaveUnidad`, `Descripcion`, `ValorUnitario`, `Importe`, `ObjetoImp` are all fixed conventional values — see this module's docstring constants) with the `Pagos20` complement built from `pagos_data`, and attaches the complement under `cfdi:Complemento`. `buyer.uso_cfdi` is forced to `"CP01"` (the schema requires it for every Pagos CFDI per the same guide, regardless of what the caller passes) — mirrors how this tool already forces `SubTotal`/`Moneda`/etc. The output XML omits `Sello`/`NoCertificado`/`Certificado`, same as `mx__build_cfdi` — seal afterward with `mx__seal_cfdi`. Returns a dict with: - ``xml``: the generated, unsealed CFDI XML string (with the Pagos complement attached)
| Name | Type | Req | Description |
|---|---|---|---|
| comprobante_data | object | yes | Fields matching CFDIComprobante, minus SubTotal/Moneda/FormaPago/MetodoPago/CondicionesDePago/lines/TipoDeComprobante — all fixed or derived for a Pagos CFDI, do not supply them |
| pagos_data | object | yes | Fields matching the Pagos20 schema |
Structured output declared, but exposes no named fields.
No examples provided.
mx__get_supported_scope Mx Get Supported Scope ~155
Return the CFDI document types, complementos, and sealing modes this package supports. Reflects Phase 1 scope: CFDI 4.0 Ingreso + Egreso + Complemento de Pagos 2.0, PAC-agnostic sealing. Build (`mx__build_cfdi`/`mx__build_pago`), XSD validation (`mx__validate_cfdi`), sealing (`mx__seal_cfdi`), and TFD verification (`mx__verify_tfd`) are all implemented. PAC submission transport and later-phase complementos are not. Returns: A `ScopeInfo` describing current scope, for callers to check before assuming a document type or complemento is supported.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| out_of_scope | array | – | Capabilities deliberately not implemented yet |
| phase | integer | yes | Package's own delivery-phase number |
| schema_version | string | yes | Wire-format schema version this package targets |
| sealing_modes | array | yes | – |
| supported_complementos | array | yes | – |
| supported_document_types | array | – | Document-type codes supported today |
No examples provided.
mx__seal_cfdi Mx Seal Cfdi ~554
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
| Name | Type | Req | Description |
|---|---|---|---|
| cert_path | – | – | Path to the CSD's DER-encoded certificate (.cer). Required when sealing_mode='local'. |
| key_password | – | – | 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 manag… |
| key_path | – | – | Path to the CSD's encrypted PKCS#8 DER private key (.key). Required when sealing_mode='local'. |
| no_certificado | – | – | 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 d… |
| sealing_mode | string | 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. |
| xml | string | yes | The unsealed CFDI 4.0 Comprobante XML, as returned by mx__build_cfdi/mx__build_pago |
Structured output declared, but exposes no named fields.
No examples provided.
mx__validate_cfdi Mx Validate Cfdi ~335
Validate a CFDI 4.0 document against the official SAT XSD schemas. Always validates the root `Comprobante` against `cfdv40.xsd`. If a `TimbreFiscalDigital` complement is present (i.e. the document has been stamped by a PAC), it is additionally validated against `TimbreFiscalDigitalv11.xsd.xml`. If a `Pagos` complement is present (`TipoDeComprobante="P"`), it is additionally validated against `Pagos20.xsd.xml`. This is XSD-only — business-rule checks from SAT's Matriz de errores (`specs/MatrizDeErrores_CFDI_v40_20260325.xls`) are not run, mirroring `mcp-nfe-br`'s `br__validate_nfe_xml` precedent (XSD-first, business rules deferred). A document that passes this validator is structurally conformant but not guaranteed to pass PAC certification. Returns a dict with: - ``valid``: True only if every schema that applies passed - ``comprobante``: the `cfdv40.xsd` validation result - ``tfd``: the TFD validation result, present only if a `TimbreFiscalDigital` element was found - ``pagos``: the Pagos 2.0 validation result, present only if a `Pagos` element was found
| Name | Type | Req | Description |
|---|---|---|---|
| xml | string | yes | The CFDI 4.0 Comprobante XML to validate, as a string |
Structured output declared, but exposes no named fields.
No examples provided.
mx__verify_tfd Mx Verify Tfd ~369
Parse a Timbre Fiscal Digital 1.1 stamp and, optionally, verify SelloSAT. Always returns the TFD's own attributes (`UUID`, `FechaTimbrado`, `RfcProvCertif`, `SelloCFD`, `NoCertificadoSAT`, `SelloSAT`, ...) and the recomputed cadena original (via `cadenaoriginal_TFD_1_1.xslt`, per Anexo 20 Rubro III.B). If `pac_certificado_der_b64` is supplied, additionally verifies `SelloSAT` (SHA-256 + RSA-PKCS#1v1.5, the same algorithm as the emisor's own Sello) against that certificate's public key. Without it, `sello_sat_verified` is `null` — parsing succeeded but cryptographic verification was not attempted, not "passed". Returns a dict with: - ``found``: False if no `TimbreFiscalDigital` element exists in *xml* - ``fields``: the TFD's own attributes - ``cadena_original``: the recomputed cadena original string - ``sello_sat_verified``: True/False if `pac_certificado_der_b64` was supplied, else null
| Name | Type | Req | Description |
|---|---|---|---|
| pac_certificado_der_b64 | – | – | Base64-encoded DER certificate of the PAC/SAT that stamped this TFD, used to cryptographically verify SelloSAT. SAT does not embed this certificate in the TFD itself, so it is not available without t… |
| xml | string | yes | The sealed, PAC-stamped CFDI XML (with a TimbreFiscalDigital complement) |
Structured output declared, but exposes no named fields.
No examples provided.
What is the io.github.cmendezs/mcp-cfdi-mx server?
io.github.cmendezs/mcp-cfdi-mx is listed in the public MCP registry as io.github.cmendezs/mcp-cfdi-mx. MCP server for Mexican electronic invoicing (CFDI 4.0, Pagos 2.0). This page covers its PyPI package (mcp-cfdi-mx).
Is the io.github.cmendezs/mcp-cfdi-mx server safe to use?
io.github.cmendezs/mcp-cfdi-mx scores 77 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the io.github.cmendezs/mcp-cfdi-mx server expose?
io.github.cmendezs/mcp-cfdi-mx exposes 6 tools: mx__get_supported_scope, mx__build_cfdi, mx__build_pago, mx__validate_cfdi, mx__seal_cfdi, mx__verify_tfd. Their descriptions and schemas cost roughly 2,059 tokens of context every time the server is loaded.
Is the io.github.cmendezs/mcp-cfdi-mx server still maintained?
io.github.cmendezs/mcp-cfdi-mx is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the io.github.cmendezs/mcp-cfdi-mx server under?
io.github.cmendezs/mcp-cfdi-mx declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.