Lo que el release candidate del 28 de julio de MCP realmente reestructura
El grupo directivo del Model Context Protocol emitió el release candidate 2026-07-28 como la revisión más grande del protocolo desde el lanzamiento. La especificación final se publica el 28 de julio y cierra la ventana de diez semanas para mantenedores de SDK que abrió el RC. Cuatro cambios portantes aterrizan juntos: un núcleo HTTP stateless, la extensión Tasks para trabajo de larga duración, MCP Apps para UI renderizada en servidor dentro de iframes en sandbox, y una superficie de autorización alineada con despliegues de OAuth 2.1 y OpenID Connect. Una política de deprecación formal se envía en paralelo para que futuras revisiones puedan evolucionar sin romper la superficie desplegada.
Las lecturas operativamente importantes:
- El núcleo stateless es la noticia real, no la superficie de extensiones. La asunción de sesión con estado de la spec anterior es lo que forzó las soluciones de afinidad de conexión que cada despliegue de MCP en producción terminó escribiendo contra balanceadores con sticky-session, sidecars de session store, o servidores single-instance por región. Stateless colapsa el transporte a HTTP plano con el protocolo base JSON-RPC corriendo encima; cada despliegue que levantó la plomería de afinidad para mantener la spec anterior puede eliminarla dentro de la ventana de migración.
- La extensión Tasks formaliza el patrón de trabajo-de-larga-duración que el mercado ya envió. Cada integración seria de MCP este año inventó su propio idiom de tool-call-devuelve-un-handle porque la spec anterior no tenía respuesta para llamadas de herramienta cuya latencia excede el timeout de HTTP.
tasks/get,tasks/updateytasks/cancelaterrizan como la superficie estandarizada — los idioms por-proveedor enviados contra el hueco son ahora código legacy dentro de la ventana de diez semanas. - MCP Apps (SEP-1865) pone la UI renderizada en servidor en el camino de auditoría, no en el camino del hack del lado del cliente. Las herramientas declaran sus plantillas de UI por adelantado; los hosts las prefetchean, cachean y revisan por seguridad; la UI renderizada habla de vuelta sobre la misma superficie JSON-RPC por la que corre cada llamada directa de herramienta. Cada acción iniciada desde UI pasa por el mismo camino de consent-and-audit que una llamada de herramienta — el patrón construir una UI web custom para gatear acciones de agentes que escribió el equipo de seguridad puede colapsar en la propia affordance de la spec.
- La superficie de autorización se alinea con OAuth 2.1 y OIDC. La capa de auth sub-especificada de la spec anterior es lo que el CSI de la NSA sobre seguridad de MCP señaló como el bloqueador principal para la adopción empresarial. La alineación del RC con el sustrato IdP desplegado — Okta, Azure Entra, Ping, ForgeRock — cierra la brecha contra la que el equipo de seguridad ha estado escribiendo middleware custom de auth-gateway durante los últimos dos trimestres.
La lectura estructural no es MCP lanzó una nueva versión. Es que el protocolo cruzó de superficie de integración experimental a sustrato estandarizado de producción — el bloqueador de adopción empresarial citado por cada encuesta de MCP en 2026 tiene una respuesta a nivel de spec, la política de deprecación compromete al grupo directivo con un contrato de compatibilidad, y la ventana de migración de diez semanas es la fecha contra la que califica el portafolio de servidores MCP del equipo.
Lo que los cuatro cambios portantes reestructuran para el plan de MCP de FY27
El portafolio de servidores MCP se consolida contra el transporte stateless. El modelo de sesión de la spec anterior forzó la topología de despliegue a sticky-session load balancing (frágil) o single-instance-por-región (no escalable). El núcleo stateless permite al portafolio de servidores MCP desplegarse detrás de un balanceador estándar sin afinidad de sesión, sin sidecar de session store, sin pinning por región. El equipo de infraestructura que levantó la plomería de afinidad durante la era de la spec anterior puede retirarla — el objetivo de simplificación de plataforma de FY27 que el equipo escribió contra el modelo de sesión de la spec anterior se convierte en un refactor de eliminar-código dentro de la ventana de migración.
La extensión Tasks colapsa los idioms por-proveedor de trabajo-de-larga-duración. Cada despliegue de MCP en producción haciendo extracción estructurada sobre documentos, ejecutando búsquedas de larga duración o disparando cadenas multi-paso de herramientas terminó escribiendo su propio idiom de devolver-un-handle porque la spec anterior no tenía superficie estandarizada de trabajo-de-larga-duración. tasks/get / tasks/update / tasks/cancel aterrizan como el ciclo de vida dirigido por el cliente sobre el modelo de creación-de-tarea dirigido por el servidor. El plan de servidores MCP de FY27 puede retirar los idioms por-proveedor y calificar contra la superficie estandarizada — la envolvente de portabilidad del contrato permanente de servidores MCP por-proveedor mejora contra el mismo conjunto de features subyacentes.
MCP Apps permite al equipo de seguridad poner las acciones iniciadas desde UI en el mismo camino de auditoría que las llamadas de herramienta. La spec anterior no tenía historia para UI renderizada en servidor; cada equipo que envió una herramienta MCP interactiva o escribió una UI web custom fuera del camino de auditoría o forzó la interacción a través de un bucle de turno mediado por chat que rompía la UX. La superficie de iframe en sandbox de MCP Apps con el mismo transporte JSON-RPC permite que la herramienta interactiva se envíe dentro del cliente, en el camino de auditoría-y-consentimiento, sin que el equipo de seguridad escriba un gateway a medida. La superficie de herramienta interactiva que el equipo de producto scopeó contra el hueco de la spec anterior se envía contra la affordance estandarizada dentro de la ventana de migración.
La alineación con OAuth 2.1 / OIDC cierra la brecha de adopción empresarial. El CSI de la NSA sobre seguridad de MCP señaló la autorización como el bloqueador principal, y el cluster de 30 CVEs sobre fallas de path-traversal y argument-injection en servidores de referencia subrayó la brecha de madurez. La alineación del RC con el sustrato IdP desplegado — la misma superficie OAuth 2.1 / OIDC sobre la que ya corre el plano SSO empresarial — significa que el plan de adopción de MCP de FY27 califica contra el mismo sustrato de auth que ya respalda el contrato permanente de IdP. El middleware custom de auth-gateway que el equipo de seguridad escribió como medida interina se retira limpiamente contra la superficie alineada.
Dónde el RC es señal y dónde es ruido
Señal: la ventana de diez semanas es una fecha dura para el portafolio de SDK Tier-1. Los SDK Tier-1 del grupo directivo — Python, TypeScript, Go, Java — se espera que envíen soporte para el RC dentro de la ventana. Cada servidor MCP que el equipo corre contra un SDK Tier-1 califica contra la fecha de envío-de-soporte del SDK; cada servidor MCP contra un SDK Tier-2 califica contra una ventana de migración más larga que la propia envolvente de portabilidad del portafolio del equipo tiene que respaldar.
Señal: la política de deprecación es el contrato que el plan de adquisiciones de FY27 necesita. La spec anterior no tenía contrato formal de deprecación; las revisiones por-ciclo rompían servidores MCP desplegados sin aviso previo. La política formal de deprecación compromete al grupo directivo a un contrato de compatibilidad contra el que el plan de adquisiciones de FY27 puede calificar el contrato permanente de servidores MCP — la pregunta de cuánto hasta que la próxima revisión disruptiva fuerce una re-migración que la función de adquisiciones no tenía respuesta ahora tiene una.
Ruido: MCP Apps reemplaza a la UI web custom es el marco incorrecto. MCP Apps es la affordance estandarizada para la superficie de UI scoped-a-herramienta; la UI web scoped-a-plataforma (dashboards, consolas admin, constructores de workflow) sigue corriendo fuera del transporte MCP. El marco que mapea cada UI web custom a MCP Apps sobrepasa la affordance; el marco que mapea la superficie de herramienta interactiva a MCP Apps atina en el objetivo de la spec.
Ruido: el núcleo stateless hace imposibles los servidores stateful. El núcleo stateless es el default a-nivel-de-transporte; el estado del lado del servidor (datos de sesión, cache por-usuario, estado de tareas corriendo) permanece en la capa de persistencia propia del servidor. El marco de transporte-stateless que se lee como sin estado del lado del servidor mal-lee el cambio; el marco que se lee como sin requisito de afinidad de conexión en el transporte lo atina.
Lo que el equipo de ingeniería debería hacer en las próximas dos semanas
Inventariar el portafolio de servidores MCP contra los cuatro cambios portantes del RC. Para cada servidor MCP que corre el equipo — interno, de terceros, comunitario — calificar contra el costo de migración del transporte stateless, el costo de reemplazo por la extensión Tasks para los idioms por-proveedor de trabajo-de-larga-duración, la oportunidad de MCP Apps para la superficie de herramienta interactiva, y la alineación de OAuth/OIDC contra el sustrato IdP empresarial. La salida es el plan de migración del portafolio de servidores MCP de FY27 contra el que califica la ventana de diez semanas.
Calificar la dependencia de SDK Tier-1 contra la fecha de envío del RC. Para cada servidor MCP contra un SDK Tier-1, reservar la migración dentro de la ventana de diez semanas; para cada servidor MCP contra un SDK Tier-2, reservar la migración de ventana extendida contra el timeline público del mantenedor del SDK. El timeline de migración por-SDK del equipo se convierte en la entrada a la renegociación del contrato permanente de servidores MCP.
Retirar el middleware custom de auth-gateway contra la superficie alineada de OAuth 2.1 / OIDC. El código interino de custom-auth-gateway que el equipo de seguridad escribió contra la capa de auth sub-especificada de la spec anterior es el primer refactor de eliminar-código que abre la ventana de migración. El objetivo de simplificación de plataforma de FY27 que el equipo escribió contra la brecha de auth de la spec anterior se convierte en un ítem concreto del backlog — calificar el refactor de eliminar-código contra el mismo camino de revisión por el que pasa cada delete crítico-para-seguridad.
Actualizar el contrato permanente de servidores MCP contra la política de deprecación. La función de adquisiciones no tenía entrada de contrato-de-compatibilidad para el contrato permanente de servidores MCP antes de que aterrizara la política de deprecación. La política de deprecación del RC es la entrada que la renegociación del contrato permanente ha estado esperando — la cláusula de envolvente-de-compatibilidad por-proveedor que la función de adquisiciones ha estado escribiendo contra un objetivo móvil ahora califica contra la política pública del grupo directivo.
Lo que el RC abarata pero no reemplaza
El RC 2026-07-28 comprime los costos de transporte, autorización y ciclo-de-vida de trabajo-de-larga-duración de la superficie de integración de MCP, no el juicio senior de decidir qué servidores MCP se envían contra el sustrato IdP empresarial, escribir las plantillas de UI scoped-a-herramienta contra las que corre la affordance de MCP Apps, ser dueño de la envolvente de compatibilidad por-proveedor sobre el contrato permanente de servidores MCP, y ejecutar la revisión de código por-ciclo contra el portafolio de servidores MCP del equipo. Los equipos que confunden el costo de transporte abaratado con el juicio abaratado envían la superficie de herramienta interactiva contra plantillas de MCP Apps que la revisión de seguridad no ha corrido, leen el post-mortem de CVEs sobre el próximo cluster de path-traversal, y comen el costo por-ciclo de re-migración que la política de deprecación habría capturado aguas arriba. Los equipos que mantienen el juicio senior en el centro de la decisión del portafolio de MCP traducen los cuatro cambios portantes en mejoras de throughput por-trimestre que la superficie sub-especificada de la spec anterior no podía producir.
La pregunta de MCP ya no es el equipo corre servidores MCP; es qué servidores MCP corre el equipo contra el transporte stateless, el ciclo de vida de la extensión Tasks, la superficie interactiva de MCP Apps, y la autorización alineada con OAuth 2.1 / OIDC, y cómo la ventana de migración de diez semanas califica contra el plan de portafolio de servidores MCP de FY27.
En SONNET CODE ejecutamos la práctica de Desarrollo de IA contra el plan de migración del portafolio de servidores MCP — migraciones de transporte stateless por-servidor, reemplazos por-proveedor con la extensión Tasks para los idioms de trabajo-de-larga-duración, superficies de herramienta interactiva por-servidor con MCP Apps, y alineación OAuth 2.1 / OIDC contra el sustrato IdP empresarial. Si el portafolio de servidores MCP de tu equipo todavía está escrito contra el modelo de sesión o la superficie de auth sub-especificada de la spec anterior, agenda una llamada — te llevaremos a través del plan de migración que lanzamos dentro de la ventana de diez semanas antes de que la spec final la cierre.
