Capítulo 5 — Protocolos de transporte y descubrimiento

Quinta entrega del recorrido capítulo por capítulo de LLM Primer IV: Designing AI Cognition with MCP. Cada mensaje de los Capítulos 3 y 4 ha estado flotando en el aire entre host y servidor — pero los mensajes no flotan, viajan en un transporte, y el transporte decide en silencio casi todo lo operativo de una integración.

Por qué existe este capítulo

MCP define su formato de mensaje — JSON-RPC 2.0 sobre un canal dúplex — y luego define tres transportes que implementan el canal. Los transportes no son intercambiables. Cada uno encaja con un patrón de despliegue, arrastra un equipaje operativo distinto y expone superficies de seguridad diferentes. Una segunda pregunta planea sobre el mismo territorio: ¿cómo encuentra el host un servidor en primer lugar? Hasta que el host no sepa que un servidor existe y dónde vive, el protocolo más bellamente especificado no produce ninguna conversación.

Este capítulo recorre ambas cosas. Los transportes deciden si el servidor está co-localizado o remoto, si tienes autenticación o aislamiento de procesos, y cómo escala el servidor. La capa de descubrimiento decide si tu servidor es algo que usa un ingeniero o algo que un equipo puede adoptar.

5.1 stdio, SSE y Streamable HTTP

stdio es el host lanzando el servidor como proceso hijo. El host escribe JSON-RPC en el stdin del hijo y lee respuestas del stdout; stderr arrastra los logs. Sin puerto, sin socket, sin red. La autenticación la maneja la frontera de lanzamiento de procesos del sistema operativo. Claude Desktop, Cursor y el inspector oficial de MCP usan stdio para servidores locales. El modelo es honesto sobre lo que es: una herramienta en tu propia máquina, co-localizada, en el mismo dominio de confianza que el host. No se puede compartir entre hosts, no puede correr en otra máquina, y uno-por-host es la única multiplicidad disponible — cinco clientes que quieran el mismo servidor queman cinco procesos.

HTTP+SSE fue la primera respuesta de MCP al caso de red. Bidireccional, pero dúplex montado a partir de dos piezas unidireccionales. Deprecado. Todavía en el mundo. Te encontrarás con servidores basados en SSE durante un tiempo.

Streamable HTTP es el transporte de red preferido. Un único endpoint — habitualmente /mcp — acepta peticiones JSON-RPC y responde con una respuesta única (en llamadas síncronas) o con un stream de Server-Sent Events cuando hay varios mensajes, incluidas notificaciones iniciadas por el servidor. Las sesiones se identifican con una cabecera Mcp-Session-Id fijada en la inicialización y enhebrada en cada petición siguiente. La sesión es la unidad de estado, liberable por DELETE o recogida por timeout. El transporte se compone limpiamente con balanceadores de carga, proxies inversos, cachés de borde y TLS. El escalado horizontal es sticky-session por ID de sesión. Nada de esto es ingeniería HTTP novedosa; el punto es que MCP encaja dentro sin inventar una capa nueva.

La elección es tanto una decisión de seguridad como de despliegue. Los servidores stdio tienden a estar sobre-privilegiados — heredan los derechos de filesystem y red del usuario, sin autenticación porque no hay un llamador remoto. Los servidores de red miran al internet abierto y deben autenticar cada petición, con OAuth 2.1 ya convergiendo como estándar. Elegir el transporte equivocado para tu postura de seguridad te obliga a atornillarle por fuera lo que debería estar integrado.

5.2 Descubrimiento de servidores: .well-known/mcp.json y Server Cards

Un protocolo que exige que cada host esté configurado a mano con la dirección de cada servidor no se convierte en ecosistema. Se convierte en pesadilla de configuración. La capa de descubrimiento de MCP toma prestado el patrón de URI well-known de RFC 8615 — el mismo mecanismo que usan robots.txt y .well-known/openid-configuration. El servidor publica .well-known/mcp.json en su URL base. Un host la trae, la parsea y aprende lo que el servidor dice de sí mismo: el endpoint MCP, la versión de protocolo, el esquema de auth, los metadatos de identidad y un puntero a la Server Card.

