Los agentes de IA empiezan a evolucionar desde asistentes que únicamente generan respuestas hacia soluciones capaces de consultar información y ejecutar acciones. Para conseguirlo, necesitan conectarse con herramientas, datos y sistemas empresariales.
Hasta ahora, muchas de estas integraciones se desarrollaban específicamente para cada aplicación. Model Context Protocol, conocido como MCP, propone una forma estandarizada de exponer herramientas y contexto para que puedan ser utilizados por aplicaciones basadas en inteligencia artificial.
¿Qué es Model Context Protocol?
MCP es un protocolo abierto que permite conectar aplicaciones de IA con fuentes de datos y herramientas externas mediante una interfaz común.
En una arquitectura MCP encontramos principalmente tres elementos:
• Host: aplicación que contiene la experiencia de usuario y coordina el agente.
• Cliente MCP: componente que mantiene la comunicación con un servidor MCP.
• Servidor MCP: servicio que publica herramientas, recursos o capacidades concretas.
Un servidor podría permitir consultar pedidos, buscar productos, acceder a documentación o crear incidencias. El agente descubre las capacidades disponibles y decide cuándo utilizarlas según la solicitud del usuario y las instrucciones configuradas.
Arquitectura MCP: el servidor expone las capacidades de los sistemas corporativos a través de una interfaz común. MCP no sustituye a las APIs existentes. En muchos casos, un servidor MCP actúa como una capa sobre servicios REST, bases de datos o aplicaciones corporativas, exponiendo sus capacidades de una forma comprensible para los agentes.
¿Qué aporta MCP a una arquitectura empresarial?
Sin un mecanismo común, cada agente puede necesitar integraciones diferentes para conectarse con los mismos sistemas. Esto aumenta el acoplamiento, duplica desarrollos y dificulta el mantenimiento.
MCP permite encapsular esas integraciones en servidores reutilizables. Por ejemplo, un servidor MCP para el sistema de pedidos podría utilizarse desde un asistente comercial, una aplicación de soporte o un agente interno de operaciones.
Además, separa la lógica de integración de la lógica del agente. El servidor es responsable de comunicarse con el sistema corporativo, mientras que el agente decide cuándo solicitar una determinada operación.
Esto no elimina la necesidad de diseñar contratos, controlar versiones o mantener las APIs subyacentes, pero introduce una capa común que facilita la interoperabilidad entre aplicaciones y herramientas.
Un ejemplo dentro de la empresa
Imaginemos un agente de soporte conectado mediante MCP a distintos sistemas. Ante la consulta de un cliente, podría:
• Buscar documentación relacionada con el problema.
• Consultar en el ERP el estado de un pedido.
• Recuperar la información permitida del cliente.
• Comprobar incidencias similares.
• Proponer la creación de un ticket.
• Solicitar confirmación antes de registrarlo.
La diferencia entre consultar un pedido y modificarlo es importante. Las herramientas de lectura pueden tener un nivel de riesgo limitado, mientras que cancelar un pedido, cambiar datos o enviar comunicaciones requiere controles adicionales.
Identidad, autorización y mínimo privilegio
Adoptar MCP no significa que todos los agentes deban tener acceso a todas las herramientas. Cada operación debe protegerse mediante los mismos mecanismos que utilizaríamos en cualquier otra aplicación empresarial.
En un entorno Microsoft, podemos utilizar Microsoft Entra ID para gestionar identidades, permisos delegados o identidades de aplicación. Cuando sea posible, el sistema debería conservar el contexto del usuario para que la operación respete sus permisos reales.
También debemos diferenciar entre autenticación y autorización. Que un agente pueda conectarse con un servidor MCP no significa que esté autorizado para ejecutar todas sus herramientas.
La autorización debe comprobarse en el servidor y en el sistema de destino, nunca únicamente mediante instrucciones incluidas en el prompt.
Seguridad y gobierno de los servidores MCP
Un servidor MCP debe tratarse como un componente de integración empresarial. Antes de incorporarlo a una arquitectura, debemos conocer quién lo mantiene, qué datos procesa, qué herramientas expone y con qué sistemas se comunica.
Entre los principales riesgos encontramos servidores no confiables, descripciones manipuladas, parámetros maliciosos, exfiltración de información y ejecución de acciones no autorizadas.
Para reducirlos, conviene aplicar:
• Un catálogo de servidores aprobados.
• Validación estricta de parámetros.
• Herramientas con responsabilidades limitadas.
• Separación entre lectura y escritura.
• Confirmación humana para acciones sensibles.
• Registro y auditoría de las operaciones.
• Control de versiones y mecanismos de desactivación.
• Aplicación del principio de mínimo privilegio.
¿Cuándo tiene sentido utilizar MCP?
MCP puede aportar valor cuando varias aplicaciones necesitan reutilizar las mismas herramientas, cuando queremos desacoplar los agentes de los sistemas corporativos o cuando existe una estrategia para gobernar las integraciones.
Sin embargo, no es obligatorio utilizarlo en todos los proyectos. Si tenemos una única integración sencilla, una API convencional puede ser suficiente. Incorporar MCP sin una necesidad clara también puede añadir componentes y complejidad operativa.
Su verdadero valor no está únicamente en conectar un agente con una herramienta, sino en crear un modelo reutilizable y gobernado para que distintas aplicaciones de IA puedan interactuar de forma controlada con los sistemas de la empresa.
Si estás explorando cómo integrar la IA con tus sistemas corporativos, nuestro equipo de expertos puede ayudarte a identificar el enfoque más adecuado para tu organización.