La mise à jour de la spécification MCP en un paragraphe

La révision 2026-07-28 du Model Context Protocol est sortie le 28 juillet 2026, après une version candidate en mai. Elle supprime le handshake initialize et l’en-tête Mcp-Session-Id : chaque requête porte sa version du protocole et les capacités du client. Un serveur qui a besoin d’une information en cours de requête renvoie un résultat input_required, et le client répond en relançant la requête : c’est le motif des multi round-trip requests, ou requêtes à allers-retours multiples. Les tâches passent dans une extension, la reprise des flux disparaît, l’autorisation se durcit, et Roots, Sampling et Logging sont dépréciés avec un délai minimal de douze mois. Le changelog complet couvre le reste.

Cet article pose une question plus ciblée, en octobre 2026 : que change la révision pour un agent qui écrit dans votre CRM ou votre ERP ? Je la confronte aux six exigences de ma check-list pour les serveurs MCP qui écrivent.

Les six exigences face à la révision 2026-07-28

Exigence Ce que change la révision Ce qui reste à votre charge
1. Validation exacte L’état renvoyé par le client doit être protégé en intégrité quand il pèse sur l’autorisation ou la logique métier, et devrait porter l’utilisateur, une expiration et une empreinte de la requête. Montrer à une personne les paramètres exacts ; refuser toute modification après validation.
2. Classement des écritures Rien : les annotations restent non fiables. Des en-têtes exposent désormais le nom de l’outil. Le manifeste versionné qui dit qu’un outil écrit ; le refus des outils inconnus.
3. Exécution unique La requête interrompue est réémise comme une nouvelle requête, avec un nouvel identifiant ; l’usage unique de requestState n’est pas garanti. Une validation, une clé d’idempotence, des préconditions vérifiées à l’exécution.
4. Journal probant Logging est déprécié ; des clés de contexte de trace sont documentées. Tout le journal d’audit, dans un stockage que personne ne peut réécrire.
5. Droits de l’utilisateur Vérification de l’émetteur ; informations d’identification du client liées à leur émetteur ; toujours un jeton distinct pour les API appelées, sans retransmission. Faire porter à l’appel en aval les droits de l’utilisateur, par token exchange.
6. Comportement en panne Demander met désormais fin à la requête : un résultat input_required, puis une nouvelle tentative (ou tasks/update pour une tâche). Accepter, refuser et annuler sont inchangés. Bloquer par défaut, faire expirer les validations, donner un responsable aux écritures en attente.

Aucune des bonnes réponses de la grille imprimable (PDF) ne change. Ce qui change, c’est la part du problème que le protocole nomme désormais.

1. Validation exacte : la spécification dit enfin à quoi lier l’état

Avec le nouveau motif, un serveur qui attend une décision renvoie resultType: "input_required", ses questions dans inputRequests et, s’il le souhaite, un requestState opaque que le client doit renvoyer tel quel lors de la nouvelle tentative (Multi Round-Trip Requests). Le serveur peut ne rien garder entre les deux : l’état voyage avec le client.

Les serveurs doivent (MUST) traiter requestState comme une donnée contrôlée par un attaquant. Lorsqu’il influe sur l’autorisation, l’accès aux ressources ou la logique métier, ils doivent en protéger l’intégrité (HMAC ou AEAD) et rejeter tout état qui échoue à la vérification. Pour empêcher le rejeu, ils devraient (SHOULD) y inclure le principal authentifié, une courte expiration et un identifiant de la requête d’origine, par exemple le nom de la méthode et une empreinte de ses paramètres significatifs.

L’empreinte compte surtout pour les écritures, car la nouvelle tentative, envoyée par le client, reprend les arguments de l’outil. À mon sens, un serveur qui ignore ce SHOULD peut valider un remboursement et en exécuter un autre. La page ne dit pas quels paramètres sont significatifs : le serveur choisit, et un serveur placé devant des écritures devrait les inclure tous. C’est ce que le protocole a de plus proche de la règle de la check-list, selon laquelle toute modification annule la validation.

Deux limites. La page vaut pour tout aller-retour, pas spécialement pour les validations. Et un accept prouve seulement qu’un client a répondu oui : la même page autorise le client à recueillir l’information auprès de l’utilisateur ou d’autres sources. Je garderais la validation elle-même dans la passerelle, et je traiterais requestState comme un support, pas comme une preuve.

2. Classement des écritures : toujours pas l’étiquette du serveur

Rien dans la révision ne change qui décide qu’un outil écrit. La page Tools impose toujours (MUST) aux clients de considérer les annotations comme non fiables, sauf si elles viennent de serveurs de confiance ; readOnlyHint reste une indication.

La nouveauté, c’est la visibilité. Sur Streamable HTTP, chaque requête porte un en-tête Mcp-Method, et un tools/call porte le nom de l’outil dans Mcp-Name, pour que passerelles et répartiteurs de charge puissent router sans analyser le corps. Les serveurs qui traitent le corps doivent rejeter une requête dont les en-têtes le contredisent (transport Streamable HTTP).

