Votre agent IA patine sur un outil « summarize ». Deux secondes s’évaporent. C’est le code ? L’API ? Ou — invisible — le LLM délégué par le serveur ?
Pour les devs qui assemblent des workflows agentiques, c’est le lot quotidien des serveurs MCP. Sans visibilité sur les appels d’échantillonnage, c’était du pile ou face sur les performances. Désormais ? Les traces éclairent ces fantômes, les métriques dévoilent la vérité dans un tableau de bord, et l’optimisation n’a plus rien de magique.
Pourquoi l’échantillonnage MCP cassait vos traces
Les spécifications MCP autorisent les serveurs — sans clés API propres — à refiler le boulot LLM aux clients. Malin, non ? Votre orchestrateur lance « summarize » ; le serveur a besoin de GPT-4o pour mâcher le texte ; il échantillonne le LLM client. La réponse revient. Délégation propre.
Mais les traces ? Silence radio. Le middleware capture bien les appels d’outils. L’échantillonnage ? Une invocation enfouie dans les entrailles du handler. Pas de span. Un outil à 2,1 secondes dont 1,8 se consument en génération — invisible. Vous bidouillez les mauvaises 300 ms.
« L’appel d’outil déclenche un appel LLM invisible dans la trace. Le middleware de l’article #7 traque tools/call summarize — mais l’appel d’échantillonnage à l’intérieur ? Fantôme. Pas de span, pas de durée, pas de nom de modèle. »
C’était la boîte noire qu’ils ont ouverte la dernière fois. Ceci ? La suite qui rend ça prêt pour la démo.
On connaît le film. Les microservices naissants étouffaient sur des RPC intraçables — rappelez-vous l’ascension de Zipkin ? L’échantillonnage MCP, c’est le RPC de l’IA agentique. L’ignorer, et vos outils virent des mystères distribués. Le corriger maintenant, et vous prenez l’avance sur l’essaim multi-agents à venir.
Comment ils ont emballé ces appels fantômes
Quatre ajustements. Simples à mourir.
D’abord, toadEyeMiddleware pour les bases — des spans sur chaque outil.
Ensuite, le wrapper traceSampling autour de ctx.mcpReq.requestSampling(). Passez le modèle, les jetons. Boum : span SpanKind.CLIENT nommé « chat gpt-4o ». Capture la durée (1834 ms !), gen_ai.request.model, même mcp.server.name.
Imbrication parfaite :
tools/call summarize 2,1 s └── chat gpt-4o (échantillonnage) 1,8 s
Logique réelle ? 300 ms. Optimisez ça, pas les spectres.
Le code ? Une import en une ligne. Dans le handler : wrappez votre échantillonnage. Cinq minutes pour tester — serveur lancé, agent client qui pingue, traces qui affluent vers votre backend OTel.
Mais les métriques ? C’est là que ça devient précis comme Bloomberg. Requêtes Prometheus intégrées. Pas de compteurs flous.
Le tableau de bord qui répond « Qu’est-ce qui coince ? »
Tableau synthétique en haut :
Taux d’appels d’outils | Durée moyenne | Taux d’erreurs | Lectures ressources 12,4 req/s | 45,2 ms | 2,3 % | 3,1 req/s
Rouge sur les erreurs ? Plongez dedans.
Séries temporelles pour les taux par outil. L’agent bascule de calculate vers search ? Les courbes le montrent. Durées P50/P95 par outil — P95 de search qui grimpe à 2 s ? Alerte pager duty.
Erreurs empilées : RateLimitError sur search (8,7 %), Validation sur calculate (0 %). Ressources par URI — sources de données chaudes qui hurlent.
En bas : tableau fusionné par outil.
| Outil | Taux | Moy. (ms) | P95 (ms) | Erreurs |
|---|---|---|---|---|
| calculate | 8,2 | 12,3 | 24,1 | 0 % |
| get-weather | 3,1 | 145,2 | 312,8 | 3,2 % |
| search | 1,1 | 890,4 | 2134 | 8,7 % |
Pas de chichi. C’est la vue conseil d’administration : coûts corrélés aux durées, erreurs aux fuites de revenus. Faites scaler vos agents ? Vous remercierez ces quatre stats.
Le moment Zipkin pour les agents IA ?
Mon atout : personne ne le dit, mais l’observabilité MCP traîne des kilomètres derrière LangChain — ces écosystèmes traquent tout, battage ou pas. La spec MCP plus pure brille, mais les outils masquaient des pépites comme l’échantillonnage.
Prédiction ? À mesure que les agents ench
