MCP se vuelve stateless: por fin puedes escalar servidores remotos sin arrastrar la sesión

Qué ha pasado de verdad

El 28 de julio de 2026 Anthropic soltó MCP 2026-07-28. No es un parche cosmético ni un changelog de “mejoras de estabilidad”. Es la mayor actualización del protocolo desde que salió, y el cambio central es brutal de simple de enunciar:

MCP se vuelve stateless. Sin estado.

Hasta ahora, montar un servidor MCP remoto te obligaba a gestionar estado de sesión. Esa frase suena a detalle de backend aburrido. No lo es. Es la diferencia entre un servicio que puedes clonar y matar como un animal de granja y un bicho al que tienes que atar con cinta adhesiva a una máquina concreta.

La fuente del anuncio es pública (ClaudeDevs en X): al quitar esa dependencia de sesión, el despliegue de servidores remotos se simplifica y se abre la puerta a infraestructura serverless y edge, y a escalar en horizontal detrás de cualquier balanceador de carga.

Eso no es marketing de “cloud-native”. Es arquitectura. Y si trabajas con agentes, tools o bridges hacia APIs reales, es el tipo de cambio que te cambia el diagrama de despliegue, no el PowerPoint.

Además del salto a sin estado, la versión mete extensiones como ciudadanos de primera clase: una vía formal para estirar el protocolo. En el anuncio aparecen MCP Apps (interfaces en iframe), Tasks (operaciones asíncronas) y Enterprise Managed Auth (acceso centralizado vía proveedor de identidad). También hay refuerzo de autenticación y una política de deprecación formal. Todo eso importa. Pero el eje que mueve el resto es el stateless.

Por qué el estado de sesión te tenía agarrado del cuello

Imagina un camarero que solo entiende tu pedido si se acuerda de la mesa 7 y de lo que pediste hace veinte minutos. Si ese camarero se va a fumar, el siguiente no sabe quién eres. Tienes dos opciones de mierda: o obligas a que siempre te atienda el mismo, o montas un sistema paralelo para copiarle la memoria al sustituto.

Eso es, a grandes rasgos, un protocolo con estado de sesión en el servidor.

En la práctica, cuando el servidor “recuerda” la sesión:

• El balanceador de carga no puede repartir a ciegas. Tiene que hacer sticky sessions (siempre al mismo nodo) o tienes que compartir sesión entre nodos.
• Compartir sesión significa Redis, almacenamiento distribuido, locks, caducidades, inconsistencias y un festín de fallos a las 3 de la madrugada.
• Serverless se vuelve hostil. Una función Lambda o un worker efímero no está diseñado para “acordarse” de ti entre invocaciones sin que tú externalices ese recuerdo.
• El edge se complica: cuanto más cerca del usuario pongas la lógica, menos sentido tiene arrastrar una sesión gorda y pegajosa.

Antes de MCP 2026-07-28, ejecutar un servidor MCP remoto te metía en ese saco: había que gestionar estado de sesión y eso limitaba las ubicaciones de despliegue. No porque a nadie se le ocurriera poner el servidor en mil sitios, sino porque el modelo de ejecución te castigaba si lo intentabas.

El anuncio no detalla el mecanismo exacto de cómo se guardaba esa sesión ni cómo se borra byte a byte en el nuevo modelo. No vamos a inventar el diseño interno. Lo que sí consta es el efecto: al pasar a stateless, desaparece ese freno estructural al despliegue remoto flexible.

Sin estado es la condición que desbloquea el escalado horizontal

Aquí va la tesis de ingeniería, sin romanticismo:

No escalas en horizontal de verdad mientras cada petición dependa de memoria local de un proceso concreto.

Escalado horizontal significa: metes más réplicas del mismo servicio detrás de un balanceador y el sistema aguanta más carga. Suena a manual de primer año. El truco es la condición previa que casi nadie escribe en grande:

Si la réplica N no puede atender la petición que iba a la réplica M sin pedir prestado un secreto compartido, no tienes N réplicas. Tienes una granja de monólogos mal avenidos.

Sin estado en el servidor de protocolo, cada request (o cada unidad de trabajo bien delimitada) lleva lo que necesita o lo recupera de un almacén externo explícito. El proceso en sí es intercambiable. Nace, muere, se multiplica. El balanceador no tiene que “conocer” a nadie. El autoscaling no llora. El deploy blue/green no te deja sesiones huérfanas colgando como carne en el gancho.

