MCP sin estado: Escalado de servidores sin sesiones ni intercambios de datos

Un servidor de Protocolo de Contexto de Modelo que funciona sin problemas en una sola máquina puede comenzar a fallar en cuanto se ejecutan tres copias detrás de un balanceador de carga, ya que cada instancia solo recuerda las sesiones que creó ella misma. El enfoque del protocolo hacia un núcleo sin estado está dirigido precisamente a ese problema. Este artículo explica qué cambia cuando desaparecen las sesiones y el proceso de inicialización, cómo las solicitudes transportan su propio contexto en su lugar, y cómo las interacciones múltiples, el enrutamiento basado en encabezados, las listas cachebillables y las tareas en segundo plano se integran en el nuevo modelo, para que pueda evaluar su impacto en los servidores y gateways que utiliza.

Una nota sobre el momento oportuno: el diseño sin estado descrito aquí corresponde a la revisión de 2026 del protocolo. Detalles como los nombres exactos de los métodos, los nombres de las cabeceras y los tipos de resultados aún pueden cambiar, por lo que confírvelos contra la especificación actual de MCP antes de utilizarlos en el código. Si necesita repasar los conceptos básicos sobre cómo los clientes MCP descubren e invocan herramientas, la introducción del blog a cómo el Protocolo de Contexto del Modelo permite a los agentes descubrir e invocar herramientas aborda ese tema.

Qué significa “estado” aquí

Un sistema es con estado cuando debe recordar algo entre solicitudes para poder manejar la siguiente. Un pedido de entrega de comida es un buen ejemplo cotidiano: pasa de estar aceptado, a estar en preparación, a estar listo para ser entregado, hasta finalmente ser entregado, y el servicio debe hacer un seguimiento de la etapa en la que se encuentra cada pedido para poder responder “¿Dónde está mi comida?” en cualquier momento.

Las versiones anteriores de MCP funcionaban de la misma manera a nivel de conexión. Cuando un cliente (la aplicación de IA) se conectaba por primera vez a un servidor, ambos realizaban un proceso de inicialización. Luego el servidor emitía un identificador de sesión, por ejemplo abc123, y el cliente lo adjuntaba a cada solicitud posterior para que el servidor pudiera asociar cada llamada con lo que había ocurrido anteriormente en la conversación, incluidas las capacidades acordadas por ambas partes.

Por qué las sesiones se rompen con la escalabilidad horizontal

Con una sola instancia de servidor y un tráfico moderado, ese diseño es perfectamente adecuado. Los problemas comienzan cuando la carga aumenta y se añaden instancias detrás de un balanceador de cargas:

1. El cliente de un usuario envía su primera solicitud, por ejemplo pidiendo la lista de herramientas. El balanceador de cargas la envía al Servidor 1, que crea la sesión abc123.
2. Ese mismo cliente envía una segunda solicitud, por ejemplo llamando a la herramienta meteorológica. Esta vez el balanceador de cargas elige al Servidor 2.
3. El Servidor 2 nunca ha oído hablar de abc123. No posee ningún estado en memoria del Servidor 1, por lo que la solicitud falla.

Los sistemas con estado tienen dos soluciones habituales. Las sesiones pegajosas fijan a cada cliente a una instancia específica, lo que perjudica incluso la distribución de carga y complica el proceso de conmutación por fallo. Como alternativa, un almacén compartido como Redis alberga los datos de las sesiones que todas las instancias pueden leer. Eso funciona, pero añade otro componente de infraestructura que hay que operar, proteger y mantener disponible, además de una búsqueda en la red en cada llamada, todo ello únicamente para mantener el registro del protocolo.

El modelo sin estado

La revisión de 2026 sigue un enfoque diferente: convierte a MCP en un protocolo de solicitud-respuesta sin estado y elimina las sesiones. Cada solicitud funciona de forma independiente y no depende de nada que el servidor recuerde de una anterior. Al no haber memoria por cliente en el servidor, cualquier instancia puede responder a cualquier solicitud, y la escalabilidad se logra simplemente añadiendo instancias detrás de un balanceador de carga ordinario.

Eso no significa que su aplicación no pueda tener ningún estado en absoluto. Una herramienta que gestiona un carrito de compras o la edición de un documento largo aún necesita datos en algún lugar. La diferencia es que dicho estado se convierte en datos de la aplicación explícitos, almacenados donde usted elija y referenciados mediante identificadores en la solicitud, en lugar de ser un estado de protocolo implícito vinculado a una conexión.

Cómo una solicitud lleva consigo su propio contexto

Incluso sin un intercambio inicial de datos ni un ID de sesión, el servidor aún necesita saber qué versión del protocolo utiliza el cliente, quién es el cliente y qué puede hacer. La respuesta es que cada solicitud trae consigo esta información.