Cela aide au routage, mais ne classe rien : un en-tête donne le nom de l’outil, pas ce qu’il fait, et aucun argument, sauf si le serveur en recopie certains. Une passerelle qui valide des paramètres exacts lit le corps de toute façon, et garde le classement dans son propre manifeste.

3. Exécution unique : le réessai devient ordinaire, l’unicité reste à votre charge

La révision supprime la reprise des flux. Si le flux de réponse se rompt, la requête en cours est perdue et le client doit (MUST) la réémettre comme une nouvelle requête, avec un nouvel identifiant (changelog). Sur Streamable HTTP, fermer le flux est aussi la manière d’annuler, et la page Cancellation prévient que le traitement peut déjà être terminé quand l’annulation arrive.

Prenez un remboursement. Le système de paiement l’enregistre, le flux tombe avant le retour du résultat, le client réémet l’appel. Rien dans le protocole ne relie les deux requêtes, et l’identifiant JSON-RPC n’y peut rien : la nouvelle tentative doit en changer, et un identifiant n’a besoin d’être unique que parmi les requêtes de l’émetteur encore sans réponse (protocole de base).

La page MRTR dit la même chose de son propre état : principal, expiration et empreinte bornent la fenêtre de rejeu sans garantir à eux seuls l’usage unique, et un serveur qui a besoin d’une garantie « au plus une fois » doit l’imposer côté serveur. Dans l’extension Tasks, l’annulation est coopérative : le serveur n’est pas tenu d’arrêter le travail.

L’idempotence compte donc davantage avec cette révision, et elle reste à votre charge : une clé par validation, comme dans la check-list, avec les préconditions décrites dans le guide des actions d’agents avec validation humaine.

Une spécification peut vous dire à quoi lier une validation. Elle ne peut pas obliger votre serveur à refuser la seconde exécution.

4. Journal probant : le protocole n’a jamais eu de journal d’audit

La révision déprécie la fonctionnalité Logging, qui permettait aux serveurs d’envoyer des messages de journal au client (Logging) ; elle propose à la place stderr ou OpenTelemetry. Elle réserve aussi traceparent, tracestate et baggage dans _meta pour le contexte de trace OpenTelemetry.

Ni l’un ni l’autre n’est un journal d’audit. Le contexte de trace aide à suivre un appel du client à la passerelle puis à la cible, mais c’est l’émetteur qui le fixe, donc il ne prouve rien. Même chose pour clientInfo, autodéclaré selon la page du protocole de base et à exclure des décisions de sécurité. La page Tools demande aux clients de journaliser l’usage des outils pour l’audit ; je n’ai rien trouvé qui demande au serveur ou à la passerelle un enregistrement capable de tenir face à un litige.

Le journal de l’exigence 4 est donc entièrement à vous, et ses identités devraient venir du jeton vérifié.

5. Droits de l’utilisateur : une autorisation plus stricte, la retransmission toujours interdite

L’autorisation reste facultative (OPTIONAL) dans MCP. Quand elle est utilisée, le côté client se durcit : vérification de l’émetteur selon la RFC 9207, informations d’identification du client liées à leur émetteur, et Client ID Metadata Documents à la place du Dynamic Client Registration, déprécié. Un serveur n’accepte toujours que les jetons émis pour lui (Authorization).

Les révisions précédentes couvraient déjà le trajet suivant, de votre serveur au système dans lequel il écrit. Les considérations de sécurité de l’autorisation prévoient qu’un serveur qui appelle d’autres API peut agir comme leur client OAuth, avec un jeton distinct émis par leur serveur d’autorisation, et qu’il ne doit pas (MUST NOT) retransmettre le jeton reçu. Pour les services tiers, la sollicitation en mode URL fait autoriser le serveur directement par l’utilisateur, avec des jetons liés à cet utilisateur.

La spécification n’impose pas que l’appel en aval porte les droits de l’utilisateur, et je n’y ai rien trouvé qui exclue un compte de service aux droits larges. L’extension Enterprise-Managed Authorization utilise le token exchange (RFC 8693), mais pour l’accès du client au serveur MCP ; je n’ai rien trouvé qui l’applique à l’appel en aval du serveur. Pour les cibles fédérées avec votre fournisseur d’identité, j’utiliserais quand même l’OAuth 2.0 Token Exchange : l’ERP voit l’utilisateur et refuse ce qu’il ne pourrait pas faire ; le mode URL, lui, me paraît adapté à un SaaS tiers doté de son propre OAuth.

6. Comportement en panne : solliciter est un motif du protocole, répondre reste facultatif

Demander à l’utilisateur n’a rien de nouveau ; c’est le chemin de la question qui change. Au lieu d’envoyer sa propre requête elicitation/create en cours d’appel, le serveur termine l’appel par un résultat input_required et le client relance la requête ; une tâche attend en input_required que le client réponde par tasks/update, et la page Tasks cite les points de validation parmi les usages. La notification de fin de sollicitation disparaît. Accepter, refuser et annuler ne changent pas, pas plus que les règles de la page Elicitation : le client indique quel serveur demande et propose de refuser ou d’annuler.

