MCP: qué estandariza al conectar IA, datos y herramientas

El 25 de noviembre de 2024, Anthropic presentó el Model Context Protocol, o MCP, como un estándar abierto para conectar aplicaciones de IA con los sistemas donde viven datos y herramientas. El anuncio original partía de un problema reconocible: cada combinación de asistente y fuente externa necesitaba su propio conector, difícil de reutilizar y mantener.

MCP estandariza la conversación entre programas. No hace que un modelo razone mejor, no decide qué servidor merece confianza y no concede permisos por sí solo. La documentación oficial de arquitectura delimita su alcance con precisión: el protocolo se ocupa del intercambio de contexto y no dicta cómo una aplicación usa el modelo de lenguaje ni cómo administra el contexto recibido.

La capacidad transferible consiste en separar cinco capas que suelen mezclarse: conexión, capacidad anunciada, autorización, decisión del modelo y ejecución real. Que dos sistemas hablen MCP prueba compatibilidad de protocolo. Para confiar en una acción todavía hay que saber quién ofrece la herramienta, qué puede hacer, con qué identidad se ejecuta y qué control conserva la aplicación.

Tres participantes, una conexión por servidor

La arquitectura distingue host, client y server. El host es la aplicación de IA que coordina la experiencia y sus políticas. Dentro de ella, un cliente MCP mantiene una conexión dedicada con un servidor. El servidor es el programa que expone contexto o funciones, tanto si corre en el mismo ordenador como si está alojado remotamente.

Si un editor conecta un servidor de incidencias y otro de archivos, el host crea un cliente para cada uno. Esa separación permite negociar capacidades y aislar conexiones, pero no equivale a un límite de seguridad automático. El host sigue siendo responsable de controlar qué entra en el contexto, qué herramientas muestra al modelo, qué acción permite y qué resultado devuelve al usuario.

La comparación con USB-C sirve hasta cierto punto: un contrato común evita diseñar un cable distinto para cada pareja de productos. Pero un servidor MCP puede aportar texto que influya en el modelo o ejecutar una función que cambie el mundo. Por eso la procedencia de la descripción, el contenido y el código importa mucho más que en un conector físico.

Dos capas: mensajes y transporte

La capa de datos usa JSON-RPC 2.0 y define la estructura de peticiones, respuestas y notificaciones. Incluye el ciclo de vida de la conexión, negociación de capacidades y primitivas compartidas. La capa de transporte decide cómo viajan esos mensajes. La documentación actual describe stdio para procesos locales y Streamable HTTP para conexiones remotas, con POST y transmisión opcional mediante eventos enviados por el servidor.

Al comenzar, cliente y servidor intercambian versión, identidad de implementación y capacidades. Si no pueden acordar una versión compatible, la conexión debe terminar. Después, una notificación indica que la inicialización ha concluido. Esta secuencia evita que un cliente invoque a ciegas funciones que el otro extremo no declaró soportar; no comprueba que la función declarada sea honesta o segura.

Las notificaciones permiten avisar, por ejemplo, de que cambió la lista de herramientas. El cliente puede volver a solicitarla y actualizar su registro. Ese dinamismo mejora interoperabilidad, pero exige decidir qué ocurre si una capacidad aparece o cambia durante una conversación: refrescar una lista no debería ampliar permisos silenciosamente.

Herramientas, recursos y prompts no son lo mismo

Un servidor puede exponer tres primitivas centrales. Un recurso aporta datos de contexto, como un archivo, un esquema o un registro. Un prompt ofrece una plantilla reutilizable para estructurar una interacción. Una herramienta es una función ejecutable: consultar una API, escribir un fichero, crear una incidencia o actualizar un pedido.

El cliente descubre herramientas con tools/list y puede invocar una mediante tools/call con argumentos que deben ajustarse a un esquema. La especificación de herramientas admite resultados estructurados y no estructurados. También advierte que las anotaciones sobre comportamiento —por ejemplo, si algo dice ser de solo lectura o idempotente— deben considerarse no fiables cuando proceden de servidores no confiables.

Esa advertencia revela la frontera correcta. El protocolo transporta nombre, descripción, esquema y resultado; no verifica que “consultar” nunca escriba ni que “borrar borrador” sea reversible. Un cliente seguro necesita una política propia, una lista de servidores admitidos, validación de entradas y salidas, confirmación para efectos sensibles y registros que permitan reconstruir lo ocurrido.

Lo que el cliente también puede ofrecer

