Artículo · Arquitectura y tecnología
MCP (Model Context Protocol): qué es y para qué sirve en una empresa
MCP, o Model Context Protocol, es un protocolo abierto que estandariza cómo un agente de IA se conecta a sistemas y datos externos. En lugar de programar una integración distinta para cada combinación de agente y herramienta, MCP define una forma común: un servidor expone lo que un sistema sabe hacer y lo que contiene, y cualquier agente compatible lo consume sin conocer sus tripas. Es la diferencia entre cablear cada aparato con su propio conector y tener un enchufe estándar.
No es un producto ni un modelo. Es una convención sobre cómo hablan las piezas. Y para una empresa que evalúa poner agentes a trabajar en su operación, esa convención cambia una cuenta que casi nadie mira al principio y que decide el coste real del proyecto: la de las integraciones.
El problema que resuelve MCP
Un agente que solo conversa no necesita nada más que un modelo. Un agente que trabaja necesita tocar tus sistemas: leer el ERP, consultar el CRM, abrir un correo, escribir en una base de datos, lanzar una consulta a un almacén de documentos. Cada uno de esos accesos es una integración, y hasta hace poco cada integración se programaba a mano, atada a la vez al sistema concreto y al framework de agentes que la usaba.
Esa cuenta crece mal. Si tienes cinco agentes que necesitan hablar con ocho sistemas, la aproximación ingenua tiende a un enjambre de conexiones a medida, cada una con su formato, su autenticación y su mantenimiento. Cuando cambias de framework, o el fabricante del sistema modifica su interfaz, se rompen varias a la vez y nadie sabe cuántas. He visto proyectos donde el modelo funcionaba de maravilla y el cuello de botella era exactamente esto: pegamento frágil entre cajas que no fue pensado para durar.
MCP ataca ese enjambre por el lado del estándar. Defines una vez cómo se expone un sistema —como un servidor MCP— y ese servidor sirve a cualquier agente que hable el protocolo. La integración deja de ser un cable entre dos puntos concretos y pasa a ser un componente reutilizable.
Cómo funciona, en términos que le importan a un directivo
No hace falta leer la especificación para entender el reparto. MCP distingue dos papeles.
Un servidor MCP envuelve un sistema o una fuente de datos y publica lo que ofrece en dos categorías: herramientas (acciones que se pueden ejecutar: crear un pedido, consultar un saldo, enviar un aviso) y recursos (información que se puede leer: un documento, un registro, el contenido de una tabla). El servidor describe cada cosa de forma que el agente entienda qué hace y qué necesita para invocarla.
Un cliente —el agente, o el sistema que lo hospeda— se conecta a esos servidores, descubre lo que exponen y lo usa cuando la tarea lo pide. El modelo de lenguaje decide qué quiere hacer. El protocolo estandariza cómo lo pide y cómo recibe la respuesta.
La consecuencia práctica es que la lógica de conexión vive en el servidor, no repartida por cada agente. Conectas un sistema una vez y queda disponible para toda tu operación agéntica. Y cuando quieras sustituir el modelo por otro —algo que en Arkatai damos por hecho, porque tratamos los modelos como una utility intercambiable— las integraciones no se tocan, porque no dependían de las primitivas de ningún fabricante concreto.
Qué significa MCP para tu empresa
Traducido a decisiones de negocio, un protocolo abierto de conexión cambia tres cosas.
| Sin protocolo estándar | Con un protocolo como MCP |
|---|---|
| Cada integración se ata al agente y al framework que la usa | La integración es un componente que reutilizan varios agentes |
| Cambiar de modelo o framework arrastra reprogramar conexiones | El modelo se sustituye sin tocar cómo se accede a los sistemas |
| El conocimiento de “cómo se conecta esto” se dispersa | La conexión de cada sistema queda definida en un sitio |
La primera es reutilización: lo que codificas para un caso sirve para el siguiente. La segunda es menos dependencia del proveedor: si tus accesos a datos y sistemas no están soldados a las primitivas de un laboratorio, conservas la libertad de elegir el mejor modelo para cada tarea sin rehacer la fontanería. La tercera es claridad operativa: la superficie por la que un agente toca tus sistemas queda definida y acotada, que es justo donde hay que poner permisos y controles.
Esa última conviene subrayarla. Un servidor MCP es una puerta a tus datos, y una puerta se gobierna: qué expone, qué puede escribir un agente a través de él, con qué credenciales. El protocolo estandariza el mecanismo de conexión. No decide por ti qué es prudente conectar. Esa parte es gobierno, y la trato en protección de datos con IA y en gobernanza de agentes.
Dónde encaja MCP en la arquitectura
Conviene no confundir MCP con las piezas vecinas, porque el mercado tiende a meterlo todo en el mismo saco.
MCP resuelve la conexión entre el agente y el mundo exterior. No es lo mismo que la orquestación, que decide qué agente hace qué y en qué orden cuando hay varios pasos o varios agentes. Eso lo desarrollo en orquestación de agentes. Tampoco es lo mismo que dar al agente acceso a un corpus de documentos para responder con base en él, que es el patrón de RAG empresarial. Y aunque un servidor MCP puede ser la vía por la que el agente alcanza ese corpus, el problema de recuperar el fragmento correcto es otro. Y no tiene que ver con lo que el agente retiene entre pasos o entre sesiones, que es memoria y contexto en agentes.
Pensado en capas: el modelo razona, la orquestación reparte el trabajo, la memoria conserva el estado, y MCP es el conjunto de puertas estandarizadas por las que el sistema toca la realidad. Cómo se ensamblan todas esas piezas en un sistema que aguanta producción es el asunto de la arquitectura de agentes de IA.
Por qué esto importa ahora
MCP es reciente y su adopción está en marcha, así que no lo presento como una decisión que un comité tenga que tomar mañana. Lo presento como una señal de hacia dónde va la parte fontanera de este trabajo: hacia estándares abiertos que despegan las integraciones del proveedor de modelo.
Para mí, que despliego estos sistemas en operaciones reales, esa dirección es la correcta por una razón concreta: la parte cara y frágil de un proyecto de agentes rara vez es el modelo, es todo lo que lo rodea. Reducir el coste de conectar y reconectar sistemas es reducir el coste de mantener la operación viva cuando el modelo, el proceso o el mercado cambien —que cambiarán—. Un agente aislado es una demo. Un agente que trabaja de verdad lo hace porque está bien conectado a la casa. Ese trabajo de conexión es exactamente la parte que en Arkatai codificamos al desplegar, y forma parte de lo que significa tratar el modelo operativo como código. El resto del panorama, para quien empiece por el principio, está en el pilar sobre agentes de IA para empresas.
Preguntas frecuentes
¿Qué es MCP en pocas palabras?
Es un protocolo abierto que estandariza cómo un agente de IA se conecta a sistemas y datos externos. Un servidor MCP expone las herramientas y los recursos de un sistema, y cualquier agente compatible los usa sin necesidad de una integración programada a medida para cada combinación.
¿MCP es lo mismo que una API?
No exactamente. Una API es la interfaz de un sistema concreto. MCP es una capa por encima que estandariza cómo se describen y consumen esas capacidades para un agente. Un servidor MCP suele apoyarse en las APIs que ya existen, pero las presenta de una forma común para que el agente no tenga que aprender cada una por separado.
¿Necesito MCP para poner agentes a trabajar?
No es obligatorio. Hay agentes que funcionan con integraciones a medida. Lo que un protocolo abierto aporta es que esas conexiones sean reutilizables y menos dependientes del proveedor de modelo, lo que abarata mantener la operación con el tiempo. La decisión no es “MCP sí o no”, sino cómo evitar un enjambre de integraciones frágiles.
¿Conectar sistemas con MCP es un riesgo de seguridad?
El protocolo no crea el riesgo, pero sí concentra la superficie por la que un agente toca tus datos, y eso hay que gobernarlo: definir qué expone cada servidor, qué puede escribir un agente y con qué credenciales. Es una decisión de permisos y controles, no un ajuste técnico que se deje por defecto.