El objeto _meta

Los datos de las solicitudes incluyen un objeto opcional _meta para estos metadatos. Puede contener:

• La versión del protocolo, para que el servidor sepa cómo interpretar el mensaje.

La identidad del cliente, como el nombre y la versión de una aplicación, por ejemplo MyAIApp v1.0.

Las capacidades del cliente, para que el servidor sepa qué funciones puede utilizar en su respuesta.

Dado que el contexto llega dentro de la solicitud, el servidor puede procesarlo de inmediato, sin necesidad de consultar una tabla de sesiones. La desventaja es que cada llamada tiene un volumen de datos ligeramente mayor, lo cual suele ser insignificante en comparación con el costo de un almacén de sesiones compartido.

Interacciones múltiples sin conexión abierta

Los diseños con estado facilitan las comunicaciones bidireccionales: si el servidor necesita más información, puede solicitarla a través de la conexión ya abierta. Por ejemplo, un usuario que desea reservar un vuelo a Delhi pero olvida mencionar la fecha. Un servidor con estado podría simplemente pedir la fecha y esperar la respuesta por la misma conexión.

Un protocolo sin estado no puede mantener conexiones abiertas con ese propósito, por lo que MCP define en su lugar un flujo estructurado de múltiples rondas:

1. Cuando un servidor recibe una solicitud que carece de parámetros esenciales, devuelve un resultado específico input required en lugar de fallar o esperar.
2. La aplicación cliente solicita al usuario los detalles faltantes.
3. El cliente coloca las respuestas en un objeto input responses y envía una nueva solicitud completamente independiente que el servidor puede completar.

Dado que la segunda solicitud contiene todo lo necesario, puede llegar a cualquier instancia del servidor. El servidor no tiene que recordar que realizó una consulta; el cliente se encarga de continuar con el proceso. Si el servidor necesita correlacionar las dos solicitudes (por ejemplo, para evitar repetir tareas costosas), puede devolver un token opaco que el cliente debe reenviar, en lugar de mantener memoria oculta.

Ruteo mediante encabezados en lugar de cuerpos

Este cambio hacia un modelo sin estado también abre la puerta a mejoras en el rendimiento y las operaciones. Dos cambios destacan: el ruteo basado en encabezados y los resultados de listas que se pueden cachear.

Detalles del protocolo en los encabezados HTTP

Anteriormente, la infraestructura frente a un servidor MCP, como una pasarela de API, un firewall para aplicaciones web o un balanceador de carga, tenía que analizar el cuerpo JSON de cada solicitud solo para determinar qué método o herramienta se estaba invocando. Analizar los cuerpos de las solicitudes en el extremo consume recursos del procesador, aumenta la latencia y resulta complicado de configurar en muchas pasarelas.

Bajo las nuevas reglas, las solicitudes HTTP deben exponer información clave del protocolo en los encabezados:

• MCP-Method, por ejemplo tools/call;
• MCP-Name, el nombre de la herramienta específica que se está llamando.

Una pasarela puede leer estos encabezados y enrutar, limitar la tasa o bloquear el tráfico sin tocar la carga útil. Eso permite expresar políticas comunes de manera sencilla, como enviar herramientas costosas a un grupo dedicado de instancias, aplicar un límite de tasa más estricto a una herramienta o bloquear completamente una herramienta durante un incidente. Como siempre ocurre con los encabezados, el servidor debe seguir validando que coincidan con el cuerpo de la solicitud, para que un cliente no pueda eludir una política enviando un encabezado engañoso.

Listas de herramientas y comandos cachebillables

Los clientes hacen constantemente a los servidores las mismas preguntas: ¿qué herramientas están disponibles? ¿Qué comandos son compatibles? Con miles de usuarios, un servidor puede dedicar una proporción sorprendente de su capacidad a responder a esas solicitudes idénticas.

Las listas de herramientas y prompts cambian rara vez, por lo que la nueva versión permite almacenar en caché los resultados de las listas. Un cliente puede obtener la lista de herramientas una vez, guardarla en memoria y reutilizarla para solicitudes posteriores en lugar de pedirla nuevamente. La misma característica permite que la infraestructura compartida, como una pasarela o un caché HTTP frente a los servidores, responda a solicitudes repetidas de listas para muchos clientes al mismo tiempo. De cualquier manera, llegan mucho menos solicitudes al servidor. Al igual que con cualquier caché, se necesita una forma de invalidarlo cuando un despliegue modifica la lista; por lo tanto, planifique su vencimiento o uso de versiones en lugar de almacenarlo en caché indefinidamente.

