einvoice-validators-mcp

MCP server that lets AI agents validate legally mandated e-invoices before submission — Malaysia MyInvois (LHDN), Dominican Republic e-CF (DGII), Nigeria NRS/FIRS, Bolivia SIAT, Costa Rica Hacienda v4.4.

Each tool runs a keyless, stateless pre-flight against the official rules of the country: XSD structure, business rules, code lists, totals math, control codes (Bolivia's CUF rebuilt digit by digit, Costa Rica's 50-digit clave decomposed) and digital signatures (XAdES / XAdES-EPES / XML-DSig verified against the embedded certificate). Documents are validated in-memory and discarded — nothing is filed with any tax authority.

Tools

Tool	Country / regime
validate_malaysia_myinvois	🇲🇾 MyInvois (LHDN/IRBM) — UBL 2.1 XML & JSON
validate_dominican_republic_ecf	🇩🇴 e-CF (DGII, Ley 32-23) — signed XML
validate_nigeria_firs	🇳🇬 NRS/FIRS FIRSMBS — UBL 2.1 XML & JSON
validate_bolivia_siat	🇧🇴 SFV/SIAT (SIN) — signed XML + CUF
validate_costa_rica_v44	🇨🇷 Comprobantes v4.4 (Hacienda) — signed XML, 8 document types

Every response is a JSON report: valid, wellFormed, signatureValid, errorCount, warningCount and rule-coded findings the agent can reason about.

Setup

1. Get a RapidAPI key (free): subscribe to the API(s) you need — every one has a free plan:
   • Malaysia MyInvois
   • Dominican Republic e-CF
   • Nigeria NRS/FIRS
   • Bolivia SIAT
   • Costa Rica v4.4
2. Add the server to your MCP client.

Claude Desktop / Claude Code

{
  "mcpServers": {
    "einvoice-validators": {
      "command": "npx",
      "args": ["-y", "einvoice-validators-mcp"],
      "env": { "RAPIDAPI_KEY": "your-rapidapi-key" }
    }
  }
}

Any MCP client (stdio)

RAPIDAPI_KEY=your-rapidapi-key npx -y einvoice-validators-mcp

Usage notes for agents

• Pass the invoice as-is in the invoice argument. Signed documents are byte-sensitive: do not pretty-print, re-encode or "fix" them before validating.
• A non-compliant invoice is a normal result ("valid": false with findings), not an error.
• valid: true is an informative pre-flight ("structurally ready to submit"), not an acceptance by the authority — trust chains, live registries and clearance remain with the tax authority's online services.

Why not just generate validation code?

The commodity layer (XSD) you can generate. What you cannot reliably generate: the gated or prose-only rule sets, the exact signature canonicalization proven against genuinely signed documents, and the maintenance when regulators change the rules (Costa Rica's TRIBU-CR migration, LHDN SDK updates). These APIs are maintained validators with real-world proof — the technical write-ups show real outputs, including tamper detection on genuinely signed documents.

Links

• Overview & landing: samirchatwiti.github.io/e-invoice-validators
• Also available on Zyla API Hub
• Author: Samir Chatwiti — GovTech/LegalTech solution architect

License

MIT (this MCP client). The validation services themselves are commercial APIs.