La dirección no siempre va del servidor al host. El cliente puede ofrecer sampling, para que un servidor solicite una generación al modelo sin integrar un proveedor concreto; elicitation, para pedir al usuario información o confirmación; y mensajes de registro. Son capacidades negociadas, no derechos que cualquier servidor obtiene al conectarse.

La guía oficial de conceptos del cliente describe controles humanos para sampling y elicitation. El usuario puede revisar y modificar solicitudes o respuestas y rechazar la entrega de información. Elicitation no debe pedir contraseñas ni claves de API. La interfaz tiene que identificar qué servidor pregunta, para qué y cómo se usará el dato.

Los roots permiten que el cliente comunique directorios dentro de los que un servidor debería operar. La propia guía marca el límite: esos roots expresan fronteras previstas, pero no aplican restricciones de seguridad. Un proceso local con permisos amplios no queda encerrado por recibir una lista de carpetas. El aislamiento debe existir en el sistema operativo, el contenedor o la política del host.

Autorización no es sinónimo de conexión

En servidores remotos, la especificación de autorización de MCP se apoya en OAuth y metadatos protegidos para descubrir el servidor de autorización. Los tokens deben estar destinados al servidor MCP correspondiente. Pasar sin validación un token recibido hacia una API posterior está prohibido porque rompe límites de audiencia, dificulta la auditoría y puede convertir el servidor en vía de exfiltración.

Aun con OAuth, el diseño debe aplicar mínimo privilegio. Un token que reúne desde el principio acceso a archivos, bases de datos y administración multiplica el daño si se filtra. Alcances separados, tokens breves, consentimiento por cliente, validación exacta de redirecciones y credenciales fuera de registros reducen el radio de impacto.

Para stdio, el proceso se ejecuta localmente y no usa el mismo flujo remoto de autorización. Eso no lo hace inocuo: normalmente hereda privilegios del cliente que lo lanza. Instalar un servidor local equivale a ejecutar software. Hay que conocer su procedencia, revisar el comando completo, limitar archivos y red, y usar un entorno aislado cuando sea posible.

Riesgos que el estándar nombra pero no elimina

Las buenas prácticas oficiales de seguridad describen ataques de intermediario confundido, paso indebido de tokens, secuestro de sesión, peticiones a recursos internos y compromiso de servidores locales. Un servidor malicioso puede intentar que el cliente consulte direcciones internas durante el descubrimiento de OAuth; un paquete local puede contener un comando de inicio dañino; un resultado puede introducir instrucciones destinadas al modelo.

Las mitigaciones viven en la implementación: HTTPS para conexiones remotas, validación de destino y redirecciones, protección frente a SSRF, identificadores de sesión impredecibles, separación de identidades, sandbox, aprobación visible y telemetría. MCP hace posible describir una conexión de forma común. No inspecciona el código del servidor, no certifica su editor y no sustituye la autorización de la API final.

También hay riesgo semántico. Un servidor de calendario autorizado puede devolver datos falsos por un error; un modelo puede escoger una herramienta correcta con argumentos equivocados; una herramienta puede ejecutar bien una orden que el usuario no pretendía. Autenticidad, exactitud, intención y permiso son preguntas separadas. Una conexión cifrada solo responde a una parte.

Cómo evaluar una integración MCP

Primero se inventarían participantes y límites: host, clientes, servidores, transporte y datos alcanzables. Después se enumeran primitivas y efectos: qué recursos se leen, qué herramientas escriben, qué prompts entran en contexto y qué capacidades del cliente puede solicitar el servidor. Cada herramienta sensible necesita identidad, alcance, validación, confirmación y registro.

Luego se prueban casos adversos: descripción engañosa, parámetros fuera del esquema, servidor que cambia herramientas, respuesta con instrucciones hostiles, token para audiencia incorrecta, dirección interna durante descubrimiento y proceso local que intenta salir del directorio autorizado. Las pruebas deben observar el efecto real, no confiar en la anotación enviada por el propio servidor.

En diciembre de 2025, Anthropic donó MCP a la Agentic AI Foundation, un fondo dirigido bajo la Linux Foundation. Ese cambio de gobernanza puede facilitar un estándar compartido, pero no altera el criterio técnico. MCP reduce conectores exclusivos; la confianza sigue construyéndose en cada frontera. La pregunta duradera no es “¿usa MCP?”, sino “¿qué capacidad conecta, con qué autoridad, y qué impide que una entrada no fiable produzca un efecto indebido?”.