¿Por qué le importa a un servidor de herramientas de IA tener un núcleo de protocolo sin estado, si nunca lo pensaste para escalar?
La versión candidata del 28 de julio de 2026 del Model Context Protocol saca las sesiones de protocolo del centro de Streamable HTTP. Las notas de la versión describen un núcleo sin estado que escala sobre infraestructura HTTP normal: una solicitud lleva lo necesario para enrutarla, así que un servidor puede vivir detrás de un balanceador de carga común sin necesitar un almacén de sesiones pegajosas que recuerde con qué proceso habló cada cliente. Eso no vuelve sin estado a toda aplicación construida sobre MCP. Vuelve más fácil de escalar, reintentar y observar la capa de protocolo.
Este artículo revisa las notas oficiales de la versión y la guía de migración del SDK, consultadas el 22 de septiembre de 2026. No presenta la operación de un servidor MCP a gran escala.
Qué salió del núcleo del protocolo
Antes de esta revisión, un cliente y un servidor MCP podían construir afinidad entre sí: un identificador de sesión, un saludo inicial o un mensaje que el servidor enviaba sin que se lo pidieran, todo atado a una conexión. El núcleo sin estado elimina esa suposición de la capa de protocolo. Un servidor ahora puede ser uno más entre varios procesos intercambiables detrás de un balanceador, y una conexión caída ya no tiene por qué significar una sesión rota. La versión también describe metadatos de caché, encabezados de operación y contexto de trazas, que importan cuando intentas seguir una misma llamada lógica a través de varios servicios en lugar de un único socket de larga duración.
Sin estado no significa sin datos
La distinción es práctica. Un servidor puede seguir guardando estado de negocio en una base de datos, una cola o una caché. Lo que debería dejar de hacer es depender de que un proceso específico recuerde que un cliente le habló hace cinco segundos. Mueve esa suposición a un almacén que puedas inspeccionar, replicar y recuperar ante fallos, y la solicitud misma se vuelve más fácil de reintentar, cachear y rastrear, sin importar qué instancia del servidor la atendió.
Qué exige realmente una migración
Quitar la afinidad de sesión no sale gratis para las integraciones existentes. Un código que dependía de un saludo inicial, un identificador de sesión o un mensaje que el servidor enviaba sin ser solicitado puede comportarse distinto en cuanto el transporte deja de garantizar que el mismo proceso atienda cada solicitud. La guía de migración del SDK de TypeScript documenta requisitos de autorización específicos de esta revisión junto con el cambio de transporte. Lo trataría como una matriz de versiones: qué versión de cliente, qué revisión de servidor y qué suposiciones de transporte se sostenían realmente antes de tocar nada. Prueba el transporte de forma aislada antes de tocar la lógica de negocio construida encima.
Por qué quitar la afinidad es la mejora más grande
Es tentador leer las actualizaciones de un protocolo solo buscando funciones nuevas. Aquí, quitar una dependencia oculta es probablemente el cambio más importante. Un núcleo sin estado convierte una integración local ingeniosa, afinada para un solo proceso y una sola conexión, en algo que puede sobrevivir a una segunda instancia, una solicitud fallida y una traza que alguien pueda seguir después de que ocurrió el problema. Es un titular más pequeño que una función nueva, y un cambio más grande para quien tenga que operar eso en producción.
Sigue el RSS en español para leer el próximo artículo.
Sobre el autor: conoce mi portfolio y mi agencia, Bimbi Digital.