Qué se publicó el 28 de julio

El Model Context Protocol publicó su quinta especificación el 28 de julio, y es el mayor cambio desde que el protocolo nació. El núcleo es ahora sin estado. La negociación entre initialize e initialized desaparece, la cabecera Mcp-Session-Id se retira y cada petición lleva en su lugar la versión del protocolo, la identidad del cliente y sus capacidades en un campo _meta. El efecto práctico es que basta un balanceador de carga round robin: cualquier instancia puede atender cualquier petición y no queda ningún almacén de sesiones que mantener.

De esa decisión se derivan varias piezas más. Las Multi Round-Trip Requests sustituyen las llamadas iniciadas por el servidor que antes necesitaban un flujo abierto: en lugar de empujar una petición por un canal abierto, el servidor devuelve un tipo de resultado input_required y el cliente repite la llamada original con las respuestas incorporadas. Las peticiones Streamable HTTP llevan ahora las cabeceras Mcp-Method y Mcp-Name para que una pasarela o un limitador de tráfico pueda encaminar y medir sin analizar el cuerpo JSON. Los resultados de listado de herramientas, prompts y recursos llevan un tiempo de vida y un ámbito de caché. Tasks y MCP Apps pasan a un marco formal de extensiones en vez de residir en el núcleo.

Las cifras de adopción explican por qué esto importa más allá de quienes escriben servidores. Los SDK de nivel 1 para TypeScript, Python, Go y C sharp se acercan juntos a los 500 millones de descargas al mes, y los paquetes de TypeScript y Python han superado cada uno los mil millones de descargas totales. David Soria Parra, uno de los responsables principales del mantenimiento, lo llamó la publicación más importante desde que remote MCP arrancó hace más de un año. Si su empresa compró en los últimos dieciocho meses un producto que conecta un asistente con sus sistemas, esta especificación está debajo, le hayan dicho el nombre o no.

Retirar Sampling mueve una factura de inferencia

La lista de obsolescencias se lee como tarea de limpieza: Roots, Sampling y Logging, todos con doce meses de ventana. Dos de ellos son realmente menores. Roots se convierte en rutas de directorios y ficheros pasadas como parámetros de herramienta o fijadas en la configuración del servidor. Logging se traslada a la salida de error estándar o a OpenTelemetry, que es donde la mayoría de los operadores lo querían de todos modos. Sampling es otro caso, y lo es de una manera que toca un presupuesto y no una base de código.

Sampling era el mecanismo por el que un servidor MCP podía pedir al cliente que ejecutara una respuesta del modelo en su nombre. El servidor necesitaba salida de un modelo de lenguaje pero no tenía que guardar credenciales, porque la inferencia la hacía el cliente y la pagaba el cliente. Eso es un reparto comercial real expresado como función del protocolo. La guía de migración publicada para los servidores que pierden Sampling indica integrarse directamente con las interfaces de un proveedor de modelos desde el lado del servidor. Leído como operador, la consecuencia es clara: quien opera el servidor necesita ahora su propia cuenta de proveedor, su propia clave y su propia partida.

Hacia dónde se mueve el dinero depende del asiento que ocupe. Si opera servidores MCP para su propia plantilla contra el cliente de un proveedor, aterriza en su cuenta una inferencia que antes no pagaba, y en una instalación mediana eso es un compromiso mensual nuevo de cuatro cifras en euros y no un error de redondeo. Si consume el servidor MCP de un proveedor, cuente con una revisión de precios, porque un coste que antes empujaba hacia su cliente pasa a ser propio del proveedor. Nada de esto se anuncia en unas notas de versión. Ambas cosas aparecen en una factura en menos de un año.

Sin estado movió el estado, no lo borró

Los comentarios de los proveedores sobre esta publicación giran sin excepción en torno a la escala, y provienen de las empresas que más ganan cuando los servidores son fáciles de alojar: proveedores de nube y de borde que describen el protocolo como encaminable, cacheable y escalable globalmente, y plataformas que celebran el fin de la gestión de sesiones. Todo ello es cierto. Abandonar la fijación de cada sesión a una misma instancia elimina una clase de fallo en la que un flujo interrumpido destruía la conversación entera, y permite ejecutar un servidor sobre infraestructura sin servidor que nunca habría podido mantener una sesión abierta.

Lo que ninguno de ellos dice es que el estado no se evaporó. Todo lo que de verdad debe persistir entre llamadas hay que representarlo ahora de forma explícita: el servidor genera un identificador - el de un carrito, un token, una referencia de proceso - y lo devuelve dentro de un resultado para que el cliente lo reenvíe. Es un diseño sólido, pero convierte una preocupación invisible del protocolo en una parte visible de sus contratos de herramientas. Alguien tiene que decidir qué significan esos identificadores, cuánto duran y qué ocurre cuando un cliente reenvía uno caducado. Ese trabajo no desapareció con la cabecera de sesión. Se trasladó a sus esquemas, donde le toca a su equipo hacerlo bien.

Ponga el 28 de julio de 2027 en la planificación

La regla que manda es que todo lo marcado como obsoleto sigue funcionando al menos doce meses. Eso convierte el 28 de julio de 2027 en la primera fecha en que Roots, Sampling, Logging, el registro dinámico de clientes o el transporte antiguo por HTTP y SSE pueden retirarse de verdad, y es la única fecha de esta publicación que merece escribirse en una hoja de ruta. Esta semana no se rompe nada. Aun así, lo primero que conviene leer son los cambios de autorización: los servidores de autorización deben devolver ahora un parámetro de emisor y los clientes deben validarlo antes de canjear un código, las credenciales de cliente quedan ligadas al servidor que las emitió, y el registro dinámico de clientes cede el paso a los Client ID Metadata Documents.

Para una operación europea, la pieza sobre la que conviene actuar pronto es Enterprise Managed Authorization, que llega como extensión y permite a la administración conceder acceso a servidores MCP de forma centralizada mediante un proveedor de identidad. Hasta ahora la autorización en las instalaciones de MCP se dejaba con frecuencia para el final, y precisamente por eso tantos proyectos internos de agentes se quedaron atascados en la revisión de seguridad. Si el suyo es uno de ellos, el motivo del atasco ya está atendido en la especificación, y el paso honesto es preguntar a sus proveedores cuándo darán soporte a la extensión en lugar de esperar a que se lo cuenten.

Leer a continuación: Un solo mensaje alcanzó las claves SSH  |  Anthropic pide sus chips a un fabricante de memoria