MCP supprime les sessions et déplace votre facture d'inférence

Ce qui est sorti le 28 juillet

Le Model Context Protocol a publié sa cinquième spécification le 28 juillet, et c'est le plus grand changement depuis la naissance du protocole. Le noyau est désormais sans état. La négociation entre initialize et initialized disparaît, l'en-tête Mcp-Session-Id est retiré, et chaque requête transporte à la place la version du protocole, l'identité du client et ses capacités dans un champ _meta. L'effet pratique, c'est qu'un simple répartiteur de charge round robin suffit : n'importe quelle instance peut servir n'importe quelle requête, et il n'y a plus aucun magasin de sessions à exploiter.

Plusieurs autres pièces découlent de ce choix. Les Multi Round-Trip Requests remplacent les appels lancés par le serveur qui exigeaient jusqu'ici un flux maintenu ouvert : au lieu de pousser une requête dans un canal ouvert, le serveur renvoie un type de résultat input_required et le client rejoue l'appel d'origine avec ses réponses jointes. Les requêtes Streamable HTTP portent maintenant les en-têtes Mcp-Method et Mcp-Name, afin qu'une passerelle ou un limiteur de débit puisse router et compter sans analyser le corps JSON. Les résultats de liste d'outils, d'invites et de ressources portent une durée de vie et une portée de cache. Tasks et MCP Apps rejoignent un cadre formel d'extensions au lieu de siéger dans le noyau.

Les chiffres d'adoption expliquent pourquoi cela dépasse le cercle de ceux qui écrivent des serveurs. Les SDK de premier rang pour TypeScript, Python, Go et C sharp approchent ensemble les 500 millions de téléchargements par mois, et les paquets TypeScript et Python ont chacun franchi le milliard de téléchargements cumulés. David Soria Parra, l'un des principaux responsables de la maintenance, l'a qualifiée de publication la plus importante depuis le lancement de remote MCP il y a plus d'un an. Si votre entreprise a acheté ces dix-huit derniers mois un produit qui relie un assistant à vos systèmes, cette spécification se trouve dessous, qu'on vous en ait donné le nom ou non.

Le retrait de Sampling déplace une facture d'inférence

La liste des dépréciations se lit comme un ménage de printemps : Roots, Sampling et Logging, tous assortis d'une fenêtre de douze mois. Deux d'entre eux sont réellement mineurs. Roots devient des chemins de répertoires et de fichiers passés en paramètres d'outil ou fixés dans la configuration du serveur. Logging s'en va vers la sortie d'erreur standard ou vers OpenTelemetry, là où la plupart des exploitants le voulaient de toute façon. Sampling relève d'un autre ordre, et d'un ordre qui touche un budget plutôt qu'une base de code.

Sampling était le mécanisme par lequel un serveur MCP pouvait demander au client d'exécuter une complétion de modèle pour son compte. Le serveur avait besoin de la sortie d'un modèle de langage sans avoir à détenir d'identifiants, puisque c'est le client qui réalisait l'inférence et qui la payait. C'est un véritable partage commercial exprimé sous forme de fonction de protocole. La note de migration publiée pour les serveurs qui perdent Sampling invite à s'intégrer directement aux interfaces d'un fournisseur de modèles côté serveur. Lue par un exploitant, la conséquence est nette : celui qui fait tourner le serveur a désormais besoin de son propre compte fournisseur, de sa propre clé et de sa propre ligne budgétaire.

Le sens dans lequel l'argent se déplace dépend du siège que vous occupez. Si vous exploitez des serveurs MCP pour vos propres équipes face au client d'un fournisseur, une inférence que vous ne payiez pas atterrit sur votre compte, et pour un déploiement de taille moyenne il s'agit d'un nouvel engagement mensuel à quatre chiffres en euros et non d'une erreur d'arrondi. Si vous consommez le serveur MCP d'un fournisseur, attendez-vous à une révision tarifaire, car un coût qu'il poussait jusqu'ici vers votre client devient le sien. Rien de tout cela n'est annoncé dans une note de version. Les deux apparaissent sur une facture en moins d'un an.

Sans état a déplacé l'état, il ne l'a pas effacé

Les commentaires des fournisseurs autour de cette publication portent uniformément sur l'échelle, et ils viennent des entreprises qui gagnent le plus quand les serveurs deviennent faciles à héberger : des acteurs du cloud et de la périphérie décrivant le protocole comme routable, mémorisable en cache et capable de monter en charge à l'échelle mondiale, et des plateformes saluant la fin de la gestion des sessions. Tout cela est exact. Abandonner l'affinité qui rattachait chaque session à une même instance supprime une classe de pannes où un flux interrompu détruisait la conversation entière, et cela permet de faire tourner un serveur sur une infrastructure sans serveur qui n'aurait jamais pu maintenir une session ouverte.

Ce qu'aucun d'eux ne dit, c'est que l'état ne s'est pas évaporé. Tout ce qui doit véritablement persister d'un appel à l'autre doit désormais être représenté explicitement : le serveur émet un identifiant - celui d'un panier, un jeton, une référence de processus - et le renvoie dans un résultat pour que le client le retransmette. C'est une conception saine, mais elle transforme une préoccupation invisible du protocole en une partie visible de vos contrats d'outils. Quelqu'un doit décider ce que signifient ces identifiants, combien de temps ils durent et ce qui se passe quand un client en rejoue un périmé. Ce travail n'a pas disparu avec l'en-tête de session. Il s'est déplacé dans vos schémas, où il revient à votre équipe de le réussir.

Inscrivez le 28 juillet 2027 dans le plan

La règle qui gouverne est que tout ce qui est marqué comme déprécié reste fonctionnel au moins douze mois. Cela fait du 28 juillet 2027 la première date à laquelle Roots, Sampling, Logging, l'enregistrement dynamique des clients ou l'ancien transport en HTTP et SSE peuvent réellement être retirés, et c'est la seule date de cette publication qui mérite d'être inscrite dans une feuille de route. Rien ne casse cette semaine. Les changements d'autorisation restent malgré tout les premiers à lire : les serveurs d'autorisation doivent maintenant renvoyer un paramètre d'émetteur et les clients doivent le valider avant d'échanger un code, les identifiants de client sont liés au serveur qui les a émis, et l'enregistrement dynamique des clients laisse la place aux Client ID Metadata Documents.

Pour une exploitation européenne, la pièce sur laquelle agir tôt est l'Enterprise Managed Authorization, qui arrive sous forme d'extension et permet à l'administration d'attribuer l'accès aux serveurs MCP de façon centralisée via un fournisseur d'identité. Jusqu'ici, l'autorisation dans les déploiements MCP était souvent reléguée à la fin, et c'est précisément pour cela que tant de projets internes d'agents se sont enlisés à la revue de sécurité. Si le vôtre en fait partie, la raison de l'enlisement est désormais traitée dans la spécification, et l'étape honnête consiste à demander à vos fournisseurs quand ils prendront en charge l'extension plutôt qu'à attendre qu'on vous le dise.

À lire ensuite: Un seul message a atteint les clés SSH  |  Anthropic demande ses puces à un fabricant de mémoire