MCP (Model Context Protocol): cómo conectar tus agentes de IA a los sistemas de tu empresa

MCP es un protocolo abierto que define una forma estándar de que las aplicaciones de IA —asistentes, copilotos o agentes— se conecten a fuentes de datos, herramientas y sistemas externos. Lo presentó Anthropic a finales de 2024 como estándar abierto, y a lo largo de 2025 fue adoptado por buena parte del ecosistema, incluidos otros grandes proveedores de modelos y plataformas de desarrollo. Eso es lo que lo ha convertido en relevante: no es la propuesta de un fabricante, sino un punto de encuentro común.

La idea de fondo es simple. En lugar de que cada aplicación de IA invente su propia manera de hablar con cada herramienta, todos hablan el mismo idioma. Una vez que un sistema expone sus capacidades mediante MCP, cualquier aplicación compatible puede usarlas sin integración a medida. El modelo deja de estar aislado en su conversación y pasa a tener una vía estandarizada para consultar información y ejecutar acciones en el mundo real.

Para entender por qué MCP importa, conviene ver el problema que elimina. Imagina que tienes varias aplicaciones de IA (un asistente interno, un agente de soporte, un copiloto comercial) y varios sistemas a los que quieres conectarlas (CRM, ERP, documentación, base de datos, Jira, Slack). Sin un estándar, cada combinación es una integración propia: si tienes M aplicaciones y N sistemas, acabas construyendo y manteniendo del orden de M×N conectores distintos, cada uno con su formato, su autenticación y sus errores.

MCP convierte ese problema en algo manejable. Cada sistema se expone una sola vez como servidor MCP, y cada aplicación de IA habla MCP una sola vez como cliente. Pasas de M×N a M+N: construyes el conector de cada sistema una vez y lo reutilizas con cualquier aplicación compatible, presente o futura. Es el mismo principio que hizo útiles a los estándares anteriores —de los drivers de impresora a USB, del LSP en los editores de código—: dejar de resolver el mismo problema una y otra vez.

MCP sigue una arquitectura cliente-servidor sencilla de entender, con tres roles. No hace falta ser ingeniero para captar la idea, y sí ayuda a tomar buenas decisiones después:

• Host: la aplicación de IA con la que interactúa el usuario —un asistente de escritorio, un IDE, un agente empresarial—. Es quien orquesta y decide.
• Cliente MCP: el componente que vive dentro del host y mantiene la conexión con un servidor concreto, traduciendo entre la aplicación y el protocolo.
• Servidor MCP: el programa que expone las capacidades de un sistema —tu CRM, tu base de datos, tu documentación— de forma estandarizada para que el host pueda usarlas.

Un servidor MCP no expone "todo" de cualquier manera: ofrece tres tipos de capacidades bien diferenciadas, y entender esa diferencia es clave para diseñar integraciones seguras.

• Herramientas (tools): acciones que el modelo puede invocar —consultar un pedido, crear un ticket, buscar en una base de datos, enviar un correo—. Son lo más potente y también lo más sensible, porque pueden ejecutar efectos reales.
• Recursos (resources): datos y contexto que la aplicación puede leer —un documento, un registro, el resultado de una consulta—. Aportan información, no ejecutan acciones.
• Prompts: plantillas e instrucciones reutilizables que el servidor ofrece para guiar tareas habituales de forma consistente.

Una pregunta razonable: si esto va de conectar IA a sistemas, ¿no es lo que ya hacían las APIs o los plugins? La respuesta es matizada. MCP no sustituye a tus APIs: normalmente un servidor MCP las usa por debajo. Lo que aporta es una capa estándar pensada específicamente para que un modelo descubra y use capacidades sin integración a medida.

La diferencia práctica está en quién hace el trabajo de adaptación. Con una API tradicional, alguien tiene que programar cómo el modelo entiende esa API, cómo la llama y cómo interpreta la respuesta, y repetirlo para cada aplicación. Con MCP, el servidor describe sus capacidades de forma que cualquier host compatible las entiende y las puede usar sin código específico. Frente a los plugins propietarios de un único proveedor, MCP tiene la ventaja de ser abierto e interoperable: lo que construyes una vez sirve para distintas aplicaciones de IA.

MCP no compite con RAG ni con los agentes: es el tejido conectivo que los une. Conviene situar cada pieza para no mezclarlas. Lo explicamos en detalle en de ChatGPT a los agentes de IA y en RAG y bases de conocimiento, pero el resumen es este:

• RAG aporta conocimiento: recupera fragmentos relevantes de tu documentación para que las respuestas se apoyen en hechos. Una búsqueda en tu base de conocimiento puede exponerse, precisamente, como una herramienta MCP.
• El agente razona y decide: interpreta el objetivo, elige qué pasos dar y qué herramientas usar en cada momento.
• MCP es el canal estandarizado por el que el agente accede a esas herramientas y datos —incluida la búsqueda RAG, el CRM o la base de datos— sin un conector a medida por cada sistema.

MCP cobra sentido cuando dejas de pensar en un chat aislado y empiezas a pensar en un agente que necesita tocar varios sistemas. Algunos ejemplos concretos y acotados, que es como conviene empezar:

• Soporte: un agente que consulta el historial del cliente en el CRM, busca en la documentación interna vía RAG y crea o actualiza tickets, todo a través de servidores MCP gobernados.
• Comercial: un copiloto que prepara una reunión leyendo el CRM, las propuestas anteriores y la documentación de producto, combinando varios servidores MCP en una sola tarea.
• Operaciones e IT: un agente que consulta logs, bases de datos y sistemas de monitorización para diagnosticar incidencias, con las acciones de cambio siempre sujetas a aprobación humana.
• Gestión documental: acceso estandarizado a repositorios como SharePoint, Drive o Notion para buscar, resumir y referenciar información interna.
• Datos: consultas a bases de datos y data warehouses expuestas como herramientas de solo lectura, para que dirección obtenga respuestas sobre KPIs sin exportar nada a mano.

Aquí es donde hay que bajar las expectativas y subir el rigor. MCP da a un modelo una vía estandarizada para acceder a datos y ejecutar acciones, y eso —que es justo su valor— amplía la superficie de riesgo. No es un motivo para no usarlo, sino para usarlo con gobierno.

El protocolo ha ido madurando en este frente —por ejemplo, con una especificación de autorización basada en OAuth para servidores remotos—, pero la seguridad sigue dependiendo en gran medida de cómo lo despliegas tú: qué servidores autorizas, con qué permisos y con qué registro. Los puntos críticos a vigilar:

• Inyección de instrucciones a través de herramientas: contenido malicioso en los datos que el agente lee puede manipular su comportamiento. Si además puede actuar, el daño deja de ser teórico.
• Herramientas envenenadas (tool poisoning): un servidor MCP de terceros poco fiable puede describir sus capacidades de forma engañosa para inducir acciones no deseadas.
• Exceso de permisos: dar a un servidor MCP más acceso del que necesita convierte cualquier fallo en un problema grande. El principio de mínimo privilegio no es opcional.
• Gestión de tokens y credenciales: los servidores remotos manejan accesos a sistemas reales; un token comprometido es una puerta abierta.
• Confianza en servidores de terceros: instalar servidores MCP de la comunidad sin revisarlos es equivalente a ejecutar código ajeno sobre tus datos.
• Falta de trazabilidad: sin registro de qué herramienta se invocó, con qué datos y con qué resultado, es imposible auditar un error o un incidente.

MCP no es algo que se "active" de golpe en toda la organización. Como con cualquier capa que toca datos y procesos, conviene una adopción gradual y ordenada. Una secuencia razonable:

• Empieza por un caso de uso concreto, con valor claro y riesgo manejable, en lugar de "conectar la IA a todo".
• Arranca en modo solo lectura: servidores que consultan información antes que servidores que ejecutan acciones.
• Usa servidores oficiales o construidos internamente; revisa con lupa los de terceros antes de confiar en ellos.
• Aplica mínimo privilegio: cada servidor accede solo a lo que su caso de uso necesita.
• Centraliza el acceso con una pasarela o capa de gobierno en lugar de instalaciones sueltas por equipo.
• Registra todas las invocaciones de herramientas y mantén supervisión humana en las acciones sensibles.
• Define una política interna de uso y forma a los equipos antes de escalar.

MCP ha pasado en poco más de un año de propuesta de un fabricante a estándar adoptado por gran parte del sector, con servidores disponibles para multitud de sistemas y soporte en las principales plataformas de desarrollo de IA. Esa tracción es real y es la mejor señal de que merece la pena conocerlo y empezar a usarlo en casos acotados.

Conviene, eso sí, mantener la prudencia que pedimos siempre. Es un ecosistema que sigue evolucionando: la especificación se actualiza, las prácticas de seguridad se están consolidando y la interoperabilidad entre agentes —el terreno de protocolos complementarios como A2A (Agent2Agent), pensado para que agentes de distintas plataformas se comuniquen— todavía está madurando. MCP resuelve cómo un agente se conecta a herramientas y datos; A2A apunta a cómo se coordinan varios agentes entre sí. Ambos van en la misma dirección: sistemas conectados e interoperables en lugar de soluciones cerradas. La recomendación es la de siempre: adoptar lo que ya aporta valor, evaluar madurez y seguridad antes de cada paso, y no llevar a producción nada que no entiendas y puedas gobernar.

Conectar agentes de IA a los sistemas reales de una empresa es, sobre todo, un problema de arquitectura, seguridad y gobierno del dato —no solo de elegir un protocolo. En DatIACode lo abordamos en tres niveles complementarios:

• Formación en IA generativa, agentes y su integración para equipos técnicos y de negocio, adaptada por perfil — formación en IA generativa.
• Diseño de casos de uso y arquitectura: qué conectar, con qué permisos, con qué supervisión y con qué trazabilidad, para empezar por donde el valor es claro y el riesgo es manejable.
• Implantación técnica con IA, RAG, agentes y MCP sobre tu stack —incluido Java con Spring AI— y, cuando hay procesos o datos sensibles, cumplimiento del AI Act.