Las 30 herramientas del MCP de infraestructura fiscal de República Dominicana: referencia completa
Referencia consolidada en español de las 30 herramientas del único servidor MCP de infraestructura fiscal conectado a la DGII en República Dominicana: organización por capas, casos de uso y cuándo usar el orquestador vs. emisión directa.
Contenido de este artículo
1. Por qué importa tener una referencia consolidada
2. Arquitectura en tres capas
3. Capa 1: Descubrimiento y aprendizaje (5 herramientas)
4. Capa 2: Emisión, seguimiento y archivos (23 herramientas)
5. Capa 3: Confiabilidad (2 herramientas)
6. Cuándo usar el orquestador vs. emisión directa
7. Preguntas frecuentes
La documentación oficial del servidor MCP conectado a la DGII está en inglés y organizada herramienta por herramienta. Para un equipo que evalúa si el servidor cubre sus casos de uso, eso obliga a leer más de 30 páginas separadas. Este artículo consolida las 30 herramientas en una sola referencia en español.
Para una introducción al protocolo MCP antes de entrar en el detalle de herramientas, ver ¿Qué es un servidor MCP de infraestructura fiscal?. Para la guía de integración paso a paso, ver Cómo conectar un agente de IA a la DGII.
Arquitectura en tres capas
Las 30 herramientas están organizadas en tres capas con funciones distintas y complementarias. Capa 1 — Descubrimiento y aprendizaje: el agente explora el catálogo sin leer documentación externa. Capa 2 — Emisión, seguimiento y archivos: el núcleo operativo. Capa 3 — Confiabilidad: el agente falla de forma controlada, corrige y reintenta.
Capa 1: Descubrimiento y aprendizaje (5 herramientas)
Estas herramientas permiten al agente explorar el catálogo sin consultar documentación externa. Son especialmente útiles en las primeras sesiones de integración.
discover_rd_endpoint
Traduce una descripción en lenguaje natural al endpoint correcto. Útil cuando el agente recibe una instrucción como “emitir una factura de exportación” y necesita identificar que el tipo correcto es el e-CF 46.
explain_rd_field
Explica un campo específico de la API en lenguaje natural: qué es, si es obligatorio, qué valores acepta y cuál es el valor por defecto cuando aplica.
generate_rd_request_example
Genera un payload de ejemplo completo y funcional para cualquier tipo de e-CF con todos los campos obligatorios y valores de prueba válidos.
guide_rd_document_onboarding
Entrega un plan de integración paso a paso específico para un tipo de e-CF. Útil para copilotos de ERP que onboardean a nuevos emisores sin intervención técnica.
list_rd_document_types
Lista los 10 tipos de e-CF del catálogo oficial de la DGII con código, nombre y flujo. Es la herramienta más simple para confirmar que el servidor MCP está conectado correctamente después de la configuración inicial. Ver también Los 10 tipos de e-CF en República Dominicana.
Capa 2: Emisión, seguimiento y archivos (23 herramientas)
El núcleo operativo del servidor. Contiene el orquestador principal, 10 pares de herramientas de emisión y consulta de estado por tipo de documento, una herramienta de descarga y una de creación de empresa en sandbox.
El orquestador: issue_and_track_rd_document
La herramienta central. Acepta cualquier tipo de e-CF (documentTypeCode del 31 al 47), valida el payload si se activa validateFirst, emite el documento, espera el resultado legal si se activa waitForFinalStatus y descarga los archivos firmados si se activa downloadAssets. Encadena los cuatro pasos en una sola llamada, gestionando automáticamente los flujos síncrono y asíncrono.
Pares de emisión y consulta por tipo de e-CF (20 herramientas)
Para cada tipo de e-CF existe un par dedicado de herramientas: una para emisión y otra para consulta de estado. Estos pares son la alternativa al orquestador cuando el equipo prefiere controlar cada paso de forma independiente.
Factura de Crédito Fiscal (31): issue_rd_fiscal_credit_invoice / get_rd_fiscal_credit_invoice_status
Factura de Consumo (32): issue_rd_consumer_invoice / get_rd_consumer_invoice_status
Nota de Débito (33): issue_rd_debit_note / get_rd_debit_note_status
Nota de Crédito (34): issue_rd_credit_note / get_rd_credit_note_status
Factura de Compras (41): issue_rd_purchase_invoice / get_rd_purchase_invoice_status
Gastos Menores (43): issue_rd_minor_expense / get_rd_minor_expense_status
Regímenes Especiales (44): issue_rd_special_regime / get_rd_special_regime_status
Gubernamental (45): issue_rd_government_invoice / get_rd_government_invoice_status
Exportaciones (46): issue_rd_export_document / get_rd_export_document_status
Pagos al Exterior (47): issue_rd_foreign_payment / get_rd_foreign_payment_status
Los pares de emisión directa no incluyen polling automático ni descarga de archivos. Si se usan en lugar del orquestador, el equipo debe implementar seguimiento y descarga de forma independiente.
download_rd_document_asset
Descarga el XML firmado, el PDF o el resumeXml de un documento ya aceptado por la DGII usando el documentId del trackingReference.
create_rd_sandbox_company
Crea una empresa emisora de prueba en sandbox directamente desde el agente, sin acceder al dashboard del proveedor. Solo disponible en ambiente sandbox.
Capa 3: Confiabilidad (2 herramientas)
validate_rd_request_payload
Valida el payload contra el esquema del tipo de e-CF antes de enviarlo a la DGII. Detecta campos faltantes, tipos incorrectos y valores fuera de rango. Devuelve la ruta exacta del campo con el problema.
diagnose_rd_api_error
Recibe el governmentResponseCode de un rechazo de la DGII y devuelve la causa probable más la acción correctiva. Para el mapa completo de códigos de rechazo, ver Errores de rechazo DGII en e-CF.
Cuándo usar el orquestador vs. emisión directa
Para la mayoría de integraciones, el orquestador issue_and_track_rd_document es el punto de entrada correcto. Cubre el 95% de los casos de uso con una sola llamada. Los pares de emisión directa tienen sentido cuando el equipo ya tiene su propia máquina de estados, cuando requiere control granular sobre reintentos, o cuando la latencia del orquestador es un factor crítico.
La referencia técnica completa de parámetros y esquemas de respuesta para cada herramienta está en la documentación oficial del servidor MCP.
Preguntas frecuentes
¿El servidor MCP tiene herramientas para consultar el historial de documentos emitidos?
El servidor MCP está optimizado para emisión y seguimiento en tiempo real, no para consultas de historial. Las consultas de historial se realizan directamente a través de la API REST del proveedor.
¿Puedo usar las herramientas de emisión directa y el orquestador en el mismo sistema?
Sí, no hay conflicto. Un sistema puede usar el orquestador para el flujo conversacional y los pares de emisión directa para procesos programados. Ambos usan el mismo token y producen los mismos resultados ante la DGII.
¿Las herramientas de descubrimiento consumen cuota de emisión?
No. Las herramientas de descubrimiento son llamadas al servidor MCP, no al ente fiscal. Solo las herramientas de emisión de la capa 2 generan documentos fiscales reales en producción.
Sobre el autor
Ing. Carlos Méndez es arquitecto de software con más de 10 años integrando sistemas fiscales en América Latina.
Artículos Relacionados
Los 10 tipos de comprobantes fiscales electrónicos (e-CF) en República Dominicana: cuándo usar cada uno
Referencia práctica de los 10 tipos de comprobantes fiscales electrónicos en República Dominicana: código, caso de uso, flujo de emisión (síncrono o asíncrono) e implicaciones técnicas para developers e integradores.
Cuánto tiempo toma integrar la API de facturación electrónica de la DGII: benchmark por método
Desglose honesto del tiempo de integración de la API de facturación electrónica de la DGII por etapa: lectura de documentación, construcción de payloads, manejo de estados y diagnóstico de rechazos. Comparativa REST vs MCP con estimaciones transparentes.
Errores de rechazo de la DGII en e-CF: cómo diagnosticarlos y corregirlos desde un agente de IA
Los rechazos de la DGII en e-CF tienen causas precisas y acciones correctivas definidas. Esta guía explica el ciclo de vida del documento, los códigos de error más frecuentes y cómo un agente de IA puede diagnosticar y corregir rechazos de forma autónoma.