Loading ToolBench
MCP server for Mexican electronic invoicing (CFDI 4.0, Complemento de Pagos 2.0), PAC-agnostic sealing
Server defines 6 tools with reasonable descriptions (avg ~250 chars, within baseline 194 median). Tool names follow verb_noun pattern (mx__get_*, mx__build_*, mx__validate_*, mx__seal_*, mx__verify_*). However, input schemas are largely absent or minimal, most tools show only high-level object descriptions without property-level type definitions. mx__build_cfdi and mx__build_pago accept 'comprobante_data' and 'pagos_data' as untyped objects; mx__validate_cfdi and mx__verify_tfd have no visible input schema. Output schemas are not documented. Error handling guidance is missing. Security considerations (e.g., private key handling in mx__seal_cfdi) are not addressed in tool descriptions.
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)
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)
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 schemas missing or incomplete for 4 of 6 tools. mx__validate_cfdi, mx__seal_cfdi, mx__verify_tfd show no visible input schema in source. mx__build_cfdi and mx__build_pago accept 'comprobante_data' and 'pagos_data' as bare objects without property-level type definitions, making it impossible for LLMs to construct valid payloads.
Output schemas not documented. No tool description specifies what fields are returned or their types. LLMs cannot plan downstream calls or extract required data (e.g., does mx__build_cfdi return xml + total, or additional metadata?).
Descriptions for mx__validate_cfdi, mx__seal_cfdi, mx__verify_tfd are minimal (1-2 sentences, ~50 chars). Lack context on when to use, what they return, error conditions, or prerequisites. Below baseline 194 chars and insufficient for LLM tool selection.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Seal a CFDI 4.0 XML document with a digital signature (Sello).
Validate a CFDI 4.0 XML document against SAT's XSD schema (Anexo 20).
Verify a PAC-returned Timbre Fiscal Digital 1.1 stamp.
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., mx__seal_cfdi requires a private key, what happens if it is missing or invalid?
Security concerns not addressed. mx__seal_cfdi accepts a private key (inferred from 'sealing' context) but no description warns against passing secrets as parameters or documents how credentials are injected. Potential for key leakage into logs.