servers / dominican-republic-invoices-dgii-e-cf-facturacion-electronica
Dominican Republic Invoices (DGII e-CF facturacion electronica) MCP server
communitystreamable_httpremoteverifiedhealthy
Dominican Republic DGII e-CF: AI agents authenticate and submit electronic invoices, stateless BYO.
01Tools · 4
How to read this: tool names here are observed from a live tools/list handshake. The Risk label is a heuristic inferred from the tool name (write/destructive verbs), not from executing the tool — a conservative guess, not a verified capability. We never escalate risk from a description. Found one that's wrong? Tell us — we fix on report.
| Tool | Risk | Side effects | Approval |
|---|---|---|---|
| get_seed Step 1 of DGII authentication: fetch a fresh "semilla" (seed) XML from the DGII Autenticacion service — GET /Autenticacion/api/Autenticacion/Semilla. No credentials, no fiscal effect. Returns { seed_xml, valor, fecha }: a short-lived XML document you must SIGN with your DGII-recognized digital certificate (Digifirma or another approved CA), then pass to get_token. This server only fetches the seed — the signing happens on YOUR side. Environment header (set once in your MCP client, per-request): x-dgii-env: test (default = TesteCF certificacion, open, NO fiscal effect) | prod (eCF produccion, real fiscal effect). There is NO static API key — DGII authentication is certificate-based: you sign the semilla and each e-CF with your own DGII-recognized digital certificate (Digifirma or another approved CA). This server never signs and never stores a token or certificate. Optional owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools. | read | false | unknown |
| get_token Step 2 of DGII authentication: exchange your SIGNED semilla for a session token — POST /Autenticacion/api/Autenticacion/ValidarSemilla (multipart field "xml"). You take the seed from get_seed, sign it with your DGII-recognized digital certificate merchant-side, and pass it here as base64 (signed_seed_xml). Returns { token, expira, expedido } — a Bearer token valid ~1 hour; use it for submit_invoice and query_status. If the seed is not correctly signed DGII returns HTTP 400 (e.g. "Archivo no valido." when the file is missing/not XML). This server forwards the signed bytes untouched and never stores the token. Environment header (set once in your MCP client, per-request): x-dgii-env: test (default = TesteCF certificacion, open, NO fiscal effect) | prod (eCF produccion, real fiscal effect). There is NO static API key — DGII authentication is certificate-based: you sign the semilla and each e-CF with your own DGII-recognized digital certificate (Digifirma or another approved CA). This server never signs and never stores a token or certificate. Optional owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools. | read | false | unknown |
| submit_invoice Step 3: submit an ALREADY-SIGNED e-CF (comprobante fiscal electronico) to DGII for validation — POST /Recepcion/api/FacturasElectronicas (multipart field "xml", Bearer token). Your billing software BUILDS the e-CF XML (e-NCF, RNC emisor/comprador, Totales, ITBIS) and SIGNS it with your DGII-recognized certificate; this server does NOT generate or sign the XML — it forwards the signed bytes with your token. DGII replies { trackId, mensaje, error }: a trackId is your acuse de recibo (receipt) — the document was RECEIVED for asynchronous validation, NOT yet accepted. Poll query_status with the trackId until estado is "Aceptado" (fiscally valid) / "Aceptado Condicional" / "Rechazado" (rejected — read mensajes, fix, resubmit with a new e-NCF). An "error" with no trackId means DGII rejected the submission outright. Environment header (set once in your MCP client, per-request): x-dgii-env: test (default = TesteCF certificacion, open, NO fiscal effect) | prod (eCF produccion, real fiscal effect). There is NO static API key — DGII authentication is certificate-based: you sign the semilla and each e-CF with your own DGII-recognized digital certificate (Digifirma or another approved CA). This server never signs and never stores a token or certificate. Optional owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools. | read | false | unknown |
| query_status Step 4: query the validation status of a submitted e-CF by its trackId — GET /ConsultaResultado/api/Consultas/Estado?TrackId={id} (Bearer token). Returns { trackId, estado, codigo, rnc, encf, secuenciaUtilizada, fechaRecepcion, mensajes[] }. estado enum: "En Proceso" (still validating — poll again) / "Aceptado" (ACCEPTED, fiscally valid) / "Aceptado Condicional" (accepted with observations in mensajes) / "Rechazado" (REJECTED — read mensajes for the reason, fix and resubmit with a new e-NCF). Poll this after submit_invoice until estado is no longer "En Proceso". Environment header (set once in your MCP client, per-request): x-dgii-env: test (default = TesteCF certificacion, open, NO fiscal effect) | prod (eCF produccion, real fiscal effect). There is NO static API key — DGII authentication is certificate-based: you sign the semilla and each e-CF with your own DGII-recognized digital certificate (Digifirma or another approved CA). This server never signs and never stores a token or certificate. Optional owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools. | read | false | unknown |
02Install & source
https://inv-do.wishpool.app/mcp
remote_url- repohttps://github.com/junter1989k-ai/dominican-republic-invoice-mcp
- homepagehttps://inv-do.wishpool.app/mcp
- licenseMIT
- adoption0 stars · 0 forks
05Provenance & freshness
sourcesOfficial MCP Registry [p1]
last_checked2026-07-10 15:20Z
next_check2026-07-11 20:08Z
cadenceevery 29h
verifiedtools_list:passed handshake:passed metadata:passed
index_statusindex — 8 unique facts >= 5
06Badge
Add the “as seen on MCPExplorer” badge to your README.
[](https://mcpexplorer.com/servers/dominican-republic-invoices-dgii-e-cf-facturacion-electronica)
Next step
This is one server. A loadout combines the right servers, governance, and proven plays for a whole job — assembled deliberately, not tool-dumped.
Explore loadouts →