MCP 2026-07-28: qué significa el protocolo sin estado para los despliegues de agentes B2B

Por qué este release cambia la aritmética del despliegue

El Model Context Protocol (MCP) es un estándar abierto para conectar agentes de IA con sistemas externos. El 28 de julio de 2026 se publica su mayor revisión desde el lanzamiento — un especificación final que hace que la capa de protocolo sea sin estado, introduce extensiones de primera clase y deprecia tres características que añadían complejidad sin justificar su coste en producción.

Para los equipos que despliegan servidores MCP detrás de sistemas de agentes B2B, el impacto práctico es concreto: ya no necesitas sesiones persistentes, almacenes de sesión compartidos ni balanceadores de carga con conciencia de sesión. El estado que un agente necesita a lo largo de varias llamadas a herramientas se convierte en un handle explícito — visible para el modelo, auditable en los logs y cacheable por los intermediarios. Este artículo recorre los cambios que importan para los despliegues B2B y cómo se corresponden con el patrón de módulos MCP que ya entregamos.

La capa de protocolo sin estado

El cambio principal: el handshake initialize / initialized y el header Mcp-Session-Id se eliminan. Ahora las solicitudes son autocontenidas. La versión del protocolo, la información del cliente y las capacidades viajan en _meta en cada solicitud, no en una sesión negociada que el servidor deba recordar.

Qué elimina esto en un despliegue B2B:

• Balanceadores de carga con sesiones persistentes. Los servidores MCP remotos pueden situarse detrás de balanceadores de carga round-robin simples. Cualquier instancia del servidor puede atender cualquier solicitud porque no se requiere estado del lado del servidor para interpretarla.
• Almacenes de sesión compartidos. Si hoy escalas horizontalmente, cada instancia del servidor MCP necesita acceso al mismo estado de sesión — normalmente Redis o una base de datos. El protocolo sin estado elimina esa dependencia.
• Infraestructura de reproducción de sesión. Cuando una sesión se cae a mitad de un flujo de trabajo, el cliente debe reinicializar y restablecer el contexto. El protocolo sin estado no tiene sesión que caerse; cada solicitud lleva lo que necesita.

La forma del despliegue se vuelve más simple: un grupo de instancias de servidor MCP sin estado detrás de un balanceador de carga, sin una capa de estado compartido entre ellas. Es la misma forma que cualquier API HTTP sin estado — probada en batalla, observable y barata de escalar.

El patrón de handle explícito para los flujos de trabajo con estado

Sin estado no significa que el estado desaparezca. Los flujos de trabajo que abarcan varias llamadas a herramientas — una recepción de RFQ, la negociación de una cotización, una reserva de disponibilidad — todavía necesitan continuidad. El especificación final reemplaza el estado de sesión oculto con el patrón de handle explícito: una herramienta acuña un handle (un order_id, un quote_id, un basket_id) y el modelo lo devuelve como un argumento ordinario en las llamadas posteriores.

Este es un cambio significativo para los despliegues B2B por tres razones.

El estado es visible para el modelo. Hoy, el estado de sesión vive en los metadatos de transporte que el LLM nunca ve. Con los handles explícitos, el modelo mantiene y referencia el handle en su razonamiento. Cuando el modelo llama a get_quote(quote_id="q-7f3a"), sabe sobre qué cotización está operando. Esto mejora la precisión de la selección de herramientas en los flujos de trabajo de varios pasos.

El estado es auditable en los logs. Cada solicitud lleva su handle en el cuerpo de la solicitud, no en un header que el logger de la aplicación descarta. Un rastro de auditoría puede reconstruir el estado completo del flujo de trabajo en cualquier punto leyendo los argumentos de la solicitud — no se necesita ninguna correlación contra los logs del almacén de sesión.

El estado es cacheable por los intermediarios. Como el handle forma parte de la solicitud, una capa de gateway o de caché puede indexar por él. Los resultados de listas y recursos llevan campos ttlMs y cacheScope, de modo que una consulta al catálogo con un handle estable puede servirse desde la caché sin acceder al sistema upstream.

Cómo se corresponde esto con un flujo de trabajo de RFQ

Considera un flujo de trabajo de cotización que se ejecuta a lo largo de cinco llamadas a herramientas: crear solicitud, buscar en el catálogo, generar cotización, reservar disponibilidad, aplicar nivel de precios. Bajo el protocolo basado en sesiones, estas cinco llamadas comparten una sesión del lado del servidor. Bajo el patrón de handle explícito:

1. create_request(buyer_id, line_items) → request_id="r-1042"
2. search_catalog(request_id="r-1042", query="industrial pump 220V")
3. generate_quote(request_id="r-1042", supplier_ids=["s-12", "s-19"])
       → quote_id="q-7f3a"
4. hold_availability(quote_id="q-7f3a", hold_duration="48h")
       → hold_id="h-3391"
5. apply_pricing_tier(quote_id="q-7f3a", tier="volume-3")

Cada llamada lleva el handle que necesita. Ningún servidor recuerda nada entre llamadas. Si el balanceador de carga enruta la llamada 4 a una instancia distinta de la llamada 3, sigue funcionando — el handle está en la solicitud. Si el equipo de auditoría necesita reconstruir este flujo de trabajo una semana después, los handles en los argumentos de la solicitud cuentan toda la historia.

Extensiones: de primera clase y versionadas de forma independiente

El especificación final introduce las extensiones como un concepto de primera clase. Las extensiones obtienen identificadores en DNS inverso (por ejemplo, com.example.workflow), tienen sus propios repositorios ext-*, cuentan con mantenedores delegados y se versionan de forma independiente del protocolo central.

Las dos primeras extensiones son concretas:

• MCP Apps — interfaces de usuario HTML renderizadas en el servidor y entregadas en iframes en sandbox. Un servidor MCP puede entregar una interfaz que el cliente renderiza, habilitando superficies de aprobación con humano en el bucle sin que el cliente construya un frontend a medida.
• Tasks — trabajo de larga duración con handles de tarea. Una herramienta puede devolver un handle de tarea de inmediato y el cliente sondea para saber si se ha completado, en lugar de mantener una conexión abierta durante minutos.

Para los despliegues B2B, MCP Apps importa allí donde un humano debe aprobar una transacción antes de que el agente continúe — una orden de compra por encima de un umbral, una cotización con un descuento no estándar. La superficie de aprobación puede entregarse junto con el módulo MCP en lugar de requerir un frontend aparte. Tasks importa para los flujos de trabajo que superan el timeout de una sola solicitud: una cotización de proveedor que tarda 90 segundos en generarse, una sincronización de catálogo que se ejecuta durante minutos.

Deprecaciones: Roots, Sampling, Logging

Se deprecian tres características (solo con anotación durante 12 meses; la eliminación requiere un proceso de estándares aparte):

• Roots → reemplazado por parámetros de herramienta y URIs de recurso. Roots era una forma de que los clientes informaran a los servidores sobre ubicaciones del sistema de archivos; la misma intención ahora se expresa como argumentos de las herramientas que leen archivos.
• Sampling → reemplazado por la integración directa con la API del proveedor de LLM. Los servidores que necesitan llamadas a un LLM las hacen directamente al proveedor, en lugar de solicitar al cliente que realice un ida y vuelta de sampling.
• Logging → reemplazado por stderr y OpenTelemetry. El registro del servidor se traslada a la salida estándar del proceso y al trazado distribuido, no al canal de logging de MCP.

La deprecación de Logging es la más relevante para los despliegues B2B. El patrón de registro de auditoría — donde cada llamada a herramienta registra solicitud, respuesta, latencia y resultado — ahora se alinea con OpenTelemetry en lugar de con un canal de logging específico del protocolo. Esto significa que los logs del servidor MCP se integran con los pipelines de observabilidad existentes (Datadog, CloudWatch, Honeycomb) sin un transporte a medida.

Enrutable, cacheable, trazable

Tres adiciones que afectan a las operaciones en producción:

• Los headers Mcp-Method y Mcp-Name permiten el enrutamiento en el gateway sin inspección del cuerpo. Un gateway puede enrutar por método y nombre de herramienta a nivel de header — sin parseo de JSON en la capa de enrutamiento.
• ttlMs y cacheScope en los resultados de listas/recursos dan a los intermediarios un contrato de caché estándar. Una respuesta de lista de catálogo puede declarar un TTL de 5 minutos, y cualquier gateway en el camino puede respetarlo.
• La propagación de W3C Trace Context está documentada para la compatibilidad con OpenTelemetry. Un trace iniciado por el cliente del agente se propaga a través del servidor MCP y hacia las llamadas a los sistemas upstream, de modo que un único flujo de trabajo de RFQ aparece como un solo trace en todos los sistemas que toca.

