Qué ha cambiado exactamente
MCP no numera versiones: las fecha. La anterior estable era 2025-11-25; la nueva es 2026-07-28, publicada tras una ventana de release candidate de diez semanas para que los mantenedores de SDK validaran los cambios contra cargas reales. Las piezas del cambio son seis, y conviene separarlas porque tienen implicaciones muy distintas.
Núcleo sin estado. Se eliminan las sesiones a nivel de protocolo y la cabecera Mcp-Session-Id del transporte Streamable HTTP. Desaparece también el intercambio initialize / notifications/initialized: cada petición viaja de forma independiente y lleva su versión de protocolo y las capacidades del cliente en _meta. Si un cliente quiere conocer de antemano las capacidades del servidor, existe un nuevo RPC server/discover, que no es obligatorio.
Estado explícito. El estado entre llamadas no desaparece: se hace explícito. Los servidores que necesitan mantener contexto entre invocaciones emiten handles propios que se pasan como argumentos ordinarios de herramienta. La diferencia es sustancial desde el punto de vista de auditoría: el estado deja de ser una propiedad opaca de la conexión y pasa a ser un dato visible en la traza de la llamada.
Enrutado y cacheo. Las peticiones incorporan cabeceras Mcp-Method y Mcp-Name, de modo que un balanceador o un gateway puede enrutar sin abrir el cuerpo del mensaje. Los listados (tools/list, resources/list, prompts/list) dejan de variar por conexión y pueden cachearse durante el tiempo que el servidor indique mediante ttlMs.
Extensiones, autorización y ciclo de vida. La revisión formaliza un marco de extensiones — con Tasks para trabajo de larga duración y MCP Apps para interfaces renderizadas por el servidor —, endurece la autorización para alinearla con despliegues OAuth y OpenID Connect, e introduce una política formal de deprecación.
Por qué esto es una noticia de arquitectura, no de protocolo
El efecto práctico sobre un despliegue en producción es inmediato. Un servidor MCP remoto que antes necesitaba sesiones sticky, un almacén de sesión compartido e inspección profunda de paquetes en el gateway puede ahora ejecutarse detrás de un balanceador round-robin corriente, enrutar por cabecera y permitir a los clientes cachear el listado de herramientas durante el TTL que el servidor autorice.
Quien haya intentado poner un servidor MCP detrás de Azure App Service, un Application Gateway o un Front Door reconocerá el problema que esto resuelve. La afinidad de sesión —ARR affinity en el mundo IIS— es exactamente el tipo de dependencia que rompe el escalado horizontal, complica el blue/green, degrada la conmutación entre regiones y obliga a explicarle al equipo de plataforma por qué esta carga concreta necesita un tratamiento especial.
| Preocupación | Antes (2025-11-25) | Ahora (2026-07-28) |
|---|---|---|
| Escalado | Sesiones sticky y almacén de sesión compartido entre instancias | Cualquier instancia atiende cualquier petición; balanceo round-robin |
| Gateway / WAF | Inspección del cuerpo para saber qué se está invocando | Enrutado y políticas por cabecera Mcp-Method / Mcp-Name |
| Autorización | Autenticación asociada al establecimiento de la sesión | Validación por petición, alineada con OAuth / OIDC |
| Rendimiento | Listados renegociados por conexión | Listados cacheables con TTL declarado por el servidor |
| Continuidad | Failover pierde el contexto de sesión | Sin estado que perder: el contexto viaja en handles explícitos |
| Trazabilidad | Estado implícito en la conexión, difícil de auditar | Estado explícito en argumentos, visible en la traza |
La lectura corta para un comité de arquitectura: MCP ha dejado de ser un protocolo con forma de herramienta de escritorio y ha adoptado la forma del resto de la web. Eso no lo hace seguro por sí solo, pero elimina la excepción — y en banca y seguros, las excepciones de plataforma son precisamente lo que bloquea un despliegue durante trimestres.
Lo que rompe
No es una actualización menor y conviene decirlo sin adornos. Hay cambios incompatibles hacia atrás: un servidor que hable 2026-07-28 puede no entenderse con clientes antiguos, y viceversa. La compatibilidad exige que ambos extremos compartan una era de protocolo soportada, o que uno de los dos implemente deliberadamente una traducción o un mecanismo de fallback. La política formal de deprecación garantiza que lo marcado como obsoleto siga funcionando al menos doce meses, pero eso es una ventana de migración, no una garantía de interoperabilidad indefinida.
Para un entorno regulado, esto tiene una consecuencia operativa concreta: si hay servidores MCP internos consumidos por clientes de terceros —o por herramientas de desarrollo que actualizan a su propio ritmo—, la migración necesita un inventario previo de qué habla con qué, y una fase de convivencia. No es una tarde de trabajo.
El punto que nadie está comentando: el cacheo es superficie de ataque
Que los listados de herramientas sean cacheables es excelente para el rendimiento y merece una línea en el análisis de riesgos. Un cliente que cachea tools/list durante el TTL declarado está operando, durante ese intervalo, sobre una vista del catálogo de herramientas que puede haber cambiado en el servidor. Si una herramienta se retira por un incidente de seguridad, el TTL determina cuánto tarda ese cambio en propagarse.
La consecuencia de diseño es sencilla y hay que tomarla explícitamente: el ttlMs no es un parámetro de rendimiento, es un parámetro de contención. En cargas de banca o seguros, valores agresivos de cacheo deberían ir acompañados de un mecanismo de invalidación y de la capacidad de revocar la autorización a nivel de petición, que precisamente es lo que el nuevo modelo permite.
Contexto que conviene no separar: esta especificación llega la misma semana en la que se ha documentado el primer incidente de ciberseguridad ejecutado de extremo a extremo por un sistema de agentes autónomos. MCP es, precisamente, el mecanismo por el que un agente accede a sistemas de producción. Facilitar el despliegue y endurecer los controles tienen que avanzar a la vez: si solo se hace lo primero, lo que se ha ganado es velocidad para llegar antes al problema.
Checklist de migración
- Inventariar clientes y servidores MCP y su versión de protocolo antes de tocar nada. Sin ese mapa no hay plan de convivencia posible.
- Actualizar a un SDK que hable
2026-07-28, verificando que no es un simple salto de versión menor del paquete anterior. - Eliminar suposiciones de sesión: retirar cualquier dependencia de
Mcp-Session-Idy mover el estado por sesión a handles explícitos pasados como argumentos. - Emitir y honrar las cabeceras nuevas (
Mcp-Method,Mcp-Name) y validarlas en el servidor, no solo en el gateway. - Declarar
ttlMsy ámbito de cacheo de forma consciente, con un mecanismo de invalidación para retirada de herramientas. - Desactivar la afinidad de sesión en el balanceador y validar el escalado horizontal real, no el teórico.
- Revisar el flujo de autorización contra el patrón OAuth/OIDC corporativo, incluida la revocación.
- Probar con el modelo en el bucle, no solo con
curl: las regresiones típicas de esta migración son herramientas que el modelo deja de encontrar o formas de argumento que han derivado. - Actualizar la observabilidad — trazas, métricas y evals — para que refleje el modelo por petición. Es el mismo cuadro de mando que ya defendimos en AgentOps.
Qué significa para banca y seguros
El patrón que veníamos aplicando para llevar IA agéntica a producción en sectores regulados pasaba por MCP como capa de integración con sistemas heredados. La objeción recurrente en los comités no era el modelo ni el caso de uso: era la infraestructura. Un servicio que exige afinidad de sesión y un almacén compartido es un servicio que encaja mal en una Landing Zone diseñada para cargas sin estado, complica el plan de recuperación y obliga a documentar una excepción ante el auditor.
Con el núcleo sin estado esa objeción desaparece. El servidor MCP se despliega, se escala y se recupera como cualquier API interna, con las mismas políticas de red, la misma identidad y la misma observabilidad. Y con la autorización validada petición a petición, la trazabilidad —quién invocó qué herramienta, con qué argumentos y bajo qué credencial— deja de depender de correlacionar sesiones y pasa a ser un dato de primera clase en el log.
Esa trazabilidad no es un detalle técnico. Es exactamente el material con el que se construye el expediente que pide un supervisor cuando pregunta cómo se controla un sistema automatizado que toca datos de cliente.