Handles MCP : garder un travail entre deux appels, sans doublon
Votre import s’étend sur plusieurs appels d’outil, et après une coupure, le client renvoie une écriture. Comment le serveur garde-t-il le travail sans l’écrire deux fois ?
EN 30 SECONDES
Un handle est un identifiant que le serveur MCP émet pour un travail qui dure plusieurs appels, comme un import ; le client le repasse en argument d’outil. Dans ma conception, le serveur vérifie à qui il appartient, et une clé d’idempotence empêche qu’une écriture rejouée soit appliquée deux fois.
À RETENIR · 3
- Le changelog 2026-07-28 range l’état entre appels dans des « handles explicites, émis par le serveur et passés comme des arguments d’outil ordinaires ».
- Ma proposition : un handle est difficile à deviner, a un propriétaire et une expiration, et il est refusé si quelqu’un d’autre le présente.
- Un flux de réponse coupé se présente comme une nouvelle requête, avec un nouvel identifiant. Dans ma conception, c’est la clé d’idempotence, pas cet identifiant, qui repère la répétition.
Sur cette page
L’état entre appels devient un handle
EN BREF Dans ma conception, ce qui doit survivre à un appel vit dans votre stockage, et le client en renvoie le handle à chaque appel.
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
- Handle
- Un identifiant que le serveur émet pour un objet qui dure plusieurs appels, comme un import ou une tâche.
- Principal
- L’utilisateur ou le service au nom de qui agit une requête, indiqué par son jeton d’accès.
- Clé d’idempotence
- Une valeur qui désigne un travail précis, pour que le serveur repère une répétition et ne refasse pas ce travail.
- JSON-RPC
- Le format de message de MCP. Chaque requête indique la méthode, les paramètres et un identifiant.
Un import en plusieurs étapes, un brouillon construit sur plusieurs outils, une tâche longue : chacun a besoin de ce que le changelog appelle des « handles explicites, émis par le serveur et passés comme des arguments d’outil ordinaires ».
Indexé par session
Indexé par handle
Mes règles pour un Handle Un identifiant que le serveur émet pour un objet qui dure plusieurs appels, comme un import ou une tâche. Voir le glossaire, à titre de proposition : le serveur l’émet, et ce handle devrait être impossible à deviner. Le stockage garde son propriétaire, 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 qui l’a créé, et refuse tout autre appelant. Il a une date d’expiration.
LE CONTRÔLE DU PROPRIÉTAIRE
Étape 1. Un appel arrive. user-7 envoie un appel avec imp_7KQ2M9, un handle valide ouvert par user-42.
- Un appel arrive user-7 envoie un appel avec imp_7KQ2M9, un handle valide ouvert par user-42.
- Qui appelle ? Le jeton d’accès dit user-7.
- Pas le propriétaire : refusé D’après le stockage, le propriétaire est user-42 : le serveur rejette l’appel. Un handle valide ne donne aucun droit.
- Le propriétaire Quand user-42 l’envoie, le propriétaire correspond et le handle n’a pas expiré.
- Exécution L’outil s’exécute sur l’import stocké.
Traitez un handle comme n’importe quel argument non fiable. Le modèle, côté client, peut en coller un là où il n’a rien à faire. C’est la règle du moindre privilège pour les agents qui déplacent de l’argent : on contrôle à l’entrée du serveur.
Un exemple concret : une écriture reçue deux fois
EN BREF Dans ma conception, ce sont le handle et la clé d’idempotence, et non l’identifiant JSON-RPC, qui permettent de repérer une même écriture reçue deux fois.
La version 2026-07-28 supprime la reprise des flux. Si le flux de réponse se coupe, la spécification dit que le client « doit (MUST) réémettre la requête comme une nouvelle requête, avec un nouvel identifiant de requête ».
ADAM explique : Un outil qui modifie des données peut donc recevoir le même appel deux fois. Sans clé d’idempotence, une écriture peut devenir deux.
Dans ma conception, chaque outil qui écrit reçoit une Clé d’idempotence Une valeur qui désigne un travail précis, pour que le serveur repère une répétition et ne refasse pas ce travail. Voir le glossaire.
UN EXEMPLE CONCRET
Chiffres illustratifs
VALIDÉuser-42 ajoute des lignes à un import
ENTRÉE
- Appel
- append_rows, id 42
- Handle
- imp_7KQ2M9
- Clé d’idempotence
- b1c0e6
- Jeton d’accès
- user-42
CE QUI SE PASSE
- Le jeton identifie l’appelant : user-42.
- Le stockage indique que imp_7KQ2M9 appartient à user-42 et n’a pas expiré.
- La clé b1c0e6 est nouvelle pour ce handle : les lignes sont ajoutées.
SORTIE
- Résultat
- lignes ajoutées
PAS ÉCRIT DEUX FOISLe flux se coupe, le client renvoie l’appel
ENTRÉE
- Appel
- même appel, nouvel id 43
- Clé d’idempotence
- b1c0e6 (inchangée)
CE QUI SE PASSE
- Le nouvel identifiant JSON-RPC ne révèle pas la répétition : la spécification en impose un nouveau.
- Le serveur trouve b1c0e6 déjà enregistrée pour imp_7KQ2M9 et renvoie le résultat stocké.
SORTIE
- Lignes ajoutées
- aucune, la première écriture fait foi
EN CLAIR
L’identifiant JSON-RPC Le format de message de MCP. Chaque requête indique la méthode, les paramètres et un identifiant. Voir le glossaire sert toujours à relier une réponse à sa requête. L’outil, le handle et la clé relèvent de ma conception, avec des valeurs fictives.
Dans ma conception, la clé est enregistrée pour chaque handle, à côté du résultat de la première écriture.
OBJET OBTENU
La clé repère la répétition
Sources : changelog, Streamable HTTP, lues le 7 octobre 2026.
NIVEAU TERMINÉ
Ce que vous savez maintenant
- Pourquoi, dans ma conception, un handle valide ne donne aucun droit : le serveur vérifie à qui il appartient.
- Pourquoi l’identifiant JSON-RPC ne repère pas une écriture rejouée, et ce qui la repère.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Un client relance une écriture avec la même clé d’idempotence, mais un autre handle. Le serveur doit-il y voir une répétition ?
Non. Dans ma conception, la clé est enregistrée pour chaque handle : un autre handle, c’est un autre travail, dont le propriétaire est contrôlé comme pour tout appel.
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.