Durante años, conectar una herramienta de inteligencia artificial a un ERP significaba escribir integraciones personalizadas, mantener APIs privadas y asumir que cualquier actualización del software rompería el conector. En 2024 Anthropic publicó el Model Context Protocol (MCP), un estándar abierto que cambia esa ecuación: en lugar de integraciones punto a punto, el agente IA se conecta al ERP a través de un servidor MCP que expone herramientas tipadas, y el agente decide cuándo y cómo usarlas según el contexto de la conversación. En 2025 Microsoft, Google, OpenAI y los principales fabricantes de ERP comenzaron a publicar sus propios servidores MCP o a anunciar su hoja de ruta. En 2026, conectar Odoo, Sage o Dynamics a un agente IA mediante MCP ya no es un experimento de laboratorio: es un proyecto factible para una pyme con recursos técnicos normales.
Este artículo explica qué es el protocolo MCP, por qué simplifica la integración con ERPs, cómo se despliega en los tres sistemas más habituales en la pyme española y qué casos de uso tienen retorno real desde el primer trimestre.
Qué es MCP y por qué importa para la integración de ERP con IA
El Model Context Protocol es un protocolo cliente-servidor de código abierto que estandariza la forma en que un modelo de lenguaje grande (LLM) accede a herramientas externas, ficheros y datos estructurados. Antes de MCP, cada proveedor de IA definía su propio esquema de «tool calling»; el desarrollador tenía que adaptar el conector a cada modelo. Con MCP, el servidor declara sus herramientas en un formato JSON estándar, y cualquier cliente compatible (Claude, GPT-4o, Gemini, modelos open-source con soporte MCP) puede utilizarlas sin cambios.
Aplicado a un ERP, el servidor MCP actúa como una capa de acceso tipada: expone operaciones como get_pedido, listar_facturas_pendientes, actualizar_estado_albaran o crear_oferta_cliente. El agente IA llama a esas operaciones de forma segura, con los permisos que defina el administrador del sistema. El ERP no «sabe» que hay una IA al otro lado; simplemente recibe peticiones a su API REST o RPC como si fuesen de cualquier otra integración.
Diferencias clave respecto a una integración tradicional
| Aspecto | Integración tradicional (webhook / ETL) | Agente IA con servidor MCP |
|---|---|---|
| Lógica de orquestación | Codificada en el conector (rígida) | El agente la razona en cada llamada (flexible) |
| Mantenimiento | Reabre código ante cada cambio de modelo de datos | Solo actualiza el servidor MCP si cambia la API del ERP |
| Interfaz de usuario | Formularios y botones específicos | Lenguaje natural o voz |
| Combinación de fuentes | Cada fuente requiere un conector adicional | El agente combina MCP de ERP + MCP de CRM + RAG documental en una respuesta |
| Perfil técnico requerido | Desarrollador de integraciones | Desarrollador con conocimiento de la API del ERP |
Cómo funciona el servidor MCP para ERP: arquitectura básica
La arquitectura tiene tres piezas: el cliente MCP (el agente IA o la aplicación que lo hospeda), el servidor MCP (un proceso que traduce las peticiones del agente a llamadas al ERP) y el propio ERP con su API nativa.
El servidor MCP puede correr en la misma red que el ERP (on-premise o nube privada) o exponerse como un microservicio en la nube con autenticación OAuth 2.0. La comunicación entre cliente y servidor MCP se hace mediante JSON-RPC sobre HTTP/SSE (Server-Sent Events para streaming) o sobre stdio cuando el proceso corre localmente. En producción, lo habitual es un endpoint HTTPS con token Bearer para cada tenant.
Flujo de una consulta típica
- El usuario escribe: «¿Cuánto debemos al proveedor García Logística a cierre de mes?»
- El agente identifica que necesita datos del módulo de cuentas a pagar del ERP.
- Llama a la herramienta
get_saldo_proveedordel servidor MCP con el parámetronombre="García Logística". - El servidor MCP traduce eso a una llamada a la API del ERP (por ejemplo,
GET /api/account.move?partner=García+Logística&state=posteden Odoo). - El servidor MCP devuelve el resultado estructurado al agente.
- El agente redacta la respuesta en lenguaje natural, añade el desglose por vencimiento y, si tiene permiso, ofrece lanzar el pago.
El tiempo de respuesta extremo a extremo —incluyendo la llamada al LLM— suele estar entre 3 y 8 segundos para consultas simples, y entre 10 y 20 segundos para consultas que encadenan varias herramientas. Si tu caso requiere respuesta inmediata (por ejemplo, en un canal de voz), la arquitectura se complementa con caché de datos precalculados.
Implementación con Odoo (versiones 16 y 17)
Odoo es el ERP de código abierto más implantado en la pyme española. Desde la versión 16, expone una API JSON-RPC estable y una API REST opcional que permite autenticación mediante clave de API por usuario. En 2025 la comunidad publicó varios servidores MCP para Odoo; en 2026 la empresa Odoo S.A. publicó su propio servidor MCP oficial en la versión 17.1.
Pasos para conectar Odoo a un agente IA
- Generar una clave de API para el usuario técnico del agente (menú Configuración → Usuarios → Clave de API). Aplicar permisos mínimos: solo los modelos que el agente necesita leer o escribir.
- Desplegar el servidor MCP de Odoo: instalar el paquete
odoo-mcp-server(disponible en PyPI o como módulo comunitario) en un servidor accesible por el agente. Configurar la URL de Odoo, la base de datos y la clave de API en variables de entorno. - Declarar las herramientas necesarias en el fichero de configuración del servidor: por ejemplo, activar
sale.order,account.move,stock.pickingy desactivar el resto para reducir la superficie de ataque. - Conectar el agente al servidor MCP: en la configuración del cliente MCP (Claude Desktop, un bot de Teams, un workflow de n8n con nodo MCP) añadir la URL del servidor y el token Bearer.
- Probar con consultas de solo lectura antes de activar herramientas de escritura.
Con Odoo 17, la integración MCP está suficientemente madura para producción en los módulos de ventas, compras, facturación y almacén. El módulo de fabricación (MRP) requiere mapeo adicional porque su modelo de datos es más complejo.
Implementación con Sage (Sage 50, Sage 200 y Sage X3)
El ecosistema Sage tiene tres niveles con diferente nivel de apertura de API. Sage 50 ofrece integración mediante ODBC o mediante la API en la nube (Sage Business Cloud API), con autenticación OAuth 2.0. Sage 200 dispone de API REST desde la versión 2021 R2, más completa y adecuada para el servidor MCP. Sage X3 tiene una API SOAP y una API REST (módulo Web Services) que es la base recomendada para MCP en implantaciones enterprise.
En la práctica, el patrón más habitual en pymes españolas con Sage 200 es desplegar el servidor MCP en el mismo servidor Windows donde corre Sage (como servicio Windows o como contenedor Docker sobre Windows Server 2022), y que el agente lo consuma desde la red corporativa. Para acceso remoto seguro, se tunnela mediante un proxy HTTPS inverso con certificado TLS.
Un punto crítico con Sage: la API REST de Sage 200 no expone todos los campos de forma nativa. En algunos módulos (contabilidad analítica, gestión de proyectos) el servidor MCP debe llamar a procedimientos almacenados de SQL Server directamente, con los riesgos de mantenimiento que eso implica. Conviene delimitar el alcance antes de empezar.
Implementación con Microsoft Dynamics 365 Business Central
Business Central es el ERP de Microsoft más extendido en pymes medianas españolas de entre 20 y 200 empleados. Tiene una API OData v4 completa, documentada en Microsoft Learn, con soporte nativo de OAuth 2.0 mediante Microsoft Entra ID. En marzo de 2025, Microsoft publicó el repositorio oficial ms-business-central-mcp en GitHub, con herramientas predefinidas para ventas, finanzas, inventario y proyectos.
La ventaja de Business Central para esta arquitectura es que el servidor MCP puede correr como Azure Function (sin servidor que mantener) y hereda la identidad del tenant de Microsoft 365. Si ya tienes Copilot for Microsoft 365 activo, el agente MCP puede coexistir en el mismo entorno de Teams sin licencia adicional de infraestructura.
El acceso de escritura en Business Central requiere permisos de perfil específicos. Antes de activar herramientas de escritura (crear pedidos, aprobar facturas), es imprescindible revisar los flujos de aprobación existentes en Business Central para que el agente no los salte involuntariamente. La configuración recomendada es que el agente proponga la acción y el usuario la confirme en un segundo paso, en lugar de ejecutar directamente.
Si quieres profundizar en la integración de agentes IA con tu ERP, nuestro equipo analiza primero el estado de la API de tu versión concreta antes de comprometer un alcance.
Casos de uso con retorno real en la pyme
No todos los casos de uso de agente IA + ERP tienen el mismo retorno. Estos son los que muestran resultados más rápidos en implantaciones reales durante 2025 y 2026:
Consulta de estado de pedidos y facturas por lenguaje natural
El equipo de atención al cliente o comercial puede preguntar directamente: «¿Qué pedidos de Ferretería López llevan más de 5 días sin servir?» y obtener la respuesta sin entrar al ERP. Reduce entre 4 y 8 minutos por consulta en equipos con alta frecuencia de llamadas de seguimiento.
Asistente de compras y reposición
El agente consulta el stock mínimo configurado, el stock actual y el plazo de entrega del proveedor, y genera el borrador de pedido de compra. El responsable de compras revisa y aprueba. Este flujo es especialmente útil en empresas con más de 500 referencias activas donde la gestión manual de puntos de reorden consume horas semanales.
Análisis de rentabilidad de clientes o proyectos
Combinando el módulo de facturación y el de costes del ERP, el agente puede responder: «¿Cuál es el margen bruto real del proyecto 2025-047 tras imputar las horas de los tres últimos meses?» en segundos, sin que el controller tenga que extraer datos a Excel.
Automatización de tareas administrativas repetitivas
Aprobar albaranes de entrega contrastados con el pedido original, generar facturas recurrentes, actualizar tarifas de clientes por segmento: son tareas donde el agente puede ejecutar en masa con supervisión humana puntual, en lugar de proceso íntegramente manual.
Seguridad y control de acceso: lo que no puede faltar
El servidor MCP introduce un nuevo punto de acceso al ERP. Antes de ir a producción, revisar al menos estos cuatro puntos:
- Principio de mínimo privilegio: el usuario técnico del agente en el ERP solo tiene permiso sobre los módulos y campos que necesita. No usar el usuario administrador.
- Auditoría de llamadas: el servidor MCP debe registrar cada herramienta invocada, quién la invocó (usuario o sesión del agente) y qué parámetros se pasaron. Muchos servidores MCP de código abierto no lo implementan por defecto; hay que añadirlo.
- Autenticación del cliente MCP: el servidor no debe ser accesible sin token. En producción, usar tokens de corta duración (TTL máximo de 24 horas) con rotación automática.
- Revisión de herramientas de escritura: antes de activar cualquier herramienta que modifique datos en el ERP, diseñar el flujo de confirmación humana. Un agente que borra registros o aprueba facturas sin supervisión puede causar daño operativo real.
En el contexto del AI Act europeo, los agentes que toman decisiones autónomas sobre datos financieros o de clientes pueden clasificarse como sistemas de IA de riesgo limitado o alto según el uso. Aunque la mayoría de casos descritos aquí caerían en riesgo limitado o mínimo, conviene documentar las capacidades del agente y los controles implantados. Desde Summum Consultoría acompañamos la evaluación de riesgos conforme al AI Act cuando el agente tiene capacidad de decisión autónoma.
Plazos y esfuerzo típico de implantación
| ERP | Versión mínima recomendada | Esfuerzo estimado (días/persona) | Herramientas disponibles «out of the box» |
|---|---|---|---|
| Odoo | 16 Community / Enterprise | 5–10 | Ventas, compras, facturación, almacén |
| Sage 200 | 2021 R2 o superior | 8–15 | Clientes, proveedores, facturación, stock |
| Dynamics 365 BC | Wave 2 2024 (v25) | 5–8 | Ventas, finanzas, inventario, proyectos |
Los rangos incluyen el despliegue del servidor MCP, la configuración de herramientas, las pruebas de integración y la formación del equipo que usará el agente. No incluyen el desarrollo del agente en sí (si se parte de cero) ni la implantación del ERP. Estos plazos asumen que la API del ERP está activa y documentada en la instalación del cliente.
Preguntas frecuentes
¿Necesito un ERP en la nube para usar MCP, o también funciona con instalación local?
MCP funciona con ambas modalidades. En instalaciones locales (on-premise), el servidor MCP se despliega en la misma red y el agente IA accede desde dentro del perímetro o a través de un túnel seguro. No es obligatorio que el ERP esté en la nube, aunque las instalaciones cloud facilitan la exposición del endpoint. Lo que sí es necesario es que el ERP disponga de una API accesible: REST, JSON-RPC u OData. Si tu versión de Sage o Dynamics es antigua y no tiene API moderna, ese es el primer paso a resolver.
¿El agente IA puede modificar datos en el ERP o solo leer?
Puede hacer ambas cosas, según los permisos que configures en el servidor MCP y en el propio ERP. En la mayoría de implantaciones de primera fase se activan solo herramientas de lectura para ganar confianza. Las herramientas de escritura (crear pedidos, actualizar registros, aprobar facturas) se añaden en una segunda fase, siempre con un paso de confirmación humana antes de ejecutar la acción. Nunca se recomienda dar al agente permiso de escritura sin un mecanismo de supervisión.
¿Qué pasa con los datos de mis clientes y proveedores que el agente ve en el ERP?
El servidor MCP actúa como intermediario: los datos no se almacenan en el servidor MCP más allá del tiempo necesario para responder la petición. Sin embargo, sí pasan por el modelo de lenguaje que el agente usa. Si ese modelo es un servicio externo en la nube (como la API de Anthropic o Azure OpenAI), los datos de clientes viajan fuera de tu perímetro. Para evitarlo, existen dos opciones: (1) desplegar un LLM propio en tu infraestructura, o (2) usar la anonimización de datos en el servidor MCP antes de enviarlos al modelo. En sectores con datos sensibles (salud, finanzas, datos de menores) esta decisión tiene implicaciones directas bajo el RGPD.
¿Es compatible MCP con n8n o con Power Automate para combinar el agente con otros flujos de trabajo?
Sí. Desde finales de 2024, n8n dispone de un nodo MCP client que permite invocar herramientas de cualquier servidor MCP dentro de un workflow de automatización. Power Automate aún no tiene un conector MCP nativo, pero puede llamar al servidor MCP mediante el conector HTTP genérico con autenticación Bearer. En implantaciones donde ya existe n8n, conectarlo al servidor MCP del ERP es especialmente eficiente porque el agente puede combinarse con disparadores (un nuevo pedido en el ERP activa el workflow) sin infraestructura adicional. El equipo de automatización con n8n de Summum IA puede ayudarte a diseñar este tipo de arquitectura híbrida.