MCP Roots, Sampling et Logging : migrations après leur dépréciation dans 2026-07-28

Ce que c'est

État au 25 octobre 2026. La révision 2026-07-28 déprécie Roots, Sampling et Logging. Vérifier de nouveau leurs avis respectifs, le registre des fonctionnalités dépréciées et la politique de cycle de vie avant de supprimer le code de compatibilité. Le registre indique que leur suppression peut intervenir au plus tôt dans la première révision publiée à partir du 2027-07-28. Cette date ouvre la possibilité d'une future modification de la spécification ; elle ne fixe pas un arrêt automatique.

Les fonctionnalités dépréciées restent dans la spécification. Les nouvelles implémentations devraient éviter de les adopter ; les implémentations existantes devraient migrer. Les calendriers de suppression dans les SDK sont définis séparément. La politique générale autorise également une procédure accélérée documentée pour les risques de sécurité répondant aux critères prévus ; le délai habituel de douze mois n'est donc pas une garantie inconditionnelle en toutes circonstances.

Pourquoi c'est important

Ces trois fonctionnalités répondent à des besoins différents. Roots indique les emplacements pertinents du système de fichiers, Sampling délègue au client une requête destinée à un modèle et Logging transmet les notifications de journalisation du protocole. Leur remplacement peut transférer des responsabilités entre le client, le serveur et l'exploitant. Une migration qui se limite à supprimer les indicateurs de capacité peut laisser des fonctions nécessaires sans implémentation.

Roots a explicitement un rôle informatif : MCP n'impose aucun confinement dans le système de fichiers. Sampling donne actuellement au client le contrôle de l'accès aux modèles et des permissions. Logging au niveau du protocole est distinct des journaux d'exploitation du serveur. Préserver ces distinctions lors du choix des remplacements.

Comment l'appliquer

• Remplacer Roots par un contexte explicite. Les options documentées sont les paramètres d'outils, les URI de ressources ou une configuration du serveur décrivant les répertoires et les fichiers. Valider les chemins et les permissions dans le composant qui y accède. Préserver le consentement de l'utilisateur et des contrôles d'accès appropriés ; un répertoire fourni ne prouve pas que l'appelant est autorisé à le lire. Tant que Roots est conservé dans cette révision, annoncer la capacité dans chaque requête et échanger roots/list via le mécanisme de demande d'entrée.
• Remplacer Sampling par une intégration directe avec le fournisseur. La spécification recommande une intégration directe aux API des fournisseurs de modèles de langage. Traiter cela comme un changement de responsabilité, et non comme un simple changement de nom sans effet : documenter le composant qui obtient l'accès au modèle et les données qu'il envoie. L'ancienne interface Sampling permettait un contrôle côté client et recommandait une validation humaine. Conserver une validation équivalente lorsque l'application l'exige et tester le scénario de refus. Pendant la transition, déclarer les capacités Sampling dans chaque requête et éviter les options dépréciées de contexte entre serveurs.
• Diriger les journaux d'exploitation vers une destination appropriée. Les voies documentées sont stderr pour les transports stdio et OpenTelemetry pour l'observabilité structurée. Exclure les secrets et les informations personnelles des messages de journalisation et contrôler l'accès aux journaux collectés. Si la compatibilité nécessite encore Logging au niveau du protocole, le serveur déclare logging ; les clients demandent un niveau avec io.modelcontextprotocol/logLevel dans _meta.
• Tester la journalisation propre à chaque requête. Un serveur ne doit pas émettre notifications/message lorsque la requête n'a pas indiqué de niveau. Les messages autorisés appartiennent au flux de réponse de cette requête, jamais au flux d'abonnement. Vérifier que le niveau de détail choisi par un client ne peut pas affecter la requête d'un autre client.
• Supprimer chaque dépendance séparément. La procédure de déploiement proposée consiste à recenser les consommateurs, introduire le remplacement, vérifier que le même parcours autorisé fonctionne, puis seulement cesser d'annoncer la capacité dépréciée. Conserver les éléments indiquant quels clients en ont encore besoin.

Pièges

L'intégration directe à un modèle ne reprend pas automatiquement l'interface de consentement de l'ancien client. Une nouvelle destination de journalisation ne préserve pas automatiquement le masquage des données sensibles. Un paramètre de chemin ne crée pas un bac à sable. La dépréciation justifie une planification soigneuse de ces changements, pas un affaiblissement de leurs contrôles.