Para un despliegue B2B que ejecuta servidores MCP para NetSuite, HubSpot y un catálogo de proveedores, esto significa: un gateway puede enrutar por nombre de herramienta sin parsear cuerpos, cachear las respuestas del catálogo durante un TTL declarado y trazar una única solicitud de cotización desde el agente hasta el ERP y la API del proveedor en un solo árbol de spans.

Endurecimiento de la autorización para la forma de uno a muchos

El especificación final mejora OAuth y OpenID Connect para la forma de despliegue que los sistemas de agentes B2B usan realmente: un cliente (el agente) que se conecta a muchos servidores (NetSuite, HubSpot, BigCommerce, un catálogo de proveedores). La renovación de tokens, la gestión de scopes y el manejo de credenciales multi-servidor se abordan en la especificación en lugar de dejarse a que cada integración los resuelva de forma independiente.

Esto importa porque los sistemas de agentes B2B no se conectan a un solo sistema. Un agente de RFQ típico se conecta a un ERP (NetSuite), un CRM (HubSpot), una plataforma de ecommerce (BigCommerce) y dos o tres catálogos de proveedores — cada uno con su propio flujo OAuth, tiempo de vida de token y conjunto de scopes. El protocolo ahora proporciona un patrón estándar para gestionar esa complejidad, en lugar de que cada módulo MCP implemente su propio ciclo de vida de credenciales.

Actualización — 2026-08-06: Terraform MCP CVE-2026-16496 (CVSS 10.0) — la tesis stateless validada en producción

HashiCorp parcheó CVE-2026-16496 (CVSS 10.0) en Terraform MCP Server antes de la versión 1.1.0 — el primer CVE de severidad máxima en el ecosistema MCP. La vulnerabilidad es una bypass de autorización en el modo de transporte stateful streamable-HTTP: un usuario que obtiene el session ID de MCP de otro usuario puede tener sus llamadas de herramientas ejecutadas usando las credenciales de Terraform de ese usuario. HashiCorp también parcheó CVE-2026-16498 (ruptura de aislamiento de tenant) y CVE-2026-14869 (SSRF) en la misma versión. (The Hacker News, SentinelOne vulnerability database)

Este CVE es la primera evidencia de producción de que el modo de transporte stateful es un pasivo de seguridad, no solo una complejidad operativa — y valida la tesis central de este artículo. La capa de protocolo stateless que la especificación final del 28 de julio introdujo existe precisamente para eliminar el estado de sesión del lado del servidor que este ataque explota. El vector de ataque (robo de session ID que lleva a reutilización de credenciales) existe solo porque el servidor mantiene un estado de sesión que un atacante puede robar y reutilizar. Un servidor stateless no tiene sesión que robar. El patrón de handle explícito que este artículo describe — donde los flujos de trabajo con estado generan handles que viajan en el cuerpo de la petición, no en una sesión del lado del servidor — es la arquitectura que cierra esta clase de vulnerabilidad. La vulnerabilidad afecta solo el modo de transporte stateful streamable-HTTP; el núcleo de protocolo stateless no está afectado.

Para despliegues B2B, la implicación es directa: si sus servidores MCP ejecutan stateful streamable-HTTP con Mcp-Session-Id, llevan la superficie de ataque de session-hijacking que CVE-2026-16496 explota. Migrar al núcleo de protocolo stateless (Control 1 en la Lista de verificación de endurecimiento de seguridad MCP) elimina la superficie de ataque a nivel de arquitectura, no a nivel de parche. La ventana de deprecación de 12 meses de SSE es ahora una fecha límite de seguridad, no solo operativa.

Seguridad: tres nuevas superficies de ataque y un dato de defensa en profundidad

El rediseño sin estado introduce tres nuevas superficies de ataque identificadas por backslash.security en su análisis del mismo día de la especificación final:

• Secuestro de handles. Los handles explícitos reemplazan el estado de sesión del lado del servidor, pero un handle es un argumento ordinario. Si el espacio de handles es predecible o el transporte carece de protección de integridad, un atacante que observe o adivine un handle puede inyectarlo en sus propias solicitudes — suplantando al propietario del flujo de trabajo. La solución es la generación criptográfica de handles (aleatorios, no adivinables) y la vinculación de handles al llamador autenticado, no solo al cuerpo de la solicitud.
• Brecha de alcance del sistema de archivos. La deprecación de Roots elimina la declaración de límite del sistema de archivos del lado del cliente. Las herramientas que leen archivos ahora reciben rutas como argumentos, pero sin el límite de Roots, una herramienta puede acceder a ubicaciones del sistema de archivos que el cliente nunca tuvo la intención de exponer. La solución es la validación de ruta por herramienta contra una lista de permitidos explícita, no la dependencia de un límite a nivel de protocolo que ya no existe.
• Renderizado HTML de MCP Apps. La extensión MCP Apps permite a los servidores enviar UIs HTML en iframes en sandbox. El sandbox es un límite de seguridad, pero el contenido HTML proviene del servidor — un servidor MCP comprometido o malicioso puede enviar una UI que intente escapar del sandbox o hacer phishing al usuario. La solución es tratar el HTML de MCP Apps como contenido no confiable: Content Security Policy estricta, sin acceso same-origin, y confirmación del usuario antes de renderizar superficies de aplicaciones de servidores nuevos.