La Server Card es el openapi.json de MCP: un artefacto auto-descriptivo que máquinas y humanos pueden consumir. Un host puede mostrar la card al usuario durante el flujo de conexión — "este servidor dice que puede acceder a tu workspace de Linear, leerá tickets pero no los borrará, lo opera Linear, usa OAuth" — y el usuario puede decidir si la afirmación le resulta aceptable. Las cards en su forma sin firmar son afirmaciones, no pruebas. La mitigación es la atestación firmada, con un modelo de firma que ha convergido al estilo sigstore con OIDC: una card firmada vía la integración OIDC de GitHub bajo github.com/some-org/mcp-server puede verificarla cualquier host que confíe en las afirmaciones de identidad de GitHub. Los hosts pueden poner política encima — confiar sólo en cards firmadas, sólo en cards firmadas por un proveedor concreto, sólo en las que no estén en una lista de revocación.

El flujo se parece a añadir una red Wi-Fi. Una vez. El host guarda la configuración; las sesiones siguientes saltan el descubrimiento. Lo que "algo ha cambiado" significa en la práctica — saltos de versión, ampliaciones de ámbito, cambios de capacidad — debería disparar consentimiento renovado, como hace un cambio de certificado TLS. Los hosts que se saltan este paso permiten a los servidores ampliar en silencio su alcance con el tiempo, que es exactamente el progresivo creep de capacidades que compromete la confianza en cualquier integración de larga vida.

5.3 Las partes aburridas que deciden si llegas a producción

Tres preocupaciones operativas merecen tratamiento propio porque cada una es un sitio donde una implementación descuidada produce o integraciones rotas o agujeros de seguridad.

CORS importa en cualquier servidor MCP alcanzable desde un host basado en navegador. La tentación es poner Access-Control-Allow-Origin: * y seguir. Está mal. Combinado con auth por cookie es un desastre de CSRF; combinado con bearer tokens en localStorage es un riesgo de exfiltración de tokens. Usa una lista de orígenes permitidos por origen, y prefiere cabeceras Authorization a cookies para que el mismo-origen no sea tu única línea de defensa.

La validación de Origin es CORS aplicado del lado del servidor, porque los clientes no-navegador no aplican nada. El fallo clásico: un desarrollador corre un servidor MCP en localhost:8000, visita una página web que conoce la convención, la página dispara una petición, y el servidor — sin comprobación de origen — hace lo que la página pidió. Valida Origin en cada servidor Streamable HTTP.

Las cabeceras de cacheo son la tercera. La documentación estática puede cachearse agresivamente; una fila de base de datos sólo mientras haya suscripciones cableadas; un documento en edición activa nunca. Devuelve los Cache-Control y ETag adecuados por recurso. La interacción entre cacheo y suscripciones es donde los ingenieros se llevan el mordisco — un intermediario que sirve una copia obsoleta significa que la notificación resources/updated del host nunca se dispara, porque el mecanismo de suscripción nunca llega al servidor vivo.

El rebinding de DNS redondea el barrio y afecta desproporcionadamente a los servidores locales. Bindea a 127.0.0.1, no a 0.0.0.0, valida la cabecera Host contra una lista de permitidos, exige un token de auth incluso en localhost. Un servidor MCP local sin esto está a una demo de convertirse en boletín de seguridad.

Lo que prepara el Capítulo 5

Esto cierra la Parte II del libro. Tenemos el protocolo en la mano: primitivas del servidor en el Capítulo 3, primitivas del cliente en el Capítulo 4, la capa de cable y descubrimiento aquí. Sabemos qué mensajes viajan, en qué dirección, sobre qué transporte, entre qué dominios de confianza, después de qué handshake. La Parte III pasa de primitivas a patrones. Un solo servidor conectado a un solo host es útil; la rentabilidad arquitectónica de MCP es la composición — múltiples servidores, múltiples agentes, múltiples modelos cooperando hacia objetivos mayores.

Próximamente — Capítulo 6: Estrategias fundamentales de orquestación. Cuándo un único agente bien herramentado bate a un diseño multi-agente, y las dos formas fundacionales — pipelines secuenciales y concurrencia scatter-gather — sobre las que se apoyan la mayoría de los despliegues en producción.