Sesiones, vinculación de clientes y almacenes compartidos serán cosa del pasado: MCP se convierte en un protocolo web más.

El protocolo que ayuda a los modelos de inteligencia artificial a conectarse con servicios externos se prepara para abandonar uno de sus principios básicos. La mayor actualización de Model Context Protocol desde su lanzamiento eliminará las sesiones y dejará de intercambiar datos de control por adelantado, lo que ha obligado a diseñar servidores remotos más complejos que los servicios web habituales.

Los desarrolladores congelaron la versión preliminar de la especificación el 21 de mayo, y planean publicar la versión final el 28 de julio. El objetivo principal de la actualización es que cada solicitud incluya todos los datos necesarios para su procesamiento y no dependa de una conexión establecida previamente.

Inicialmente MCP se creó para aplicaciones de escritorio que se comunicaban con procesos locales a través de los flujos estándar de entrada y salida. En ese esquema, la conexión persistente y el hecho de que las capacidades se verificaran de antemano apenas planteaban problemas. La situación cambió cuando los servidores MCP empezaron a trasladarse a la nube y a distribuirse entre varios nodos.

El servidor asignaba al cliente un identificador de sesión y, de hecho, lo vinculaba a una instancia concreta. Para escalar el sistema, los operadores tenían que ligar a los clientes a servidores específicos, almacenar datos compartidos de sesión o añadir lógica especial en las pasarelas. Un servicio remoto corriente, debido a los requisitos del protocolo, se convertía en un sistema distribuido más complejo.

Después de la actualización, la versión del protocolo, las capacidades del cliente y su identificador se enviarán con cada llamada. Los servidores recibirán un método separado server/discover, a través del cual el cliente podrá solicitar las funciones disponibles con antelación o justo antes de dirigirse al servidor. Los desarrolladores denominan este enfoque complejidad bajo demanda. El esquema básico sigue siendo sencillo, y se añade estado solo donde es imprescindible.

Para operaciones que necesitan recordar contexto, MCP propondrá identificadores explícitos. Por ejemplo, una herramienta podrá crear un carrito, devolver basket_id, y el modelo transmitirá ese valor en la siguiente solicitud. Este mecanismo ya se usa desde hace tiempo en aplicaciones web convencionales. A diferencia del identificador de sesión oculto, el modelo ve el identificador del recurso y puede transmitirlo entre herramientas y fases de trabajo.

Tales valores no deben considerarse una prueba de permisos. Los identificadores pueden aparecer en solicitudes, registros e historial de diálogo, por lo que el servidor debe asociarlos a la cuenta y verificar los permisos cada vez que se le consulte.

Tras la actualización, los servidores MCP remotos podrán ejecutarse como servicios sin estado habituales. Varias instancias podrán funcionar detrás de un equilibrador, sin ligarse a clientes concretos ni usar un almacenamiento de sesiones compartido. La actualización de los servidores también dejará de interrumpir sesiones largas, aunque las solicitudes incompletas y los flujos de notificaciones todavía pueden cortarse. En ese caso, el cliente enviará la solicitud de nuevo con un nuevo identificador.

Las pasarelas recibirán el encabezado obligatorio Mcp-Method, y las operaciones con herramientas, recursos y plantillas también enviarán Mcp-Name. Gracias a los encabezados, la infraestructura podrá limitar la frecuencia de solicitudes y verificar permisos sin leer todo el cuerpo del mensaje. Además, el servidor está obligado a rechazar llamadas si el encabezado no coincide con el contenido de la solicitud, ya que de lo contrario un atacante podría disfrazar una operación como otra.

La actualización también cambia la caché. Las respuestas con listas de herramientas y recursos contendrán un tiempo de vida ttlMs y un ámbito cacheScope. El cliente podrá guardar temporalmente el catálogo y no solicitarlo cada vez que consulte al servidor. Los servidores también deben devolver las herramientas en un orden estable, lo que mejorará la eficiencia del almacenamiento en caché de las solicitudes a los modelos y puede reducir la latencia y los costes.

Los autores de MCP trasladaron las extensiones a un sistema separado con sus propios nombres, repositorios y ciclos de publicación. La función Tasks, que añadieron de forma experimental en noviembre de 2025, abandonará el núcleo y pasará a ser una extensión después de su reestructuración. Este enfoque permitirá desarrollar funcionalidades adicionales sin modificar continuamente la especificación principal.

Junto con la actualización aparecerá una política formal de deprecación de funciones antiguas. La funcionalidad obsoleta debe permanecer disponible al menos 12 meses. El plazo solo podrá reducirse ante una amenaza de seguridad confirmada, pero incluso entonces el período de transición será de al menos 90 días.

La migración requerirá ajustes. Los servidores que usaban la interfaz experimental Tasks tendrán que pasarse al nuevo esquema. Los mecanismos Sampling y Logging también perderán su papel anterior. Si un servidor empieza a comunicarse directamente con el proveedor del modelo, su propietario tendrá que almacenar por su cuenta las claves de acceso, pagar las solicitudes y procesar los datos de los usuarios.

Si se eliminan las sesiones, el estado de la aplicación no desaparecerá. Los carritos, las tareas, los identificadores de operaciones y la protección contra solicitudes repetidas seguirán requiriendo una base de datos u otro almacenamiento. MCP simplemente dejará de gestionar esos datos a nivel de protocolo.

Para migrar a la nueva versión, los clientes primero llamarán a server/discover y, cuando se conecten a un servidor antiguo, volverán al initialize anterior. Los desarrolladores también han preparado conjuntos preliminares de herramientas para Python, TypeScript, Go y C#. Como resultado, MCP se acercará más a la infraestructura web habitual, y los propietarios de servidores ya no tendrán que mantener una capa separada solo por las exigencias del protocolo.