La spécification MCP datée du 28 juillet 2026 supprime les sessions imposées entre clients et serveurs. Cette refonte simplifie la répartition des requêtes sur plusieurs instances, mais impose des adaptations aux applications conçues pour les versions précédentes.
Des requêtes indépendantes du serveur
Jusqu’ici, un client utilisant le Model Context Protocol devait établir une session avec un serveur, qui lui attribuait un identifiant pour les appels suivants. Dans une infrastructure composée de plusieurs instances, les requêtes devaient être renvoyées vers celle ayant ouvert la session ou s’appuyer sur un stockage partagé.
La révision 2026-07-28 retire l’échange d’initialisation ainsi que l’en-tête Mcp-Session-Id. Chaque requête contient désormais les informations nécessaires à son traitement et peut être prise en charge par n’importe quelle instance disponible derrière un répartiteur de charge.
L’état passe sous la responsabilité de l’application
Une application peut toujours conserver des informations entre plusieurs appels, par exemple pour suivre un document, une opération ou une navigation. Cet état n’est toutefois plus associé automatiquement à une session MCP.
Le serveur doit désormais créer un identifiant explicite, demander au client de le transmettre lors des appels suivants et contrôler sa validité. Les applications qui utilisaient l’identifiant de session dans leur propre logique devront donc adapter leur fonctionnement.
Des appels plus faciles à administrer
La nouvelle spécification introduit les en-têtes Mcp-Method et Mcp-Name, qui précisent la méthode appelée et l’outil sollicité. Les passerelles et les répartiteurs de charge peuvent ainsi reconnaître les requêtes sans analyser leur contenu complet. Certaines réponses peuvent aussi indiquer leur durée de validité et leur périmètre de mise en cache. La propagation du standard W3C Trace Context est formalisée afin de suivre un appel depuis l’application d’origine jusqu’aux services interrogés par le serveur MCP.
Les échanges persistants disparaissent
Lorsqu’une confirmation ou une donnée complémentaire est nécessaire, le serveur ne maintient plus un flux ouvert avec le client. Il renvoie une réponse signalant l’intervention attendue, puis le client renouvelle l’appel avec les informations demandées et un identifiant permettant de reprendre l’opération.
Les traitements longs sont désormais gérés par une extension dédiée. Le serveur fournit un identifiant de tâche que le client utilise pour consulter son état ou demander son annulation.
Une rupture de compatibilité
La version 2026-07-28 n’est pas directement compatible avec les implémentations précédentes. Les développeurs doivent mettre à jour leurs SDK, retirer les mécanismes liés aux sessions MCP et adapter les fonctions reposant sur des notifications spontanées ou des connexions persistantes.
Les serveurs qui continuent à utiliser l’ancien fonctionnement peuvent recevoir des clients compatibles avec les versions antérieures, mais doivent refuser les requêtes au format 2026-07-28 ou demander au client de revenir à une révision prise en charge.
