MCP 2026-07-28 detrás de balanceadores HTTP: enrutamiento y ámbito seguro de la caché

Qué es

Estado al 25 de octubre de 2026. MCP 2026-07-28 permite que cada solicitud HTTP incluya el contexto necesario para procesarla de forma independiente. Volver a consultar las especificaciones de Streamable HTTP, caché y herramientas correspondientes a esa versión antes de cambiar las reglas de la pasarela. El balanceo de carga ordinario y el almacenamiento correcto de resultados en caché son decisiones de despliegue independientes.

El núcleo ya no requiere sesiones de transporte. El estado de la aplicación que abarque varias solicitudes sigue necesitando identificadores explícitos y un almacenamiento adecuado. Una solicitud también puede tener una respuesta en streaming; la ausencia de estado no hace que todas las conexiones sean breves.

Por qué importa

RFC 9111 define las claves habituales de la caché HTTP a partir del método HTTP y la URI de destino, con variaciones adicionales donde se especifique. Las operaciones MCP comparten un endpoint POST, mientras que su método y sus parámetros se encuentran dentro del JSON. De ello se deduce que una caché genérica cuya única clave sea /mcp no puede distinguir esas operaciones de forma segura. El campo JSON ttlMs no es una cabecera HTTP Cache-Control ni configura automáticamente un proxy.

Las listas de herramientas pueden variar según la autorización, aunque no deben hacerlo por el historial de conexiones. Se recomienda un orden determinista cuando el conjunto disponible no cambie. Ninguna de estas propiedades convierte en público un catálogo filtrado por permisos.

Cómo aplicarlo

• Conservar y validar los metadatos de enrutamiento. Reenviar MCP-Protocol-Version y Mcp-Method; Mcp-Name es obligatorio para tools/call, resources/read y prompts/get. Los servidores que procesen el cuerpo deben rechazar las discrepancias o la ausencia de cabeceras obligatorias con HTTP 400 y HeaderMismatch (-32020). Decodificar los nombres con la codificación especificada antes de compararlos. No confiar en estas cabeceras que reflejan el cuerpo en una vía anterior que carezca del requisito de validación correspondiente.
• Excluir las entradas sensibles de las cabeceras de enrutamiento. Los esquemas de herramientas pueden exponer parámetros mediante x-mcp-header; la especificación de herramientas desaconseja marcar contraseñas, tokens o datos personales porque los intermediarios pueden verlos. Enrutar con los metadatos permitidos y mantener la autorización en el punto de ejecución.
• Conservar el streaming. Admitir respuestas JSON y SSE, desactivar el almacenamiento intermedio de respuestas cuando no sea adecuado y comprobar el comportamiento de los tiempos de espera por inactividad. El transporte recomienda X-Accel-Buffering: no para SSE y comentarios de mantenimiento de conexión para flujos de larga duración. No configurar la reanudación mediante Last-Event-ID para esta revisión ni almacenar en caché flujos de suscripción.
• Limitar los resultados que pueden almacenarse. Las indicaciones de caché son obligatorias en los resultados completos de descubrimiento, listas de herramientas, listas de prompts, listas de recursos, listas de plantillas de recursos y lecturas de recursos. Los resultados intermedios input_required y las solicitudes que incluyan inputResponses o requestState no deben almacenarse en caché. No deducir que la ejecución de una herramienta puede almacenarse en caché solo porque su descripción indique que es de solo lectura.
• Aplicar por separado la vigencia y el aislamiento. ttlMs mide milisegundos desde la recepción; cero significa que el resultado queda obsoleto de inmediato. Las notificaciones de cambios pertinentes invalidan las entradas aún vigentes. public permite compartir únicamente datos que no sean específicos de un usuario; private restringe la reutilización al mismo contexto de autorización, lo que incluye una caché separada para un token distinto. Crear las claves de las entradas a partir del servidor, el protocolo, el método y los parámetros que afecten al resultado; mantener separadas las páginas de la paginación.
• Almacenar resultados en caché, no envoltorios de respuesta obsoletos. Un intermediario que entienda MCP debe devolver el ID JSON-RPC de la solicitud actual. Conservar el momento de caducidad original en lugar de renovarlo cuando haya un acierto de caché. En un proxy HTTP ordinario, mantener desactivada la caché de POST salvo que su comportamiento para MCP esté implementado y verificado expresamente. Cuando deba prohibirse el almacenamiento, utilizar la directiva HTTP no-store además de la política de la aplicación; private por sí sola permite el almacenamiento en una caché privada.
• Verificar con identidades de prueba aisladas. Comprobaciones propuestas en preproducción: alternar instancias, obtener la misma lista con permisos distintos, modificar un catálogo, dejar caducar una entrada y reutilizar un resultado apto para caché con un ID de solicitud diferente. Confirmar que el flujo se entrega a tiempo y que no se reutilizan resultados entre usuarios.

Trampas

TTL es una indicación de vigencia, no una garantía de que los datos no puedan cambiar. Enrutar mediante una cabecera no equivale a autenticar. Una solicitud balanceada correctamente no demuestra que sea seguro reintentar acciones con efectos secundarios. Mantener explícitas estas decisiones de la aplicación al habilitar optimizaciones de infraestructura.