Trabajo de larga duración con tareas en segundo plano

Algunas herramientas responden en milisegundos, como una consulta meteorológica. Otras no: pedirle a un asistente que analice 10,000 documentos podría tomar veinte minutos. En un ciclo simple de solicitud-respuesta, el cliente tendría que mantener la conexión abierta durante todo ese tiempo, ocupando recursos en ambos extremos y dejando a la interfaz de usuario atascada esperando.

Para abordar esto, la revisión de 2026 incluye un marco de trabajo para tareas rediseñado:

1. Creación. Cuando un cliente activa una herramienta compleja, el servidor responde de inmediato con un identificador de tarea, por ejemplo task_abc123, y la solicitud inicial finaliza.
2. Ejecución en segundo plano. El servidor realiza el análisis en segundo plano mientras el usuario continúa utilizando otras partes de la aplicación.

Verificaciones de progreso. En cualquier momento, el cliente puede solicitar el estado y los resultados de la tarea mediante una llamada Task Get.

Entradas actualizadas. Si el trabajo necesita más información durante su ejecución, el cliente la proporciona con Task Update.

Se trata del conocido patrón de tareas asíncronas de las APIs web, aplicado a MCP. Esto mantiene a las aplicaciones receptivas independientemente de lo intensivo que sea el trabajo. En un despliegue con múltiples instancias, recuerde que el estado de la tarea debe almacenarse en un lugar al que todas las instancias puedan acceder, ya que la llamada Task Get puede llegar a un servidor diferente al que creó la tarea. El protocolo ya no requiere un estado de sesión compartido, pero seguir siendo responsable del almacenamiento duradero de las tareas.

Qué significa esto para sus servidores

Si opera o desarrolla servidores MCP, la lista de verificación práctica es la siguiente:

• Elimine la memoria oculta por conexión. Todo lo que una herramienta necesite entre llamadas debe almacenarse de forma explícita, identificado por los códigos que envía el cliente.
• Lea el contexto de cada solicitud. Obtenga la versión del protocolo, la identidad y las capacidades del cliente desde _meta, no de una sesión.
• Diseñe las herramientas para que pregunten en lugar de esperar. Devuelva un resultado que requiera entrada cuando falten parámetros y espere las respuestas en una nueva solicitud.
• Utilice los encabezados de enrutamiento en el extremo. Configure las pasarelas para enrutar y limitar según MCP-Method y MCP-Name, y válidelos en relación con el cuerpo de la solicitud en el servidor.

Listas de caché y planificación de invalidación. Permite que los clientes y las pasarelas almacenen en caché las listas de herramientas y comandos, con una forma clara de actualizarlas después de las implementaciones.

Mover herramientas lentas a tareas. Devolver rápidamente un ID de tarea y mantener el estado de la tarea en un almacén compartido por todas las instancias.

Puntos clave

• La revisión sin estado reemplaza el diseño basado en sesiones de MCP por llamadas independientes de solicitud-respuesta, eliminando la necesidad de sesiones persistentes o un almacén de sesiones compartido solo para escalar.
• Los códigos de handshake y los IDs de sesión han desaparecido; cada solicitud lleva consigo su versión de protocolo, la identidad del cliente y sus capacidades en _meta.
• La información faltante se maneja con un resultado input required y una solicitud posterior que contiene input responses, en lugar de mantener una conexión abierta.
• MCP-Method y MCP-Name permiten a las pasarelas enrutar, limitar la tasa de uso y bloquear tráfico sin tener que analizar los cuerpos en formato JSON.
• Las listas estables de herramientas, instrucciones y recursos pueden guardarse en caché, reduciendo la carga repetitiva en los servidores.
• Las herramientas que ejecutan tareas prolongadas devuelven un ID de tarea de inmediato, y los clientes realizan consultas adicionales mediante Task Get y Task Update.
• El enfoque sin estado traslada el estado en lugar de eliminarlo: los datos de la aplicación y el progreso de las tareas siguen necesitando un almacenamiento duradero al que pueda acceder cada instancia. Verifique los nombres exactos según la especificación actual antes de utilizarlos.

Lecturas relacionadas

• Cómo el Protocolo de Contexto del Modelo permite a los agentes de IA descubrir y llamar herramientas — Una explicación clara de MCP: cómo los hosts, clientes y servidores permiten que una aplicación de IA descubra herramientas, las llame con entradas estructuradas y entienda cuáles son sus limitaciones.
• Diseñando interfaces de herramientas eficientes en tokens para servidores MCP agenciales — Aprenda cómo reducir docenas de definiciones de herramientas MCP a un número limitado de herramientas enfocadas en un dominio específico y organizadas por acciones, sin perder ninguna funcionalidad subyacente.