Eso es lo que desbloquea MCP al volverse stateless. No es que de repente “vaya más rápido” (no hay métricas públicas en el anuncio que comparen latencia o coste antes/después, así que no vamos a fabricar un 40% mágico). Es que cambia el espacio de diseños posibles:

1. N instancias idénticas detrás de un load balancer clásico (round-robin, least-conn, lo que sea).
2. Serverless: invocaciones efímeras sin tener que reconstruir teatro de sesión en cada cold start solo para no romper el protocolo.
3. Edge: lógica cerca del usuario sin arrastrar afinidad de sesión como si fuera un mainframe con zapatos deportivos.

El orden importa. Primero quitas el estado del camino crítico del protocolo. Luego el escalado deja de ser un proyecto de plataforma y vuelve a ser un slider de réplicas.

HTTP stateless y GET que no muta: por qué encaja con MCP

MCP no vive en el vacío. Habla el idioma de la web moderna: clientes, servidores, tools, recursos, transporte. Y la web aprendió a hostias una lección hace décadas.

HTTP, en su modelo mental sano, es stateless: el servidor no necesita recordar la petición anterior para entender la de ahora. La autenticación, los tokens, los ids de recurso viajan con la request o se resuelven contra un store. Por eso puedes poner CDNs, caches y granjas enormes sin que cada front se case con un backend de por vida.

Encima está la semántica de métodos:

• GET no debe mutar. Lees. No “lees y de paso borras la base de datos”.
• Las operaciones que cambian algo se marcan como lo que son (POST, PUT, PATCH, DELETE), con las expectativas de reintentos, idempotencia y caché que eso implica.

¿Qué tiene que ver con MCP? Mucho, si dejas de pensar en el protocolo como un chat mágico y lo miras como un contrato de herramientas y recursos.

Cuando el bridge agente ↔ tools se parece a un túnel con memoria oculta en el servidor, cada tool call es un poco ruleta: ¿depende de lo que pasó hace tres turnos en esta sesión invisible? ¿Si reintento, duplico el cargo? ¿Si el nodo muere a mitad, recupero el hilo o empiezo de cero con cara de tonto?

Un MCP stateless empuja el diseño hacia lo que HTTP ya premiaba:

• La unidad de trabajo se explica sola. Lo que el servidor necesita para ejecutar la tool está en la petición, en un recurso direccionable o en un backend de datos con nombre y apellidos (no en la RAM sentimental del proceso).
• Los reintentos dejan de ser terrorismo. Si una lectura no muta, repetirla no te funde el mundo. Si una escritura es explícita y, cuando toca, idempotente, el cliente puede recuperarse sin adivinar.
• El cliente (el host del agente) se convierte en el lugar natural del hilo conversacional. El historial del agente, el plan, el scratchpad: eso puede vivir donde ya vivía el contexto del modelo. El servidor MCP aporta capacidades, no una segunda memoria paralela mal documentada.

No estamos diciendo que MCP “sea HTTP” ni que todo sea REST de manual. Estamos diciendo que la condición stateless alinea el protocolo con el único modelo de despliegue que ha demostrado escalar en internet sin magia negra. GET que no muta, requests autónomas, servidores intercambiables: es el mismo esqueleto conceptual.

Si montas agentes en producción y aún diseñas tools como si fueran métodos de un objeto en memoria con this eterno, el protocolo te va a dejar de tapar las vergüenzas. Bien.

Qué cambia en el diagrama de producción

Olvida un momento las demos de “miro el calendario con el agente”. Piensa en un equipo que tiene que mantener MCP remoto en serio: varias tools, credenciales, auditoría, picos de carga, varias regiones.

Antes (con estado de sesión como freno)

El camino típico era más estrecho:

• Pocas instancias “gordas” o sticky sessions sí o sí.
• Miedo razonable a poner el servidor en un runtime que se duerme o se recrea.
• Operaciones de deploy coordinadas para no romper sesiones vivas.
• Observabilidad enredada: el bug no está en la request 47, está en “la sesión de esta mañana después del tercer tool call”.

Después (stateless como premisa)

El anuncio abre, de forma explícita, un mapa distinto:

• Despliegue en infraestructura serverless y edge.
• Escalado horizontal detrás de cualquier balanceador de carga.
• Réplicas que puedes matar en un rolling update sin montar un funeral por la sesión.

Eso no significa que el estado desaparezca del universo. Significa que deja de esconderse dentro del protocolo como pegamento invisible. Si necesitas memoria de negocio (el carrito, el workflow, el job id), la pones en una base de datos, una cola, un object store. Sitios donde ya sabes hacer backups, TTL, permisos y métricas.

