mx-fiscal-mcp-server

An MCP server that gives an AI agent Mexican tax and banking capabilities — validate RFC, CURP, CLABE and NSS with real check digits, read a CFDI 4.0 invoice, ask the SAT whether it is still live, and look up the SAT's code tables. No API keys, no CSD certificate, no PAC contract.

Ask Claude "read this invoice and tell me whether it's still valid" and it parses the XML, labels every SAT code, checks both RFCs and the arithmetic, and queries the SAT's public status service — instead of you opening three web tools.

> Read this CFDI and check it at the SAT

  parse_cfdi(xml="<cfdi:Comprobante …>")

  CFDI A-1042 — 1160.00 MXN
  ✅ Stamped · version 4.0 · Ingreso
  Emisor:   TES150312DX2 ✅  601 — General de Ley Personas Morales
  Receptor: PELJ900521DK2 ✅  G03 — Gastos en general
  ✅ Totals add up: subtotal − discount + transferred − withheld = total

  cfdi_status(xml="<cfdi:Comprobante …>")

  CFDI status — Vigente
  ✅ The invoice exists in the SAT's records and has not been cancelled.
  Es cancelable: Cancelable con aceptación
  EFOS: returned 200 — the issuer is NOT on the SAT's definitive 69-B list.

Why this exists

Mexican electronic invoicing has two halves, and only one of them was served.

Building and stamping a CFDI needs a CSD certificate and a contract with a PAC. That half already has tooling — mcp-cfdi-mx (Python) does it, and this server deliberately does not compete with it.

Reading is the other half, and it needs nothing: the check-digit algorithms are public, the SAT's catalogues are public, and the invoice status service behind the QR code on every printed invoice is public and unauthenticated. Yet an agent asked to validate an RFC will happily invent a regex that rejects XAXX010101000 — the RFC of every invoice issued to the general public — because that one does not satisfy its own check digit. This server is the read half, done carefully.

The arithmetic comes from mx-identifiers (MIT, zero dependencies, 101 tests against public vectors); the CFDI reader is ported from the tool running at ortamarco.me; the SOAP envelope was read out of nodecfdi/sat-estado-cfdi rather than guessed. It is the third of three read-only, key-free MCP servers alongside domain-security-mcp-server and seo-geo-mcp-server.

Tools

Identifiers

CFDI

Catalogues

Every tool is read-only, declares an outputSchema and returns structuredContent (validated by the SDK) alongside human-readable Markdown (default) or JSON (response_format="json").

Honesty notes

These are surfaced in the tool output, not buried here:

• Structurally valid is not registered. A check digit that adds up says the string is well-formed and nothing more. Only the SAT can say an RFC is registered; only RENAPO that a CURP belongs to a person. This server never asks either, and its wording never implies it did.
• XAXX010101000 does not satisfy its own check digit. The SAT assigned the general-public RFC by decree and the modulus-11 algorithm asks for a 4 where the SAT wrote a 0. XEXX010101000 (foreign residents) does satisfy it. The tools report is_generic and check_digit_satisfied as separate fields rather than collapsing both into "valid".
• Reading a CFDI is not verifying it. parse_cfdi does not check the digital signature. A perfectly parseable invoice can be cancelled, or fabricated wholesale.
• An unreachable SAT is not an invalid invoice. The status endpoint publishes no SLA and no status page, and it goes down. Its documentation states capacity for up to 2 million queries per hour and asks callers not to raise their query volume, since every query reads the SAT's transactional databases. cfdi_status degrades to available: false with the reason — a statement about the SAT, never about the document.
• The bank list is a subset. bancos_clabe carries the main Banxico participants, not the full catalogue; an unknown code is reported as unknown rather than given an invented name. The plaza catalogue is not bundled at all, so the plaza code is returned verbatim.
• EFOS codes are read from the SAT's own table. The SAT documents ValidacionEFOS in its Documentación del Servicio de Consulta de CFDI v1.4, section 3: 100, 101 and 104 put the issuer on the definitive 69-B list; 102 and 103 mean the issuer is not on it but a third-party RFC the invoice was issued on behalf of (a cuenta de terceros) is; 200 and 201 mean the issuer is not on it (201: nor any third party). efos_state speaks of the issuer only, and efos_third_party_state (listed / not_listed / not_reported / unknown) of the third parties. An empty field or an undocumented code is reported as unknown with the raw code kept in validacion_efos, never as "listed". Versions up to 1.0.1 reported 102 and 103 as an issuer on the list; 1.0.2 fixes it.

Protocol

Built on the v2 MCP SDK, so it speaks the 2026-07-28 revision (server/discover, no initialize, per-request _meta envelope) and still serves 2025-era clients — Claude Desktop, Claude Code and Cursor — from the same server factory. The entry points own the era decision: serveStdio(factory) on stdio, createMcpHandler(factory) over HTTP with the default legacy: 'stateless'. There is no session state and no Mcp-Session-Id in either direction. npm run smoke exercises every tool on both eras and asserts the negotiated era of each connection.

Because the tool list is a compile-time constant, tools/list and server/discover advertise a real one-hour ttlMs with cacheScope: 'public' on 2026-era connections instead of the SDK's conservative ttlMs: 0.

Install

Requires Node.js 20+. Nothing to clone — every MCP client can run it with npx.

Use it with Claude Code

claude mcp add mx-fiscal -- npx -y mx-fiscal-mcp-server

Use it with Claude Desktop or Cursor

Add to claude_desktop_config.json (or ~/.cursor/mcp.json) — see examples/:

{
  "mcpServers": {
    "mx-fiscal": {
      "command": "npx",
      "args": ["-y", "mx-fiscal-mcp-server"]
    }
  }
}

On Windows use "command": "cmd" with "args": ["/c", "npx", "-y", "mx-fiscal-mcp-server"]. Restart the client, then ask: "Generate 10 Mexican customers with valid RFC and CURP for my seed file."

Self-host (HTTP transport)

The same server speaks stateless Streamable HTTP for remote or multi-client use.

TRANSPORT=http npx -y mx-fiscal-mcp-server
# POST JSON-RPC to http://127.0.0.1:3000/mcp   ·   health at /healthz

It is safe by default: it binds to 127.0.0.1 and only accepts localhost Host and Origin headers, which blocks DNS-rebinding attacks from a web page. To expose it — for example behind Coolify or Traefik — opt in explicitly: