Anthropic publicó MCP en noviembre de 2024. Un año después, Microsoft, OpenAI y la mayoría del ecosistema lo adoptaron. Esta guía explica qué es, cómo funciona y por qué importa para tu Dataverse, AS400, Sage u Oracle.
Si en tu empresa tienes tres modelos de IA distintos (Claude para análisis, Copilot para productividad, GPT para código) y cinco sistemas (Dataverse, Sage, AS400, Fabric, SQL interno), antes de MCP necesitabas quince integraciones. Cada par modelo–sistema con su propio formato de function calling, su propia autenticación, su propio logging.
Y al año siguiente, cuando aparece un modelo nuevo que vale el doble, toca reescribir los cinco conectores otra vez.
Cada nuevo modelo o sistema multiplica el trabajo. Diferentes formatos, diferentes auth, mantenimiento exponencial.
Un único protocolo. Un servidor por sistema, un cliente por modelo. Auth y logging centralizados.
Anthropic describe MCP, sin metáforas finas, como "USB-C for AI". Antes, cada cable. Ahora, un puerto.
La especificación oficial de MCP define cómo se comunican tres tipos de actores: un cliente (la app del modelo IA), un servidor (que expone capacidades) y un sistema (la fuente real de datos o acciones). El cliente y el servidor hablan MCP entre ellos. El servidor habla el protocolo nativo del sistema (SQL, REST, RPG).
El truco está en que cliente y servidor no necesitan conocerse de antemano. Cualquier servidor que hable MCP puede ser consumido por cualquier cliente que hable MCP. Esto desacopla la evolución de los modelos (renuevan cada 3-6 meses) de la evolución de los sistemas empresariales (renuevan cada 5-10 años).
Un comercial pregunta a Copilot: "¿cuáles son las facturas pendientes del cliente Acme?". Lo que para él es una frase, para el sistema son ocho pasos coreografiados entre cliente, servidor MCP, motor de auth y Sage 200.
Un servidor MCP productivo no es un script Python con dos endpoints. Tiene capas claras: el protocolo, una capa de transporte, autenticación, autorización, lógica de tools/resources, y los adaptadores nativos que hablan con cada sistema.
La app del modelo IA. Inicia conexión, descubre capabilities y orquesta llamadas. No conoce el sistema final.
JSON-RPC 2.0 estandarizado. Tres transportes posibles: stdio para local, SSE para servidores remotos, HTTP streamable para empresas.
OAuth 2.1 con Entra ID. El servidor extrae claims del token, identifica al usuario y aplica RBAC por tool. Filtrado de campos sensibles antes de devolver datos.
La implementación de las capabilities que expone el servidor. Cada tool es una función con schema. Cada resource es una URI. Cada prompt es una plantilla.
Cliente SQL, conector REST, driver DB2 para AS400, SDK de Sage o Fabric. La capa que traduce la intención del modelo al lenguaje del sistema final.
El destino final. Donde realmente viven los datos. El servidor MCP nunca los reemplaza, solo los pone al alcance de la IA con control.
Un servidor MCP expone tres tipos de capacidades. Entender la diferencia es clave para diseñar integraciones que sean potentes pero también auditables.
Funciones tipadas con JSON-Schema. El modelo decide cuándo y con qué argumentos llamarlas. Pueden tener efectos secundarios: crear un ticket, actualizar un estado, lanzar un email.
URIs que apuntan a fuentes de información. El modelo puede listarlas y leerlas. No mutan estado. Útil para corpus que el modelo explora: catálogos, históricos, KB.
Workflows recurrentes empaquetados como prompts parametrizados. El usuario los invoca por nombre y el servidor devuelve el prompt completo con contexto inyectado.
Regla práctica: usa tools para acciones discretas (consultar pedido X, crear ticket Y), resources para corpus que el modelo puede explorar (catálogos, históricos), y prompts para empaquetar workflows recurrentes que tu equipo repite cada semana.
Hay tres formas comunes de conectar un modelo a información externa: RAG, function calling propietario y MCP. No son alternativas; resuelven problemas distintos. Esta tabla te ayuda a elegir según el caso.
Una arquitectura empresarial típica usa RAG para conocimiento y MCP para datos operativos. El modelo elige qué herramienta usar según la pregunta.
No todos los sistemas se conectan igual. Algunos son obvios (Dataverse, Sage). Otros requieren capa de integración custom (AS400, Oracle on-prem). Aquí está cómo abordamos los cuatro stacks que más vemos:
El más natural para MCP. Dataverse ya tiene tablas, relaciones, RBAC y Entra ID integrados. El adaptador es delgado: expone entidades como tools y hereda los permisos del usuario logueado en Copilot.
Ideal para empresas que ya tienen su CRM, operaciones o master data en Power Platform y quieren que Copilot Studio acceda sin más fricciones.
contacts.search(filter)
opportunities.get(id)
tickets.create(...)
orders.update_status(id, status)
Lo más complejo. AS400 con RPG/COBOL no tiene APIs modernas. Construimos una capa de integración (DB2 nativo, Jolt para BEA, o microservicios sobre transacciones existentes) que el MCP server consume.
Cache inteligente para evitar saturar sistemas heredados con consultas IA inesperadas. Crítico en bancos, manufactura y logística donde AS400 sigue siendo backbone.
oracle.get_shipment(id)
as400.list_orders(date_range)
oracle.get_inventory(warehouse)
as400.run_query(sql_template)
Sage tiene APIs modernas (REST + OData en 200/X3). El servidor MCP se conecta directo y expone facturas, balances, contabilidad y CRM. Compatibilidad con sociedades múltiples nativa, lo que es crítico para asesorías que llevan decenas de empresas en una misma instalación.
Caso típico: cliente final consulta vía chat IA "¿cuál es mi saldo del cliente X?" y recibe respuesta sin pasar por el asesor.
sage.list_invoices(customer, status)
sage.get_balance(account)
sage.search_customers(query)
sage.get_aging_report()
Para datos a escala (TB). El MCP server expone semantic models y permite al modelo consultar datalakes vía DAX o SQL endpoints de Fabric sin mover datos. Ideal para KPIs corporativos en grupos con muchas unidades de negocio.
Permite construir agentes que cruzan datos de marketing, ventas y operaciones sin mover petabytes ni romper governance. Lo combinamos a menudo con dashboards Power BI existentes.
fabric.query_semantic(dax)
fabric.list_datasets()
onelake.read_table(name, filter)
fabric.get_kpi(name, period)
Exponer un ERP a una IA da miedo si no se hace bien. Estas son las cinco capas mínimas que tiene que tener un servidor MCP empresarial que merezca llamarse así.
Importante: MCP es solo el protocolo de transporte. La seguridad la implementa el servidor. Antes de exponer cualquier sistema, exige a tu proveedor que demuestre estas cinco capas con tests reales. Las soluciones "MCP plug-and-play" del marketplace que saltan estos pasos son peligrosas en entornos regulados.
Implementaciones anonimizadas en producción real. Mismo protocolo, tres sectores y stacks distintos. Cada caso resuelve un problema operativo concreto. Puedes ver más detalle en nuestros casos de éxito.
Operativa portuaria con miles de movimientos diarios en Oracle. Antes: TI hacía queries SQL bajo petición. Ahora: managers consultan turnos, embarques, retrasos y ETAs en lenguaje natural desde Teams.
Asesores fiscales con Sage 200 compartido. Clientes finales (autónomos, PYMES) consultan facturas, IVA y balances vía chat IA con autorización por NIF. Asesores liberados de consultas operativas básicas.
30+ orígenes de datos repartidos entre Dataverse, Microsoft Fabric y datalakes departamentales. Un único MCP los expone como tools coherentes. Agentes de marketing y editorial sobre datos siempre vivos.
Esta guía está basada en la documentación pública de Anthropic, Microsoft y la comunidad MCP. Te dejamos los enlaces clave por si quieres profundizar:
30 minutos por videollamada. Te mostramos un servidor MCP en producción real y vemos qué partes de tu stack tendría sentido conectar primero. Sin compromiso, sin presentación de PowerPoint.
Hablemos de tu caso