Un dato de defensa en profundidad: Claude Opus 5 con Auto Mode habilitado logró una tasa de éxito de ataque de inyección de prompt en navegador del 0% en 129 escenarios de prueba — el primer dato concreto que muestra que la inyección de prompt en agentes de navegador puede reducirse a cero. Auto Mode combina una sonda de inyección de prompt en la capa de entrada con un clasificador de acciones en la capa de salida. Para despliegues sin estado de MCP donde agentes de navegador llaman herramientas MCP, el patrón de escaneo de entrada + bloqueo de tareas es una implementación concreta de defensa en profundidad que el diseño sin estado del protocolo facilita: cada solicitud es autónoma, por lo que la sonda y el clasificador operan en cada solicitud de forma independiente, sin estado de sesión que corromper.

Qué cambia para los módulos MCP existentes

Si ya entregas módulos MCP — por ejemplo, el patrón del procesador de RFQ de 38 herramientas donde las herramientas se registran a través de MCP_CONFIGURATION y los mixins de dominio se componen sobre un cliente GraphQL compartido — el protocolo sin estado cambia el despliegue, no el código del módulo.

El registro de herramientas del módulo, los esquemas de entrada/salida, la limitación de tasa y el registro de auditoría siguen igual. Lo que cambia:

• Sin inicialización de sesión al arrancar. El módulo no participa en un handshake initialize. Recibe solicitudes con _meta que lleva la versión del protocolo y las capacidades, y responde.
• Las herramientas con estado acuñan handles. Si una herramienta hoy depende de una sesión del lado del servidor para rastrear un flujo de trabajo de varios pasos, debería acuñar un handle explícito y devolverlo. El cliente lo devuelve en la siguiente llamada. Para un procesador de RFQ, el request_id, el quote_id y el hold_id ya son los handles — el patrón es natural para el dominio.
• El logging se traslada a OpenTelemetry. Si el módulo registra a través del canal de logging de MCP, migra a stderr y a los spans de OpenTelemetry. El contenido de auditoría (solicitud, respuesta, latencia, resultado) se mantiene; cambia el transporte.
• La caché es declarativa. Los endpoints de listas y recursos pueden declarar ttlMs y cacheScope en sus respuestas, permitiendo que los intermediarios cacheen sin adivinar.

La conclusión para los equipos B2B

El protocolo sin estado reduce la infraestructura que requiere un despliegue de agentes basado en MCP. Cambias las sesiones persistentes y los almacenes de sesión compartidos por handles explícitos en los argumentos de la solicitud — un intercambio que hace que el sistema sea más simple de escalar, más fácil de auditar y más observable con las herramientas estándar.

Si tu equipo está definiendo el alcance de un despliegue de agentes basado en MCP, el especificación final del 28 de julio es la versión a la que apuntar. Diseñar para handles explícitos desde el principio evita la migración desde el estado basado en sesiones más adelante. La ventana de deprecación de 12 meses para Roots, Sampling, Logging y HTTP+SSE significa que los equipos que ejecutan el transporte antiguo deberían planificar la migración ahora — los 1.227 servidores que aún usan SSE deprecado son la población más afectada.

---

Un distribuidor que ejecuta NetSuite, BigCommerce y tres catálogos de proveedores obtiene un agente que recibe una RFQ por correo electrónico o portal, resuelve productos y sustitutos contra el grafo del catálogo, fija precios por nivel de cliente, reserva stock con una expiración y escribe la cotización aceptada de vuelta en NetSuite — con cada paso registrado. Esa construcción es la Fase 2-3 del método de cuatro pasos y normalmente está en producción en 5-8 semanas.

Solicita una construcción con alcance definido. Una semana de descubrimiento. Obtienes un inventario del sistema, un mapa de flujos de trabajo y un alcance fijo — construyas con nosotros o no.