MCP 2026-07-28 : le cœur sans état et ses limites de compatibilité

Ce que c'est

État au 25 octobre 2026. La révision MCP 2026-07-28, annoncée le 28 juillet 2026, modifie le cycle de vie du protocole. Consulter à nouveau le journal des modifications de cette version, les règles de compatibilité, les spécifications des extensions et le registre de dépréciation avant toute mise à niveau ; l’annonce de la version fournit une vue d’ensemble, et non le contrat complet des échanges sur le réseau.

Cette révision supprime initialize, notifications/initialized et les sessions HTTP au niveau du protocole, y compris Mcp-Session-Id. Chaque requête déclare sa version et les capacités du client dans _meta. Les serveurs doivent implémenter server/discover ; les clients peuvent l’appeler pour une découverte préalable ou envoyer directement une autre requête. La « découverte facultative » désigne le choix du client, et non une exemption pour le serveur. Ces distinctions découlent de la spécification de gestion des versions.

Pourquoi c'est important

L’établissement de la connexion ne fournit plus de contexte aux opérations suivantes. Un déploiement doit distinguer l’état du transport de l’état applicatif, par exemple celui d’une tâche de longue durée. Les clients existants utilisant l’ancienne négociation ont besoin d’un mode de compatibilité ; modifier uniquement une chaîne de version ne convertit pas leurs messages.

L’annonce de la version décrit la motivation opérationnelle : les requêtes peuvent atteindre différentes instances de serveur sans affinité de session. Cet avantage ne dispense pas l’application de stocker elle-même son état persistant.

Comment l'appliquer

• Inventorier les hypothèses sur le cycle de vie. Remplacer le contexte implicite de la connexion par des métadonnées de requête. Pour un état partagé entre plusieurs appels, exposer des références applicatives explicites comme arguments des outils. Conserver une voie distincte pour l’ancien fonctionnement lorsque les clients antérieurs restent pris en charge.
• Traiter les résultats intermédiaires. Les requêtes à plusieurs allers-retours, Multi Round-Trip Requests, remplacent les requêtes indépendantes initiées par le serveur. Un résultat input_required demande des informations ; le client répète l’opération d’origine avec inputResponses. Les résultats ordinaires utilisent resultType: "complete". Les réponses de versions antérieures dépourvues de ce champ sont traitées comme complètes.
• Mettre à jour l’intégration HTTP. Implémenter les en-têtes de méthode et, lorsque cela s’applique, de nom, et utiliser subscriptions/listen pour les notifications de changement activées explicitement. La progression d’une requête continue d’être transmise sur le flux de réponse de cette requête. La reprise et la retransmission SSE sont supprimées : la récupération nécessite une nouvelle requête avec un nouvel identifiant, ainsi que des protections au niveau applicatif contre la répétition d’effets de bord.
• Implémenter les métadonnées de cache. Le journal des modifications exige ttlMs et cacheScope sur les résultats de listes et de ressources désignés. Traiter la fraîcheur et l’autorisation de partage comme des décisions distinctes ; aucune des deux ne signifie que chaque réponse peut être mise en cache publiquement.
• Déclarer explicitement les extensions. Les extensions annoncent leur prise en charge au moyen de tables de capacités, sont désactivées par défaut et nécessitent une activation explicite par le développeur. Les tâches passent du cœur expérimental à une extension officielle. Confirmer leur prise en charge des deux côtés plutôt que la déduire de la version du cœur.
• Suivre le cycle de vie des fonctionnalités. Active, Deprecated et Removed sont des états distincts. La période minimale normale de dépréciation est de douze mois ; la politique autorise une exception de sécurité approuvée avec un délai d’au moins quatre-vingt-dix jours. Vérifier la fiche de la fonctionnalité concernée avant de planifier sa suppression.

Pièges

Ne pas interpréter l’absence d’état comme une interdiction des réponses en streaming ou des enregistrements applicatifs persistants. Ne pas supposer que chaque extension est livrée avec chaque SDK conforme : la prise en charge des extensions est facultative et évolue séparément. Enfin, la suppression de l’ancienne négociation dans cette révision n’autorise pas à retirer les mécanismes de compatibilité tant que des clients plus anciens en dépendent.