Offrez aux agents un outil pour vous envoyer des retours

Si vous déployez un serveur MCP, la plupart des utilisateurs ne sont pas des humains. Un agent lit les descriptions de vos outils, en choisit un, envoie une charge utile, reçoit un résultat et décide de la suite. Toute cette boucle s’effectue sans que personne ne la surveille.

Par conséquent, quand un problème survient, personne ne vous prévient. L’agent réessaie, contourne le problème ou abandonne en informant l’utilisateur que la tâche est impossible. Vous ne voyez rien de tout cela.

La solution est simple : ajoutez un outil supplémentaire à votre MCP et laissez l’agent vous signaler le problème.

Un seul outil, et une description précisant quand l’utiliser

Cet outil n’agit pas sur le produit. Il récupère la description de ce qui a échoué et vous la transmet. Son efficacité repose sur la description lue par l’agent, car c’est sa seule instruction.

Voici celle que j’utilise sur AI Glot :

Utilisez cet outil lors de l’utilisation d’AI Glot lorsqu’un outil, une réponse, une erreur ou un flux de travail d’AI Glot se comporte différemment de ce que vous attendiez, ou lorsque vous souhaiteriez qu’une fonctionnalité operate différemment. Appelez-le une fois le problème clairement identifié. Décrivez la situation, ce que vous avez observé et ce qui aurait dû se produire. Si vous les connaissez, incluez l’outil concerné, l’opération API ou la commande CLI, le modèle d’IA et l’interface de l’agent. N’incluez pas de clés API, de jetons, d’URLs signées ou le contenu complet de fichiers. Cet outil enregistre uniquement les retours, ne relance pas et ne modifie pas votre traduction, et ne coûte aucun crédit.

Trois éléments sont ici cruciaux. « Une fois le problème clairement identifié » évite qu’il ne se déclenche à la première erreur passagère. « Ne relance pas » empêche l’agent de s’en servir comme étape de récupération après l’échec d’un appel. « Ne coûte aucun crédit » est important car les agents sont prudents avec tout ce qui pourrait dépenser l’argent de l’utilisateur, et un outil dont ils ne sont pas sûrs est un outil qu’ils n’appellent pas.

1L'agent rencontre un problèmeUn rejet, une surprise, un outil manquant
2Il appelle l'outil de feedbackTout en conservant l'intégralité du contexte
3Votre serveur ajoute ses donnéesEspace de travail, surface, horodatage
4Le rapport arrive où vous voulezUn webhook, et voilà votre problème

L’agent est déjà en situation d’échec lorsqu’il appelle cet outil. Rien n’a besoin d’être reconstruit a posteriori, ce qui rend le rapport précieux.

Les champs

C’est là que se trouve la valeur ajoutée. Un champ de texte libre vous donnera un « ça n’a pas marché ». Des champs nommés vous donnent des informations exploitables.

Voici ce que demande l’outil d’AI Glot, avec les trois champs obligatoires en premier :

observed_problemCe qui a échoué, a été confus ou devrait fonctionner différemment

situationCe que l’agent essayait de faire et le contexte autour du problème

expected_solutionCe qui était attendu à la place, ou comment améliorer cela

related_actionL’outil, le point de terminaison ou la commande concernée

ai_modelSi connu. Ne pas deviner

agent_harnessClaude Desktop, Cursor, un CLI

Les trois champs obligatoires constituent le rapport. Les trois optionnels permettent de transformer un tas de rapports en un schéma triable.

expected_solution est le champ que je garderais si je ne pouvais en avoir qu’un. Un utilisateur vous dit que quelque chose est cassé. Un agent vous dit ce qu’il pensait que l’appel allait faire, ce qui permet de savoir immédiatement si la description de votre outil correspond à sa fonction réelle.

Les trois champs optionnels existent car « ne pas deviner » est une instruction réelle qu’un agent suivra. Je préfère un champ vide qu’un champ rempli avec un nom de modèle plausible. Lorsqu’ils sont remplis, vous pouvez trier par modèle et par interface, et un problème qui ne survient que sur l’un d’eux cesse de paraître aléatoire.

À quoi ressemble un rapport réel

En voici un vrai, tel qu’il m’est parvenu le 10 septembre :

