Migration MCP : quoi journaliser et vérifier avant la bascule
Dans ma proposition, chaque requête d’un serveur MCP sans état a sa propre ligne de log. Qu’y mettre, et que vérifier avant de basculer ?
EN 30 SECONDES
Une ligne de log par requête, c’est ma proposition pour auditer un serveur MCP sans état. Elle s’écrit que la requête réussisse ou non. Ensuite, une checklist en six étapes sort chaque type de données de session avant la bascule.
À RETENIR · 3
- Ma proposition : une ligne de log par requête, avec la méthode, l’outil, la version, le principal, la trace, les handles et le type de résultat.
- clientInfo est autodéclaré : journalisez-le comme une déclaration, jamais comme une identité.
- Un serveur qui ne gère que la nouvelle version exclut les anciens clients : ils ne peuvent pas passer d’eux-mêmes à la version récente. Décidez avant la bascule si vous servez les deux.
Sur cette page
Ce qu’un serveur MCP devrait journaliser à chaque requête
EN BREF Ma proposition : des contrôles dans un ordre fixe, et une ligne de log par requête, qu’elle réussisse ou non.
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
- Principal
- L’utilisateur ou le service au nom de qui agit une requête, indiqué par son jeton d’accès.
- clientInfo
- Le nom et la version que le client déclare sur lui-même. Le protocole ne les vérifie pas.
- Identifiant de trace
- Un identifiant porté par la requête, pour relier ses lignes de log dans différents systèmes.
- Affinité de session
- Un réglage du répartiteur de charge (sticky sessions) qui garde un client sur la même instance.
Sans session, plus de journal de session : on doit pouvoir reconstituer le fil de chaque requête à partir de sa seule ligne.
CONTRÔLES À CHAQUE REQUÊTE
Étape 1. Arrivée. Une requête arrive, sur n’importe quelle instance.
- Arrivée Une requête arrive, sur n’importe quelle instance.
- Écart : refusé Le nom d’outil de l’en-tête diffère de celui du corps : HTTP 400, erreur -32020. La ligne de log s’écrit quand même.
- Informations obligatoires Version ou capacités absentes : -32602, HTTP 400. Version non gérée : -32022, avec la liste des versions acceptées.
- Appelant Le principal vient du jeton d’accès, jamais de clientInfo.
- Capacités Une capacité requise n’est pas déclarée : -32021.
- État scellé, handles Vérifier sceau, appelant, expiration et requête (cela limite le rejeu, sans le rendre à usage unique), et à qui appartient chaque handle.
- Exécuter et journaliser Succès ou échec, une ligne est écrite.
EN CLAIR
La ligne dit ce qui a été appelé, dans quelle version, par qui (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 tiré du jeton) et avec quel résultat. clientInfo Le nom et la version que le client déclare sur lui-même. Le protocole ne les vérifie pas. Voir le glossaire y figure comme une déclaration, jamais comme une identité.
C’est le volet transport de la piste d’audit. L’autre volet, la décision, est décrit dans « Prouver le travail d’un agent à un auditeur ». Mettez le même Identifiant de trace Un identifiant porté par la requête, pour relier ses lignes de log dans différents systèmes. Voir le glossaire dans les deux pour les relier.
La checklist de migration que j’appliquerais
EN BREF Ma proposition en six étapes : lister l’état, trancher pour les anciens clients, puis déplacer chaque type d’état hors du processus.
Lister chaque champ lié à la session
Cherchez l’identifiant de session, initialize et tout ce qui dépend de la connexion ou du processus.
Choisir : nouvelle version seule, ou les deux
Un serveur qui gère les deux générations PEUT (MAY) les servir sur le même point d’accès. Un serveur strictement moderne devrait lister ses versions dans l’erreur renvoyée en réponse à initialize.
Ajouter la découverte et les infos par requête
Implémentez server/discover, comparez en-têtes et corps, mettez un resultType sur chaque résultat.
Mettre l’appel en attente dans un état scellé
Passez de l’élicitation et du sampling à input_required. Liez l’état à l’appelant, à l’expiration et à la requête (cela limite le rejeu ; l’usage unique exige un contrôle côté serveur).
Mettre l’état durable derrière des handles
Stockage partagé, contrôle du propriétaire, expiration, et une clé d’idempotence sur chaque outil qui écrit.
Mettre en place le log, puis tester
Coupez l’affinité de session en préproduction, puis rejouez un enchaînement en plusieurs étapes. Si quelque chose casse, un état se cache peut-être encore dans un processus.
Je ne sauterais jamais l’étape 6. Affinité de session Un réglage du répartiteur de charge (sticky sessions) qui garde un client sur la même instance. Voir le glossaire peut masquer un état qui vit encore dans un processus.
OBJET OBTENU
Trancher d’abord pour les anciens clients
La feuille de route MCP (mise à jour le 22 août 2026) reflète « l’état actuel de la réflexion plutôt que des engagements fermes ». Le groupe Transports veut faire de Streamable HTTP le seul transport, même pour les serveurs locaux.
Un groupe Agent Identity, encore en formation, cite parmi ses priorités DPoP, la workload identity federation et l’échange de jetons RFC 8693. Sa raison : « l’appelant est de plus en plus souvent un agent ».
Sources : changelog, versionnage, Streamable HTTP, feuille de route, toutes lues le 7 octobre 2026.
FAQ
Non. Selon la matrice de compatibilité de la spécification, cette combinaison échoue, et l’ancien client ne peut pas passer à la version récente. Un serveur peut gérer les deux générations du protocole : initialize choisit les anciennes règles, et une requête qui porte le _meta moderne est traitée sans état.
Non. La version 2026-07-28 la marque obsolète (Deprecated) : elle marche encore pendant au moins 12 mois, et le changelog suggère stderr en mode stdio ou OpenTelemetry. Écrivez votre propre ligne par requête, que le client ait demandé un niveau de log ou non.
NIVEAU TERMINÉ
Ce que vous savez maintenant
- Pourquoi, dans ma proposition, chaque requête a sa propre ligne de log, et pourquoi clientInfo y figure comme une déclaration.
- Les six étapes de migration, et ce qu’il faut décider d’abord pour les anciens clients.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Votre test de préproduction passe avec l’affinité de session activée. Êtes-vous prêt pour la bascule ?
Pas encore. L’affinité garde un client sur une seule instance : un état caché dans un processus marche encore. Coupez-la et rejouez d’abord un enchaînement en plusieurs étapes.
Vous avez fini tous les niveaux publiés de cette série. Retour à la carte de la série
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.