En tant que co-responsable de XMLUI, je suis extrêmement sensible aux agents qui tâtonnent lorsqu’ils créent des applications XMLUI. Lorsque quelque chose qui devrait être une évidence ne l’est pas, parce que la recherche MCP n’a pas trouvé la réponse qu’elle aurait dû avoir, je dépose un problème, puis je demande à un agent de rédiger le document manquant.
Ce nouveau document est un correctif testable. Par exemple, j’ai demandé à Claude de trouver ses recherches échouées pour la conversion de sélection en radio dans le journal MCP. La réponse :
Deux recherches pratiques, toutes deux à 21h12, toutes deux manquées :
« Entrée du formulaire de valeur de changement de choix de groupe radio mutuellement exclusif » – principaux succès : utiliser un formulaire personnalisé, préremplir un formulaire à partir d’une réponse API, utiliser la validation regex dans un formulaire. Bruit adjacent à la forme, contenu radio nul.
« Choisissez l’une des deux options de sélecteur horizontal » – la reformulation quelques instants plus tard, en attaquant du côté UX au lieu du côté composant. Rien non plus.
Les recherches ayant échoué n’avaient renvoyé que des correspondances faibles avec un score de pertinence élevé autour de 0,7. Après avoir ajouté le nouveau document, je lui ai demandé de répéter la recherche et de comparer. Le nouveau document s’est classé n°1 avec un score de 4,2, six fois plus élevé que tout le reste. (Étant donné que le serveur MCP peut épingler la version des documents qu’il consulte, une comparaison A/B directe est possible.) J’ai également essayé une poignée de requêtes synthétiques, comme des « boutons radio pour un petit ensemble d’options ». Ceux-ci ont confirmé le résultat.
