En este artículo, aprenderá cómo el Protocolo de contexto modelo (MCP) estandariza la forma en que las aplicaciones de IA se conectan a herramientas externas y fuentes de datos, desglosadas en tres niveles de profundidad.
Los temas que cubriremos incluyen:
Por qué conectar modelos a sistemas externos sin un estándar compartido crea un problema de integración que crece con cada nuevo cliente o herramienta. Cómo funcionan juntos el host, el cliente y el servidor, y qué sucede cuando la solicitud de un modelo fluye a través de un servidor MCP. Las opciones de transporte, los riesgos de seguridad y las opciones de implementación que importan una vez que un servidor MCP se ejecuta en producción.
Introducción
Cada modelo de lenguaje grande tiene la misma limitación incorporada: su conocimiento se detiene en el momento del entrenamiento. Pregúntele sobre un archivo en su máquina, una fila en su base de datos o un correo electrónico que llegó esta mañana y se detiene o adivina. El modelo está aislado de los sistemas en los que realmente se ejecuta su aplicación, y cerrar esa brecha recae completamente en el desarrollador.
El enfoque habitual es escribir integraciones personalizadas (una función aquí, una definición de herramienta allá) que canalicen datos externos a la ventana contextual. Eso funciona a pequeña escala. Pero una vez que conectas múltiples modelos a múltiples servicios, terminas manteniendo una matriz de adaptadores únicos, cada uno con su propia lógica de autenticación, suposiciones de esquema y modos de falla. Agregar un nuevo modelo o un nuevo servicio significa reelaborar toda esa matriz nuevamente.
El MCP es un estándar abierto, introducido por Anthropic, que le da a este problema una forma más clara. En lugar de que cada aplicación de IA cree sus propios conectores para cada sistema externo, ambas partes implementan un protocolo compartido. Un servicio se expone como servidor MCP una vez y cualquier cliente compatible con MCP puede utilizarlo.
Este artículo explica cómo funciona MCP en tres niveles: por qué existe el problema y cuál es la idea central de MCP, cómo encaja la arquitectura y cómo se ve una solicitud y, finalmente, las decisiones de transporte, seguridad e implementación que importan cuando se lleva a producción.
Nivel 1: Por qué es importante MCP
Un modelo solo puede funcionar con información disponible en su ventana contextual: el mensaje del sistema, el historial de conversaciones y cualquier dato adicional proporcionado durante la interacción. Acceder a información fuera de ese contexto requiere herramientas externas.
La mayoría de los sistemas de IA admiten la llamada de herramientas. Cuando un modelo solicita una herramienta, la aplicación ejecuta la solicitud, recupera los datos requeridos y devuelve el resultado al modelo. Esto permite que los modelos interactúen con bases de datos, API, sistemas de archivos y otros sistemas externos.
A medida que crece el número de aplicaciones de IA y herramientas externas, aumenta la complejidad de la integración. Considerar:
Clientes M AI (aplicaciones de chat, asistentes IDE, marcos de agentes, proveedores de modelos) N herramientas y fuentes de datos (bases de datos, API, servicios internos, plataformas SaaS)
Sin un estándar compartido, cada cliente normalmente requiere su propia integración con cada herramienta. Por lo tanto, el número de adaptadores de herramientas cliente puede crecer como M × N.
Por ejemplo, si tres aplicaciones de IA necesitan acceso a cinco herramientas internas, es posible que termines creando y manteniendo quince integraciones separadas. Agregar una nueva herramienta requiere integrarla con cada cliente. Agregar un nuevo cliente requiere integrarlo con cada herramienta.
El problema que resuelve MCP
MCP proporciona una forma estándar para que las aplicaciones de IA y los sistemas externos se comuniquen.
Las aplicaciones de IA implementan la especificación del cliente MCP. Las herramientas y las fuentes de datos exponen capacidades a través de servidores MCP. Debido a que ambas partes siguen el mismo protocolo, cualquier cliente MCP compatible puede utilizar un servidor MCP sin requerir una integración personalizada para ese cliente específico.
En lugar de crear un adaptador separado para cada par cliente-herramienta, cada cliente implementa el protocolo MCP una vez y cada herramienta lo implementa una vez. La superficie de integración pasa de aproximadamente M × N adaptadores personalizados a implementaciones de protocolos M + N.
El resultado práctico es un ecosistema más componible. Un servidor MCP que expone una base de datos PostgreSQL, una API interna o un sistema de tickets puede ser utilizado por múltiples asistentes, IDE y marcos de agentes a través del mismo protocolo en lugar de mediante integraciones separadas para cada plataforma.
Nivel 2: Arquitectura MCP y cómo fluye una solicitud
Las interacciones MCP involucran tres partes: el host, el cliente y el servidor.
El anfitrión
El anfitrión es la aplicación con la que el usuario realmente habla. Puede ser una interfaz de chat, un IDE con tecnología de inteligencia artificial o un agente personalizado. Contiene el modelo de lenguaje e impulsa la conversación. Cuando el modelo decide que necesita recurrir a un sistema externo, esa decisión se origina aquí.
El cliente
El cliente se sienta dentro del host y maneja la mecánica del protocolo. Mantiene un registro de servidores MCP disponibles, traduce las solicitudes del modelo en llamadas MCP formateadas correctamente, las envía al servidor correcto y convierte las respuestas en algo que el modelo pueda usar. Desde la perspectiva del modelo, simplemente pide cosas. El cliente se encarga de la fontanería.
El servidor
El servidor es su puente hacia un sistema externo. Registra sus capacidades (qué herramientas ofrece, qué datos puede proporcionar) y responde a las solicitudes de los clientes. Un servidor ubicado frente a una base de datos recibe una llamada de herramienta estructurada del cliente, ejecuta la consulta adecuada de forma segura y devuelve los resultados en un formato con el que el modelo puede trabajar. El servidor posee todos los detalles de implementación de ese sistema; el cliente y el modelo solo ven la interfaz MCP.
Host, clientes y servidor MCP
Seguimiento de una solicitud
Supongamos que un usuario le dice a un asistente de IA: “Tome las cifras de ingresos del segundo trimestre de la base de datos y elabore un resumen para el equipo”.
El modelo ve que necesita dos cosas que no puede hacer por sí solo. El cliente verifica sus servidores registrados y encuentra una herramienta de consulta de base de datos y una herramienta de borrador de correo electrónico en dos servidores MCP separados.
El modelo llama a Database_query con los parámetros relevantes. El servidor ejecuta la consulta, formatea los resultados y los envía a través del cliente al modelo. Ahora, trabajando con números reales, el modelo llama email_draft: lista de destinatarios, contenido, asunto. El servidor de correo electrónico se encarga del resto, confirma el éxito y el modelo le dice al usuario que ya está hecho.
Ninguno de los servidores sabía nada del otro. La modelo coordinó los pasos. El cliente se encargó de la traducción del protocolo todo el tiempo. El desarrollador no escribió ningún código adhesivo entre el modelo y ninguno de los sistemas.
Herramientas, recursos e indicaciones
Los servidores MCP exponen tres tipos de capacidades:
Las herramientas son funciones invocables. El modelo los invoca para actuar o recuperar resultados calculados. Los recursos son datos legibles que el modelo puede extraer como contexto: archivos, registros, documentos. Las indicaciones son plantillas reutilizables que proporciona el servidor, útiles para estandarizar cómo su organización quiere que el modelo aborde ciertas tareas.
La distinción entre herramientas y recursos es importante desde el punto de vista operativo. Leer un recurso es una operación pasiva y de riesgo relativamente bajo. Llamar a una herramienta que escribe en un sistema de producción es una categoría de acción completamente diferente. Mantenerlos separados le permite aplicar diferentes políticas de autorización a cada uno.
Nivel 3: transporte, seguridad y dónde se ejecuta MCP
Una vez que la arquitectura tiene sentido, las preguntas restantes son las que deciden si una implementación de MCP se sostiene fuera de una demostración: cómo se mueven físicamente los mensajes entre el cliente y el servidor, qué puede salir mal cuando un servidor no es confiable y dónde debe ejecutarse el servidor.
Cómo hablan realmente el cliente y el servidor
MCP divide la comunicación en dos capas y vale la pena entenderlas:
La capa de datos es el protocolo real: debajo es JSON-RPC 2.0 y define el ciclo de vida de la conexión más las primitivas que discutimos anteriormente. La capa de transporte es simplemente el conducto por el que viajan esos mensajes para llegar del cliente al servidor.
Dos servidores que exponen herramientas idénticas pueden ejecutar transportes completamente diferentes sin que la capa de datos se preocupe en absoluto; esa separación es lo que permite a MCP intercambiar uno por otro sin tocar el comportamiento de ninguna herramienta.
MCP actualmente define dos transportes:
stdio es para servidores locales. El cliente inicia el servidor como un subproceso y los dos hablan sobre entrada y salida estándar. Es simple, rápido, no necesita configuración de red y mantiene todo en una sola máquina. Esto es una buena opción para complementos IDE, acceso a archivos locales y cualquier cosa que se ejecute junto con el host. HTTP transmitible es para servidores remotos. El cliente y el servidor intercambian mensajes JSON-RPC a través de un único punto final HTTP que admite POST y GET, y el servidor utiliza opcionalmente Eventos enviados por el servidor para transmitir múltiples mensajes, lo cual es útil para llamadas de larga duración y notificaciones iniciadas por el servidor.
El problema de la confianza y las limitaciones de seguridad
MCP le brinda a un modelo un acceso real a bases de datos, bandejas de entrada o cualquier cosa que toque una herramienta. La mayor parte del riesgo real proviene de la autenticación, que es lo que describe la página de mejores prácticas de seguridad de MCP:
Un servidor proxy que reutiliza una ID de cliente fija y confía en una cookie sobrante del navegador en lugar de verificar el consentimiento de cada cliente puede terminar reenviando un código de autorización robado. Reenviar el token de un cliente a un servicio descendente sin confirmar que realmente fue emitido para usted infringe los registros de auditoría y los límites de velocidad. Un ID de sesión adivinable o vinculado incorrectamente permite que cualquiera que lo encuentre actúe como ese usuario.
También hay un problema de exposición separado: un servidor malicioso puede entregarle a un cliente URL que apunten a IP internas o puntos finales de metadatos en la nube durante el descubrimiento rutinario de OAuth, y cualquier cosa que ejecute localmente se ejecuta con sus propios privilegios, por lo que un comando de inicio no revisado puede llegar directamente a su sistema de archivos. La solución en ambos casos es validar los tokens que se emitieron para usted, vincular las sesiones a la identidad real, otorgar alcances limitados y proteger los servidores locales en lugar de confiar en ellos de forma predeterminada.
La descripción general de MCP de Google sugiere lo siguiente: obtenga el consentimiento del usuario antes de que un agente actúe o comparta datos, limite lo que un servidor puede ver, no confíe en la autodescripción de una herramienta a menos que el servidor sea examinado, desinfecte lo que regresa antes de que se registre o se muestre, y siga auditando la actividad de la herramienta para detectar el uso indebido.
Transporte, seguridad y dónde se ejecuta MCP
Elegir dónde se ejecutan los servidores MCP
La división local versus remota que determina la elección de transporte también determina la forma de implementación.
Los servidores locales se ejecutan como subprocesos en la misma máquina que el host. Esto es rápido y privado, lo que se adapta a datos confidenciales o una configuración de desarrollo personal. Los servidores remotos se ejecutan de forma independiente y pueden atender a muchos clientes a la vez. Requieren más para funcionar, pero se escalan y se pueden mantener por separado de cualquier aplicación que los llame.
En lo que respecta al alojamiento, la misma fuente señala que las plataformas sin servidor como Cloud Run se adaptan a herramientas simples y sin estado que deberían reducirse a cero entre llamadas, mientras que algo como un entorno Kubernetes administrado se adapta a servidores con estado o de alto rendimiento que necesitan un control más preciso. El hecho de que esa infraestructura se administre por usted o se ejecute en su propio hardware se reduce principalmente a limitaciones de cumplimiento y residencia de datos. El alojamiento administrado gestiona el tiempo de actividad y la escalabilidad, mientras que el alojamiento propio intercambia esa comodidad por un control total.
Un ecosistema en crecimiento sobre el que construir
MCP es de código abierto, con SDK que cubren los principales idiomas y un conjunto en constante crecimiento de servidores MCP listos para usar para sistemas comunes como GitHub, Slack y Postgres. Por lo tanto, a menudo no es necesario crear un conector desde cero. El soporte al cliente ha seguido el mismo camino: los IDE como Visual Studio Code admiten MCP de forma nativa junto con Claude y otros asistentes.
Concluyendo
MCP resuelve un problema de integración real con el que se topa rápidamente cualquiera que cree aplicaciones impulsadas por IA: conectar modelos a sistemas externos es repetitivo, frágil y no se compone bien sin un estándar. El protocolo le brinda ese estándar: una separación clara entre la aplicación de IA y la capacidad externa, con una interfaz bien definida entre ellas.
A nivel conceptual, proporciona una forma consistente de acceder a información y capacidades externas. A nivel arquitectónico, define cómo los hosts, clientes y servidores trabajan juntos para conectar modelos con herramientas, recursos y solicitudes. A nivel operativo, proporciona opciones de transporte y patrones de seguridad que hacen que las implementaciones en el mundo real sean prácticas y escalables.
A medida que crece la adopción, MCP se está convirtiendo en una base común para crear sistemas de IA que puedan interactuar de manera confiable con el software y los datos de los que dependen.
Aquí hay algunos recursos que vale la pena marcar:
¡Feliz aprendizaje!