La distinción es de adultos:

Dónde vivía el “recuerdo”	Qué implica en producción
Sesión en el proceso MCP	Afinidad, sticky, réplicas miedosas
Estado de negocio en store externo	Réplicas tontas, escalado limpio
Contexto del agente en el host	El modelo sigue el hilo; el tool no improvisa memoria

MCP stateless empuja de la primera fila a las otras dos. Eso es higiene, no dogma.

Extensiones, Tasks y Apps: útiles, pero no te comas el anuncio crudo

La actualización no solo dice “somos stateless” y se va a casa. Introduce extensiones como ciudadanos de primera clase: una vía formal para extender el protocolo sin convertir cada idea en un fork pirata.

En el paquete del anuncio aparecen:

• MCP Apps (UIs en iframe). O sea, no solo tools de texto: superficies de interfaz embebidas.
• Tasks (operaciones asíncronas). El reconocimiento de que no todo es request/response de milisegundos; hay trabajos largos.
• Enterprise Managed Auth (acceso centralizado vía proveedor de identidad). La empresa quiere SSO y control, no API keys en un Notion.

También hay auth hardening (refuerzo de autenticación) y una política de deprecación formal. Esto último es más importante de lo que parece: un protocolo sin deprecación clara es un cementerio de flags eternos y clientes zombi.

Ahora el jarro de agua fría, porque aquí se escribe con datos y no con brochure:

• No consta en el material que Tasks y MCP Apps sean productos cerrados “ya en producción” como suite acabada. Son piezas del anuncio de protocolo / extensiones. Trátalas como capacidad que el estándar abre, no como botón mágico que ya te resuelve el roadmap.
• No vamos a atribuir ahorros de coste ni subidas de throughput: el anuncio no trae esos números.
• No afirmamos compatibilidad total hacia atrás con servidores que vivían del estado de sesión: no está especificado en lo que tenemos. Si tu implementación actual chupaba sesión como un vampiro, tendrás que leer la especificación y probar. Punto.

El criterio editorial es simple: el cambio stateless es el que reordena infraestructura. Las extensiones son el menú de lo que podrás construir encima cuando el transporte ya no te obligue a ser monógamo con una instancia.

La trampa clásica: “stateless” no significa “sin memoria en el sistema”

Cada vez que alguien dice stateless, aparece un listillo diciendo que entonces no puedes tener usuarios logueados ni workflows. Es confusión interesada o ignorancia con micrófono.

Stateless en el servidor de protocolo quiere decir:

• No guardo en la RAM del proceso el significado de tu conversación de tools como condición para entender la siguiente llamada.
• Cualquier réplica sana puede atenderte si la request está bien formada y los backends responden.

No quiere decir:

• Que no exista autenticación (de hecho, esta versión endurece auth y suma gestión enterprise).
• Que no existan jobs largos (por eso existen abstracciones tipo Tasks en el mapa de extensiones).
• Que el agente no tenga contexto (el contexto del LLM es otro problema; si te pisan el contexto entre agentes, eso es orquestación y memoria de datos, no magia del bridge).

Si confundes las capas, tomas decisiones de mierda: o intentas meter el historial entero en el servidor MCP “porque total”, o intentas que el balanceador compense un diseño stateful a base de sticky sessions eternas.

La regla limpia de producción:

1. Protocolo y transporte (lo más tontos y sin estado posible).
2. Datos de negocio y jobs (con identidad estable, ids, stores y colas).
3. Contexto del modelo / agente (gobernado donde orquestas el razonamiento, no escondido en la tool).

MCP 2026-07-28 empuja el punto 1 a donde tenía que estar. Los puntos 2 y 3 siguen siendo trabajo tuyo. El protocolo no te va a hacer el diseño de dominio.

Cómo encaja con agentes reales (y con el caos de tools HTTP)

Los agentes en producción no fallan solo porque el modelo “no razona”. Fallan porque las tools son un oeste: side effects opacos, auth repartida, timeouts, reintentos que duplican pedidos, y servidores que solo funcionan si “la sesión sigue caliente”.

Un protocolo de contexto de modelo que se alinea con HTTP sin estado y con operaciones de lectura no mutantes te da un lenguaje común para dejar de improvisar:

• Las tools de consulta pueden comportarse como lecturas: cacheables en espíritu, repetibles, aburridas en el mejor sentido.
• Las tools de acción se diseñan como acciones: explícitas, auditables, con idempotency keys cuando el dinero o los tickets están en juego.
• El servidor remoto deja de ser un proceso consentido y pasa a ser un servicio.

