MCP vs API REST para e-CF en República Dominicana: cuándo usar cada uno

Contenido de este artículo

1. El punto de partida: dos contratos distintos
2. Qué resuelve la API REST y qué no
3. Qué resuelve MCP y qué no
4. Cinco escenarios: tabla de decisión
5. Diferencias técnicas relevantes para el integrador
6. ¿Se pueden usar en paralelo?
7. Preguntas frecuentes

Cuando un equipo de desarrollo evalúa cómo integrar la emisión de comprobantes fiscales electrónicos en República Dominicana, la primera decisión no es técnica: es arquitectónica. La DGII, a través del sistema e-CF, exige validación, transmisión y confirmación de estado para cada documento. Tanto la API REST como el servidor MCP producen los mismos documentos con las mismas garantías frente a la DGII. La diferencia está en quién navega ese flujo: código determinista o un agente que razona en lenguaje natural.

Este artículo compara ambos métodos con criterios medibles: curva de aprendizaje, manejo de estados, diagnóstico de errores y escenarios de uso. Para entender primero qué es MCP como protocolo, ver ¿Qué es un servidor MCP de infraestructura fiscal?.

El punto de partida: dos contratos distintos

La API REST opera sobre HTTPS con autenticación Bearer. El developer construye el payload, lo envía al endpoint correcto, maneja la respuesta y monitorea el estado del documento hasta obtener el resultado legal final. El contrato es preciso y predecible para código determinista.

El servidor MCP opera sobre JSON-RPC 2.0 (especificación MCP). Expone herramientas con nombre, descripción y esquema de entrada tipado que un agente de IA puede descubrir y usar de forma autónoma. El agente describe la operación en lenguaje natural y el servidor gestiona la construcción del payload, la emisión y el seguimiento de estado.

Qué resuelve la API REST y qué no

La API REST resuelve el problema de rendimiento y control fino. Un backend que emite miles de documentos diarios con payloads construidos de forma determinista es exactamente el caso de uso para el que está diseñada. El developer controla cada campo, cada reintento, cada estado del ciclo de vida.

Lo que la API REST no resuelve es la curva de aprendizaje de un developer que se integra por primera vez. Requiere leer la documentación completa para entender qué campos son obligatorios por tipo de e-CF, cómo se estructuran los payloads, qué significa cada código de estado de la DGII y cómo diferenciar el flujo síncrono del asíncrono. Tampoco resuelve el caso donde un modelo de lenguaje está en el medio del flujo.

Qué resuelve MCP y qué no

El servidor MCP resuelve la barrera de descubrimiento y la construcción de payloads para agentes. El agente puede preguntar qué tipos de e-CF existen, qué campos requiere cada uno y cómo interpretar un error de rechazo de la DGII, sin que el developer haya instruido esas respuestas en el prompt. La capa de orquestación encadena validación, emisión y seguimiento en una sola llamada.

Lo que MCP no resuelve es el rendimiento en cargas masivas. Cada invocación de herramienta tiene la latencia adicional del protocolo JSON-RPC. Para un backend que emite documentos en batch, la API REST directa es más eficiente.

Cinco escenarios: tabla de decisión

La recomendación en cada escenario se basa en el tipo de consumidor del contrato: código determinista o agente con LLM.

Backend de alto volumen (batch)

Recomendación: API REST. El equipo controla cada payload, no hay LLM en el flujo, el throughput es crítico. MCP agrega latencia sin aportar valor en este caso.

Copiloto de ERP con interfaz de chat

Recomendación: MCP. El usuario instruye en lenguaje natural. El agente necesita descubrir el tipo de e-CF correcto, construir el payload y manejar el estado. El servidor MCP resuelve los tres pasos sin código adicional de integración.

Onboarding automático de nuevos emisores

Recomendación: MCP. El flujo es conversacional y no determinista. El agente guía al emisor paso a paso usando las herramientas de descubrimiento del catálogo.

Integración desde sistema legacy sin soporte MCP

Recomendación: API REST. Si el lenguaje o el entorno no tiene SDK de MCP disponible, la API REST es la única ruta viable. El SDK oficial de MCP está disponible en TypeScript y Python.

Pipeline híbrido (batch + copiloto)

Recomendación: ambos en paralelo. La API REST maneja el volumen; el servidor MCP maneja la interfaz conversacional. Los dos se autentican con el mismo token Bearer y producen los mismos resultados ante la DGII.

Diferencias técnicas relevantes para el integrador

Construcción de payload

Con la API REST, el developer construye el payload manualmente siguiendo la especificación de cada endpoint. Con MCP, el agente genera el payload desde lenguaje natural usando los ejemplos y el esquema tipado que el servidor expone.

Manejo de estados del ciclo de vida

Con la API REST, el developer implementa el polling: consulta el estado del documento periódicamente usando la referencia de seguimiento hasta que la DGII devuelve el resultado final. Con MCP, el orquestador maneja ese polling automáticamente cuando se activa la opción de espera.

Diagnóstico de errores

Con la API REST, un rechazo devuelve un código que el developer interpreta consultando la documentación normativa. Con MCP, la herramienta de diagnóstico traduce ese código en causa probable y acción correctiva. Para más detalle sobre los códigos de rechazo de la DGII, ver Errores de rechazo DGII: cómo diagnosticarlos y corregirlos.

¿Se pueden usar en paralelo?

Sí, y en arquitecturas híbridas es el patrón más común. El servidor MCP y la API REST comparten el mismo token de autenticación Bearer y producen resultados idénticos ante la DGII. No hay conflicto entre usarlos simultáneamente desde el mismo sistema.

Para implementaciones que requieren ambos flujos en República Dominicana, la infraestructura de facturación electrónica de Alanube expone ambos contratos — REST y MCP — bajo la misma cuenta y el mismo token.

Preguntas frecuentes

¿Cuál es la diferencia principal entre integrar vía API REST y vía MCP para emisión de e-CF?

La diferencia principal es el consumidor del contrato. La API REST está diseñada para código determinista. El MCP está diseñado para agentes que descubren herramientas en tiempo de ejecución y construyen payloads desde lenguaje natural. Ambos producen los mismos e-CF con las mismas garantías ante la DGII.

¿Cómo puedo evaluar cuál ruta es mejor para mi integración?

La pregunta clave es: ¿hay un modelo de lenguaje en el flujo de emisión? Si el trigger es siempre código determinista, la API REST es la ruta más directa. Si el trigger incluye instrucción en lenguaje natural o un agente que razona sobre el contexto, MCP aporta valor real.

¿Qué diferencia hay entre el manejo de errores DGII en REST y en MCP?

En REST, un rechazo devuelve un código que el developer interpreta manualmente. En MCP, la herramienta de diagnóstico devuelve la causa probable y la acción correctiva, lo que permite al agente corregir el payload y reintentar sin intervención del developer.

¿Es posible migrar de API REST a MCP sin reescribir la lógica de negocio?

El MCP no reemplaza la lógica de negocio del sistema; la complementa en la capa de integración fiscal. Un sistema que ya usa la API REST puede añadir el servidor MCP para habilitar un copiloto o agente conversacional sin tocar el proceso de emisión existente. Ambos coexisten bajo el mismo token de autenticació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. Ha liderado implementaciones de facturación electrónica en Colombia, México y Centroamérica para ISVs de mediana y gran escala.