Ce qui change
Annoncée le 28 juillet 2026, la révision MCP 2026-07-28 tranche ce que sa release candidate laissait ouvert, et sa réponse la plus discrète m’a surpris. Tasks quitte le noyau expérimental pour l’extension io.modelcontextprotocol/tasks, avec un tasks/get par scrutation et un nouveau tasks/update (SEP-2663) 1. Les notifications de changement quittent l’ancien point d’entrée HTTP GET pour un flux unique subscriptions/listen, auquel le client s’abonne type par type 1. Quant à la version du protocole, elle voyage désormais dans un en-tête : chaque requête porte Mcp-Protocol-Version 2.
L’en-tête décide du protocole servi
En couvrant la release candidate, je supposais qu’un désaccord de version se signalerait toujours. Sur la passerelle d’AWS, un cas reste muet. AWS décrit le comportement de sa passerelle AgentCore Gateway face à cet en-tête 2 :
| Requête | Comportement de la passerelle |
|---|---|
Version présente dans supportedVersions | Requête servie dans cette version |
| Version non prise en charge | HTTP 400, code -32022, et la liste des versions |
| Aucun en-tête | Repli sur 2025-03-26 |
Deux lignes font du bruit. La troisième coûte une journée : le client qui oublie l’en-tête n’y obtient pas d’erreur, mais une connexion fonctionnelle vers une révision vieille de seize mois, où ses capacités manquent en silence.
Tasks devient une surface à demander
Une extension se négocie, elle ne se suppose pas. Les traitements longs bâtis sur les primitives du noyau dépendent du pair qui implémente io.modelcontextprotocol/tasks 1, et tasks/update est une API que vous n’avez jamais appelée 1. Côté notifications, le mouvement inverse : un flux subscriptions/listen unique avec abonnement par type 1 pèse moins qu’un point d’entrée à scruter.
Impact pour une équipe
Si vous publiez un client MCP, émettez Mcp-Protocol-Version sur chaque requête dès cette semaine et verrouillez-le par un test, car la panne évitée est silencieuse 2. Si vous publiez un serveur, renvoyez les versions acceptées lors du rejet plutôt qu’un 400 sec, comme le fait cette passerelle 2. Sur Tasks, je ne migrerais pas encore : attendez que vos pairs annoncent l’extension, puis adoptez tasks/get avant tasks/update 1. Le déplacement des notifications est la pièce à faire tout de suite, car subscriptions/listen remplace du code de scrutation que vous maintenez déjà 1.