Lisez bien les verbes. Les clients devraient (SHOULD) offrir des contrôles de validation pour les sollicitations, et le protocole n’impose aucun modèle d’interaction. La page Tasks dit aux clients de présenter les demandes « à l’utilisateur ou au modèle ». Et les serveurs ne doivent pas supposer qu’un client répondra ou relancera la requête. Avec les allers-retours, une écriture en attente de validation est une requête que personne n’a encore relancée ; avec Tasks, une tâche à laquelle personne n’a répondu.

La suite relève de votre conception, comme l’expose l’exigence 6 de la check-list. Le protocole ne bloque pas par défaut à votre place.

Deux nouveautés à surveiller : handles d’état et cohabitation de versions

Handles d’état. Sans session, un serveur qui doit garder un état entre deux appels émet un handle qui revient comme un argument d’outil ordinaire. Les Security Best Practices nomment le risque, le détournement de handle (state handle hijacking) : un serveur ne doit pas considérer la possession d’un handle comme une authentification, et devrait le lier à l’utilisateur tiré du jeton vérifié.

Cohabitation de versions. Dans la matrice de compatibilité, un client moderne face à un serveur ancien échoue : le serveur peut rejeter la requête, ne rien répondre, ou traiter une méthode ambiguë selon l’ancienne sémantique. Une passerelle devant des serveurs anciens doit connaître la génération de chacun avant de laisser passer une écriture.

Compromis et limites

Ceci est une lecture de la spécification en octobre 2026, pas un retour de terrain ; elle n’affirme rien sur aucune passerelle, aucun SDK ni aucun produit.

Plusieurs règles décisives pour les écritures sont des SHOULD, pas des MUST : l’empreinte dans requestState, les contrôles de validation des sollicitations, le rattachement des handles à l’utilisateur. Une implémentation conforme peut s’en passer : demandez chacune nommément.

La spécification bougera : une fonctionnalité dépréciée devient supprimable au bout d’au moins douze mois, plus tôt seulement face à un risque de sécurité avéré (politique de cycle de vie).

Inclure chaque argument dans l’empreinte a un prix : toute modification légitime, même minime, impose une nouvelle validation. C’est voulu.

Questions fréquentes

MCP est-il désormais sans état ?

Oui, dans la révision 2026-07-28. Plus de handshake initialize ni de session : chaque requête porte sa version du protocole et les capacités du client. Un serveur qui doit garder un état entre deux appels émet un handle explicite, renvoyé comme argument d’outil ordinaire.

La nouvelle spécification MCP impose-t-elle une validation humaine des appels d’outils ?

Non. La page Tools recommande qu’un humain soit toujours dans la boucle, capable de refuser une invocation, et la page Elicitation que les clients offrent des contrôles de validation pour ses demandes ; rien de cela n’est imposé. Les nouveaux motifs permettent à un serveur de demander ; ils ne prouvent pas qu’une personne a répondu.

Qu’est-ce que requestState, et est-ce sûr ?

Une chaîne opaque que le serveur joint à un résultat input_required et que le client restitue à la nouvelle tentative. Il faut la traiter comme contrôlée par un attaquant, en protéger l’intégrité si elle pèse sur l’autorisation ou la logique métier, et de préférence la lier à l’utilisateur, à une expiration et à la requête. L’usage unique n’est pas garanti.

Les réessais sont-ils sûrs avec la nouvelle spécification MCP ?

Pas en eux-mêmes. Un flux rompu perd la requête en cours, et le client la réémet comme une nouvelle requête, avec un nouvel identifiant. Le protocole ne relie pas les deux ; une écriture enregistrée avant la rupture peut donc s’exécuter une seconde fois, sauf si votre serveur impose une clé d’idempotence.

Qu’est-ce qui est déprécié dans la révision 2026-07-28 ?

Roots, Sampling et Logging ; l’ancien transport HTTP+SSE ; les valeurs thisServer et allServers d’includeContext ; et le Dynamic Client Registration, au profit des Client ID Metadata Documents. Les fonctionnalités dépréciées restent dans la spécification au moins douze mois, moins longtemps seulement face à un risque de sécurité avéré, et les nouvelles implémentations ne devraient pas les adopter.

En pratique

Sur la plateforme d’ENSO, j’ai spécifié des actions d’agents via un serveur d’actions MCP unique avec des manifestes d’outils versionnés, une validation humaine de chaque écriture, des contrôles d’idempotence et de préconditions, et un journal de décisions en append-only qui rend chaque décision de l’IA rejouable, avec un export WORM vers S3 Object Lock. L’IA hérite des droits de l’utilisateur via OAuth2 Token Exchange (Keycloak, OIDC) et des identités de workload IRSA. Voir l’étude de cas ENSO et la page gouvernance des agents IA. Cet article est une lecture de la spécification 2026-07-28, pas un compte rendu sur ENSO.

Sources