MCP sans session : demander une info en cours d’appel
Votre outil a besoin d’une réponse de l’utilisateur en plein appel, et la relance peut tomber sur une autre instance. Comment l’appel reprend-il là où il s’était arrêté ?
EN 30 SECONDES
Les Multi Round-Trip Requests (MRTR) sont la façon dont un serveur MCP pose une question en plein appel, dans la version 2026-07-28 : il renvoie input_required, et le client relance avec les réponses. Le travail inachevé peut voyager dans un requestState scellé, vérifié à chaque relance.
À RETENIR · 3
- MRTR remplace l’élicitation et le sampling que le serveur déclenchait : il renvoie input_required, et le client relance.
- Le requestState transite par le client : la spécification demande de le traiter comme contrôlé par un attaquant, et de le protéger, par exemple avec HMAC ou AEAD, s’il influence l’autorisation ou la logique métier.
- Le lier au principal et à la requête, avec une courte expiration, borne le rejeu. L’usage unique exige un contrôle côté serveur.
Sur cette page
Demander une information en cours d’appel, étape par étape
EN BREF Avec MRTR, le serveur peut confier son travail inachevé au client dans un requestState facultatif : la relance peut arriver sur n’importe quelle instance.
Ce que je marque comme proposition est mon avis, pas le standard. Le contrôle de l’appelant suppose un serveur HTTP qui vérifie chaque appel. Or la spec laisse l’autorisation au choix.
LES MOTS À CONNAÎTRE
- Élicitation
- La demande d’information que le serveur adresse à l’utilisateur au milieu d’un appel d’outil.
- requestState
- Un jeton facultatif et opaque que le serveur renvoie quand il lui faut une saisie. Le client le renvoie tel quel en relançant l’appel.
- Principal
- L’utilisateur ou le service au nom de qui agit une requête, indiqué par son jeton d’accès.
Élicitation La demande d’information que le serveur adresse à l’utilisateur au milieu d’un appel d’outil. Voir le glossaire passait par une requête envoyée sur un flux ouvert. Il fallait donc que le même processus soit encore là au retour de la réponse. Le sampling, où le serveur fait appel à un modèle via le client, marchait pareil.
Le mécanisme Multi Round-Trip Requests (MRTR) remplace les deux. Son but affiché : fonctionner
« sans exiger de couche de stockage partagée entre les instances du serveur ni de répartition de charge avec état ».
UN APPEL, DEUX INSTANCES
Étape 1. Premier appel. L’appli appelle un outil avec l’identifiant 1. Le répartiteur choisit l’instance A.
- Premier appel L’appli appelle un outil avec l’identifiant 1. Le répartiteur choisit l’instance A.
- Demande de saisie A répond input_required, avec une question et un requestState scellé. Puis elle oublie l’appel.
- Question à l’utilisateur L’appli interroge l’utilisateur et recueille ses réponses, les inputResponses.
- Relance L’appli renvoie le même appel avec un nouvel identifiant (2), les réponses et le requestState tel quel. La relance arrive sur B.
- Vérifier, puis répondre B vérifie le sceau, l’appelant, l’expiration et l’appel de départ, puis renvoie le résultat avec resultType complete.
- Modifié : refusé Une relance dont le requestState a été modifié échoue au contrôle du sceau. B la rejette et n’exécute rien.
La relance reçoit un nouvel identifiant : cet identifiant ne permet donc pas de la relier au premier appel. C’est l’empreinte de l’appel de départ, scellée dans l’état, qui s’en charge.
Le sampling est d’ailleurs marqué obsolète (Deprecated) dans la version 2026-07-28, comme Roots et Logging, avec une période d’au moins 12 mois. Ils marchent encore, mais les nouvelles implémentations ne devraient pas les ajouter.
Pourquoi le serveur vérifie l’état scellé
EN BREF Comme requestState transite par le client, les serveurs « doivent (MUST) traiter requestState comme une entrée contrôlée par un attaquant ».
S’il « influence l’autorisation, l’accès aux ressources ou la logique métier », le serveur doit le protéger contre toute modification, par exemple avec HMAC ou AEAD.
EN CLAIR
HMAC est un sceau calculé avec une clé secrète, qui révèle toute retouche. AEAD est un chiffrement qui la détecte aussi.
ADAM explique : Un sceau n’est pas un secret : avec HMAC seul, le client peut encore lire le contenu. S’il ne doit pas le lire, prenez AEAD.
Contre le rejeu (le même état renvoyé une deuxième fois), la spécification recommande de sceller trois choses dans cet état : le Principal L’utilisateur ou le service au nom de qui agit une requête, indiqué par son jeton d’accès. Voir le glossaire authentifié, une courte durée de vie et l’identifiant de la requête de départ.
OBJET OBTENU
Une entrée à traiter comme hostile
Ces liens bornent le rejeu, sans rendre l’état à usage unique. Un usage unique exige un contrôle côté serveur.
Le principal, tiré du jeton d’accès
L’expiration. Gardez-la courte
Méthode, nom de l’outil et empreinte des arguments de départ
Ce dont le serveur a besoin pour reprendre
Le nom de l’outil compte : tous les outils partagent la méthode tools/call. Calculez l’empreinte sur un encodage JSON canonique des arguments, pour que l’ordre des clés ne la change pas.
FAQ
HMAC garantit l’intégrité, pas le secret : une charge utile seulement encodée en base64 se décode. Si le client ne doit pas lire l’état, prenez AEAD. Mon conseil dans les deux cas : changez de clé à dates fixes, avec une période de chevauchement, car chaque instance doit vérifier ce qu’une autre a scellé.
NIVEAU TERMINÉ
Ce que vous savez maintenant
- Comment MRTR permet à n’importe quelle instance de finir un appel qui demandait une saisie.
- Pourquoi le serveur vérifie l’état renvoyé avant de s’y fier.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Le client d’un même utilisateur renvoie deux fois un requestState valide, inchangé, avant son expiration. Le sceau bloque-t-il la deuxième relance ?
Pas à lui seul. Le sceau prouve que personne ne l’a modifié, et l’expiration limite la fenêtre. Bloquer un deuxième usage exige que le serveur note que l’état a déjà servi.
Ancien CTO d’Integra. Auteur nommé (1 sur 5) d’ERC-3643, premier auteur d’ERC-6960, co-auteur d’ERC-7410 et co-auteur d’ERC-8203, encore à l’état de brouillon. Conçoit des systèmes d’IA en production et des systèmes Web3 régulés.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.