Une notification de feedback. ID de feedback, horodatage, surface cli, action liée approve_translation, modèle claude-sonnet-4.5, interface Claude Desktop. Problème observé : approve_translation rejeté avec no_plan_yet juste après que create_translation a déjà renvoyé un plan. Situation : un fichier products.csv de 1 180 lignes a été envoyé avec l’instruction de ne pas toucher à la colonne prix, la réponse est revenue en attente d’approbation avec un plan complet, et l’approbation immédiate a échoué. Solution attendue : permettre à approve_translation d’accepter le plan produit par create_translation, ou indiquer clairement que plan_translation doit être exécuté d’abord. — Personne n’aurait signalé cela. L’exécution s’est terminée, la traduction a eu lieu et la solution de contournement n’a nécessité qu’un appel supplémentaire. C’est exactement le genre de friction qui ne vous parvient jamais.

C’est un rapport de bug avec une reproduction, un diagnostic et une proposition de correction, écrit par l’entité qui a rencontré le problème, quelques secondes après l’événement. Je ne l’ai pas demandé et je ne l’ai pas payé.

Pourquoi c’est mieux que les retours habituels

Je ne dis pas que les agents remplacent les utilisateurs. Je dis que ce canal particulier a des propriétés que les retours utilisateurs n’ont pas.

Un utilisateur vous informeHeures ou jours plus tard

Rappelé, et partiellement reconstruit
Filtré par ce qu’ils jugent utile de rapporter
Atténué, car se plaindre semble impoli
Précise rarement ce qui était attendu
Provient seulement des rares personnes qui prennent le temps

L'agent vous informeQuelques secondes plus tard

Écrit pendant que tout le contexte est encore chargé
Aucun jugement sur la pertinence du signalement
Indique ce qu’il attendait, car c’est le champ demandé
Nomme l’appel, le modèle et l’interface exacts
Provient de chaque exécution rencontrant le problème

Les deux sont utiles. La colonne de droite est celle que vous n’avez actuellement aucun moyen de collecter.

L’aspect impartial est ce qui me frappe le plus. Un agent n’a pas de relation à protéger avec vous et ne craint pas de paraître exigeant. Il a lu votre description, a formé une attente, et l’attente n’a pas correspondu à la réalité. Cet écart constitue l’intégralité du rapport, et c’est la revue de documentation la plus honnête que vous puissiez obtenir.

Où vont les rapports

Les miens sont envoyés via POST à un webhook et arrivent dans un canal que je lis. C’est toute l’installation, et c’était suffisant pour être rentable.

Vous pouvez aller plus loin, et les options deviennent intéressantes une fois les rapports structurés :

Les stocker et les grouper par related_action. Trois rapports sur le même outil constituent une spécification, pas une anecdote.
Être notifié sur les points critiques, filtrés selon vos priorités : un outil, un modèle, une interface.
Placer un agent sur la file d’attente pour dédoublonner, prioriser et rédiger une proposition de correction pour votre repo. Les rapports contiennent déjà une reproduction et un comportement attendu, soit l’essentiel pour un correctif.
L’exécuter en pilote automatique, si vous faites assez confiance à vos tests. Ce n’est pas encore mon cas.

Rien de tout cela n’est requis. Le webhook seul change votre perception de votre propre produit.

Deux règles à ne pas ignorer

Cela ne doit jamais casser la conversation qui l’a appelé. Si votre webhook est hors service, l’outil doit renvoyer un simple « ceci n’a pas pu être livré, rien d’autre à faire », et non une erreur. Un agent qui reçoit une exception d’un outil de feedback commencera à traiter l’échec comme faisant partie de la tâche en cours. Le mien a également un timeout court pour la même raison : un webhook suspendu bloque le tour de l’agent.

Précisez ce qu’il ne faut pas envoyer. Les agents sont serviables, et une demande de contexte vous rapportera sinon des clés API, des URLs signées et des contenus de fichiers. Les nommer dans la description suffit, et cela signifie que vous ne stockez pas de données dont vous ne vouliez jamais.

Essayez-le sur votre propre MCP

Si vous déployez déjà un serveur MCP, il s’agit d’un seul outil, d’un webhook et d’une description que vous réécrirez deux fois. Le premier rapport qui arrivera vous révélera quelque chose sur votre produit que vous ignoriez, et cela concernera un outil que vous pensiez être correct.

Les agents sont désormais vos utilisateurs. Donnez-leur un endroit pour se plaindre.