Eso conecta con una obsesión sana de este medio: los agentes necesitan fronteras claras. Si estás montando orquestación seria, ya sabes que el contexto se pisa y los tokens se funden cuando mezclas memoria, plan y side effects en el mismo cubo. Un MCP stateless no te resuelve la orquestación sola, pero te quita una excusa para esconder estado en el sitio peor.

Y si tu mundo es más “tools HTTP con disfraces” que agentes filosóficos, el mensaje es el mismo: el disfraz bonito no compensa un servidor que no puedes clonar.

Qué haría un equipo con el culo pelado en producción esta semana

Sin inventar benchmarks ni prometer migraciones de un clic, el checklist adulto se escribe solo.

1. Inventaría dónde dependes de sesión.
Si tu servidor MCP remoto asume memoria de proceso entre llamadas, márcalo en rojo. Ese es el acoplamiento que el protocolo ya no te va a maquillar con la misma cara.

2. Separa lectura y mutación en el diseño de tools.
Aunque el transporte interno sea el que sea, mentalmente aplica la disciplina de GET-no-muta: lo que solo consulta no debe colar escrituras “por comodidad”.

3. Externaliza el estado que sí es de negocio.
Job ids, aprobaciones humanas, borradores, cursors de páginas grandes: fuera del proceso. Con nombre, TTL y dueño.

4. Pon el servidor detrás de un balanceador como si las réplicas fueran ganado.
El anuncio habilita explícitamente el escalado horizontal detrás de cualquier load balancer. Si sigues desplegando una sola instancia “porque siempre se hizo así”, el cuello de botella eres tú.

5. No te fíes del powerpoint de extensiones para el trimestre.
Apps, Tasks y Enterprise Managed Auth son el mapa de expansión. Evalúalos con pruebas, no con hype. El auth endurecido y la deprecación formal sí te importan desde el día cero si expones MCP fuera de tu laptop.

6. Mide tu realidad, no la del anuncio.
Como no hay cifras oficiales de escalado comparativo en el material, la única comparación que cuenta es la tuya: cold starts, error rate en rolling deploys, % de llamadas que exigían afinidad, tiempo de recuperar un nodo muerto. Si no lo mides, vas a jurar que “stateless se nota” por fe. La fe no pagina a las 4 a.m.

Lo que no sabemos (y conviene decir en voz alta)

Transparencia, que para humo ya están los demás:

• El material disponible es esencialmente el anuncio (con un eco de actualizaciones de Claude Code en el entorno). No estamos citando aquí una lectura línea a línea de toda la especificación publicada en blog largo.
• No está detallado el antes/después mecánico del estado de sesión a nivel de campos y lifetimes.
• No hay métricas públicas de rendimiento o coste ligadas al cambio.
• No está zanjada en lo que tenemos la compatibilidad con servidores existentes casados con sesión.
• No aparecen casos de uso nombrados tipo “tal patrón en AWS Lambda” como prueba oficial.

Eso no debilita el núcleo: el protocolo se mueve a stateless para facilitar despliegue y escalado remoto. Debilita solo las fantasías que le quieras colgar encima. Si alguien te vende que mañana mismo tu factura cloud se divide por tres “gracias a MCP”, que saque el Excel o que se calle.

Cierre: el protocolo madura cuando se aburre

La madurez de un protocolo no se mide en demos virales. Se mide en si puedes desplegarlo como el resto de tu infraestructura seria: réplicas, balanceadores, bordes, funciones que nacen y mueren, auth que no es un llavero caótico, deprecaciones que no te dejan tirado diez años.

MCP 2026-07-28 empuja en esa dirección. El titular no es “Anthropic innova con colaboraciones”. El titular es más seco y más útil:

Sin estado de sesión en el servidor, el escalado horizontal deja de ser un parche y vuelve a ser el diseño por defecto.

HTTP lo aprendió hace tiempo. Los agentes y sus tools estaban tardando. Ahora el bridge de contexto de modelo se alinea con esa ley de hierro. El resto (Apps, Tasks, auth enterprise) será tan potente como lo honestos que seáis diseñando el estado fuera del sitio donde no debía estar.

El dato manda: el 28 de julio de 2026 el protocolo dio el paso. Tu diagrama de producción, si aún depende de una sesión pegajosa para que el agente no se caiga, ya tiene fecha de caducidad conceptual.