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 release candidate 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 release candidate 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 release candidate 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 release candidate 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.

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 release candidate 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.

---

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.