Sampling, roots et logging dépréciés : par quoi les remplacer
MCP 2026-07-28 déprécie trois primitives. Ce que ça change vraiment, dans quel ordre traiter la sortie, et pourquoi ce n'est pas le chantier urgent.
La révision 2026-07-28 fait passer trois capacités en déprécié : roots, sampling et logging. Dans les SDK, elles sont marquées comme obsolètes, avec un pointeur vers leur remplacement.
Avant d'ouvrir le chantier, un point de calendrier qui change tout : le protocole s'est doté d'une politique formelle de cycle de vie. Une fonctionnalité dépréciée reste fonctionnelle au moins douze mois avant d'être retirée, et les dépréciations sont suivies publiquement avec des échéances. Tu n'es donc pas dans la même urgence que pour le transport.
Sépare les deux chantiers. Le transport a une contrainte de compatibilité immédiate, les dépréciations ont une date connue à l'avance. Traiter les deux dans le même sprint est la meilleure façon de rater le premier.
Cela dit, il y a une raison de ne pas trop attendre, et elle est pratique : du code déprécié qui compile mais qui échoue à l'exécution coûte plus cher à déboguer dans six mois qu'à supprimer aujourd'hui, quand tu as encore le contexte en tête.
Sampling : le seul qui change une architecture
C'est celui qui fait mal, parce qu'il déplace un coût.
Le sampling permettait à un serveur de demander au client de faire tourner un modèle pour lui. Le serveur n'avait ni clé d'API ni facture d'inférence : il empruntait celles de l'application hôte. C'est aussi ce qui faisait sa fragilité, parce que ça ne marchait que si l'hôte avait un modèle configuré, et échouait silencieusement sinon.
Sans sampling, un serveur qui a besoin d'un modèle appelle un fournisseur directement, ou passe par une couche d'inférence unifiée qu'il gère lui-même.
Les conséquences à anticiper :
Tu deviens responsable du coût d'inférence. Ce qui était payé par l'utilisateur via son application hôte arrive sur ta facture. Si ton produit est gratuit ou à bas prix, ça peut suffire à casser ton modèle économique. À vérifier avant d'écrire la moindre ligne.
Tu deviens responsable des secrets. Une clé de fournisseur de modèle à stocker, à faire tourner, à surveiller.
Tu deviens responsable de la latence et des pannes. Ton outil dépend maintenant d'un service externe que tu ne contrôles pas. Il faut un timeout, un comportement de repli et une surveillance.
Tu dois le dire. Si tes données utilisateur partent maintenant vers un fournisseur de modèle que tu as choisi, ça se documente dans ta politique de confidentialité. C'est aussi ce qu'un dossier de soumission à un annuaire de connecteurs va regarder.
Le piège classique : laisser les chemins de sampling en place comme code mort. Ça compile, donc ça a l'air inoffensif, et ça lève à l'exécution le jour où quelqu'un passe par là. Supprimer est plus rapide que déboguer plus tard.
Roots : rendre le contexte explicite
roots permettait au client d'indiquer au serveur les emplacements auxquels il donnait accès.
La direction générale de la spec s'applique ici comme ailleurs : ce qui était implicite et porté par la connexion devient explicite et porté par la requête. Le périmètre sur lequel un outil travaille devient un argument déclaré dans son schéma, éventuellement sous forme de handle émis par le serveur.
Pour la mécanique exacte de remplacement, va lire le pointeur [Obsolete] de ton SDK plutôt que de deviner. Les SDK indiquent le remplacement recommandé pour chaque capacité dépréciée, et c'est plus fiable que n'importe quel article de blog, celui-ci compris.
Ce qui compte pour ta conception : un outil qui devine son périmètre est un outil qui se trompera. Un outil qui le reçoit en paramètre est testable, et son autorisation est vérifiable.
Logging : passer à ta propre observabilité
Le logging au niveau protocole servait à faire remonter des messages du serveur vers le client.
En pratique, la plupart des équipes qui exploitent un serveur MCP en production ont déjà leur pile d'observabilité, et le logging protocole faisait doublon. La dépréciation te pousse vers la solution que tu utilisais probablement déjà : logs structurés côté serveur, traces, métriques par outil.
C'est le remplacement le plus facile des trois, et il se combine bien avec les nouveaux en-têtes Mcp-Method et Mcp-Name, qui te permettent enfin de découper toutes tes métriques par outil.
Attention à un point : si tu utilisais le logging protocole pour renvoyer de l'information utile à l'utilisateur, par exemple la progression d'un traitement long, ce n'est pas un problème d'observabilité mais un problème de produit. Regarde du côté de l'extension Tasks, qui est faite pour les traitements longs.
Le plan de sortie
- Inventorie chaque usage des trois capacités, dans le serveur et dans les clients maison
- Traite le sampling en premier, parce que c'est le seul qui a un impact de coût et de conformité
- Supprime les chemins morts pendant que tu as le contexte, même si la date limite est lointaine
- Vérifie les pointeurs
[Obsolete]de ton SDK pour les remplacements exacts - Mets une alerte dans ton calendrier sur la date de retrait annoncée, pas sur « un jour »
FAQ
Est-ce que mon serveur casse le jour de la dépréciation ?
Non. Déprécié veut dire fonctionnel avec une date de retrait, et la politique garantit au moins douze mois.
Est-ce que je peux garder le sampling si mes clients le supportent encore ?
Techniquement oui pendant la fenêtre. Mais tu construis sur une base qui a une date de péremption connue, et tu devras faire la migration de toute façon. La seule question est de savoir si tu la fais quand tu choisis ou quand tu subis.
Comment je suis ces échéances sans y passer mes vendredis ?
Les dépréciations sont suivies publiquement, et le protocole exige maintenant une suite de conformité. Le minimum viable est de brancher une vérification de conformité dans ta CI et de surveiller le changelog. C'est exactement ce que couvre la veille de conformité.
Tu ne veux pas suivre les SEP toi-même
La veille de conformité, c'est 290 € par mois : je surveille les évolutions du protocole, je te dis ce qui concerne ton serveur, et je te préviens avant que ça devienne urgent. Pas de rapport de vingt pages, juste ce qui te concerne.
Intéressé ? Discuter de la veille de conformité →
Lectures liées
Un serveur MCP à faire auditer ?
Cinq minutes pour le décrire. Je réponds sous 24 heures ouvrées avec un premier diagnostic écrit et gratuit.
Faire auditer mon serveur MCP