Évaluations pour WebMCP

Kasper Kulikowski

Publié le 19 mai 2026, dernière mise à jour le 28 mai 2026

WebMCP est compatible avec les agents qui utilisent des modèles d'IA générative. Pour tester un système utilisant l'IA générative, vos tests doivent prendre en charge les résultats probabilistes : une entrée peut générer des milliers de réponses avec des degrés de précision variables. Cette technique de test est appelée évaluations.

Avant de déployer des outils en production, vous devez vous assurer que les agents savent quand appeler l'outil, comment l'exécuter et quelles réponses sont acceptables. Anticipez les risques d'échec.

Rédigez des évaluations pour tester les points de contact de votre système avec un grand modèle de langage (LLM) :

• Vérifiez que le modèle comprend l'objectif de votre outil, en fonction de sa description et de son schéma.
• Vérifiez que le modèle choisit le bon outil avec les bons paramètres pour répondre à l'intention de l'utilisateur.
• Confirmez que le modèle agit en fonction des informations qu'il a reçues, par exemple pour utiliser des informations afin d'appeler un autre outil.
• Vérifiez que les parcours utilisateur fonctionnent correctement. Compte tenu de l'intention de l'utilisateur, un agent peut-il mener à bien le parcours utilisateur sur mon site Web à l'aide des outils fournis ?

Vous devez continuer à écrire des tests déterministes classiques pour toute interaction système qui ne communique pas avec le modèle.

Modes de défaillance

Les développeurs doivent tester leurs systèmes pour éviter les défaillances avant qu'elles ne se produisent. Pour ce faire, vous devez comprendre quand le système peut échouer, à la fois seul et en interagissant avec des facteurs externes. Pour WebMCP, l'outil lui-même peut échouer et les agents peuvent ne pas l'utiliser comme prévu.

Les outils WebMCP peuvent échouer, et l'agent peut échouer avec les outils WebMCP. Par exemple, supposons que votre utilisateur souhaite ajouter un t-shirt à son panier.

Échec	Exemple	Résoudre les problèmes
L'agent ne parvient pas à sélectionner le bon outil ou appelle directement le mauvais outil.	L'agent ignore addToCart et passe directement à checkout.	Le description de l'outil est-il clair, complet et reflète-t-il précisément ce que fait l'outil ? Le functionName est-il intuitif et descriptif ? L'outil est-il correctement exposé au LLM dans l'état/le contexte actuel ? Le schéma de cet outil est-il potentiellement trop semblable à celui d'un autre outil, ce qui entraîne une ambiguïté d'appel ?
L'agent appelle les outils dans le mauvais ordre.	L'agent appelle checkout, puis addToCart.	Les descriptions des outils se chevauchent-elles, ce qui pourrait induire le LLM en erreur quant à la séquence requise ? La sortie d'un outil précédent fournit-elle le contexte nécessaire pour le prochain appel d'outil ? L'état est-il correctement mis à jour et les nouveaux outils sont-ils exposés au LLM comme prévu ? Le cas d'utilisation de bout en bout est-il toujours correct si certains outils sont appelés dans un ordre différent ? Avez-vous testé la chaîne d'appel d'outil spécifique de manière isolée en forçant les appels précédents pour confirmer que le LLM choisit la bonne étape suivante ?
l'agent appelle l'outil avec des arguments incorrects.	L'agent appelle addToCart, mais ajoute des chaussures au lieu d'un t-shirt.	Le inputSchema est-il clairement défini, y compris les valeurs enum et une bonne description pour chaque propriété ? Tous les paramètres obligatoires sont-ils explicitement indiqués et vérifiés ? La description de l'argument guide-t-elle explicitement le LLM sur la façon de mapper l'entrée utilisateur aux données structurées attendues (telles qu'un ID ou un format spécifique) ?

Que faire si l'utilisateur souhaite vérifier le contenu de son panier ?

Échec	Exemple	Résoudre les problèmes
La sortie de l'outil est incorrecte ou l'outil manque quelque chose.	L'utilisateur demande viewCart, mais l'agent indique le coût total du panier au lieu des noms des produits et de leurs prix individuels.	La logique de l'outil sous-jacent comporte-t-elle des bugs (vérifiez avec des tests déterministes) ? L'état de l'UI a-t-il été correctement mis à jour et l'agent a-t-il reçu les bonnes informations sur l'effet secondaire ? Si la sortie est utilisée par le LLM pour les appels suivants, est-elle clairement mise en forme pour l'ingestion par le LLM ? Le résultat est-il trop détaillé ? Ne contient-il que les informations essentielles minimales dont le LLM a besoin pour la prochaine action ?

Enfin, un outil peut échouer de n'importe quelle manière que JavaScript échoue. Pour résoudre le problème, examinez les points suivants :

• Le code de l'outil gère-t-il correctement toutes les erreurs et exceptions d'exécution potentielles ?
• L'erreur est-elle signalée à l'agent et au modèle de manière optimale ?
• Les API ou services externes sur lesquels l'outil s'appuie sont-ils opérationnels ?
• La structure des erreurs est-elle suffisamment claire pour que le modèle puisse faire la différence entre un problème temporaire (nouvelle tentative) et un échec critique ?

Tester les outils de manière isolée

Si un agent ne parvient pas à déterminer l'outil à appeler pour une requête telle que "Je voudrais une petite pizza", il n'aura aucune chance de réussir un parcours utilisateur complexe.

En testant les outils de manière isolée, vous pouvez optimiser vos schémas et vos descriptions avant même d'exécuter une simulation de navigateur.

Mesurer la précision des appels

Découvrez notre démo WebMCP zaMaker. Lorsque l'utilisateur demande "Je voudrais une petite pizza", vous pouvez vous attendre à ce que le modèle réponde en indiquant l'intention d'effectuer un appel set_pizza_size avec l'argument "size":"Small".

La fonction expectedCall définit la fonction et l'argument attendus. Cette approche confirme que l'agent choisira le bon outil pour répondre à l'intention de l'utilisateur, en fonction du schéma fourni.

{
  "messages": [
    {
      "role": "user",
      "content": "I'd like a small pizza."
    }
  ],
  "expectedCall": [
    {
      "functionName": "set_pizza_size",
      "arguments": { "size": "Small" }
    }
  ]
}

expectedCall permet d'effectuer un test déterministe basé sur des règles :

Il est possible de lier vos outils WebMCP au cycle de vie d'un composant, ce qui signifie que vous devez effectuer des tests lorsque l'état de votre application correspond à ce que WebMCP attend. Pour gérer cela, fournissez une liste complète d'outils pertinents pour l'état que vous souhaitez évaluer. Par exemple, un utilisateur navigue avec son agent et ouvre WebMCP zaMaker.

[
...
  {
    "name": "add_topping",
    "description": "Add one or more toppings to the pizza",
    ...
  },
  {
    "name": "set_pizza_size",
    "description": "Set the pizza size directly.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "size": {
          "type": "string",
          "enum": [
            "Small",
            "Medium",
            "Large",
            "Extra Large"
          ],
          "description": "The specific size name."
        },
      }
    }
  },
  {
    "name": "set_pizza_style",
    "description": "Set the style of the pizza (colors/theme)",
  ...
  },
...
]

...
 "expectedCall": [
   {
     "functionName": "set_pizza_size",
     "arguments": { "size": "Small" }
   }
 ]
...

À l'ouverture, WebMCP expose les outils add_topping, set_pizza_size et set_pizza_style. Pour tester précisément l'un de ces outils, vous devez inclure tous les outils afin de créer un état complet simulé.

REMARQUE : Un agent peut avoir accès à des outils supplémentaires, mais la meilleure chose que vous puissiez faire est d'évaluer les outils que vous fournissez.

Maintenant que vous savez que l'agent appelle le bon outil selon les besoins, vous pouvez tester si l'appel d'outil comporte les bons paramètres et si le résultat est conforme aux attentes. Il y a deux étapes : les tests déterministes et les tests probabilistes.

Exécuter des tests déterministes

Comme les outils WebMCP sont conçus avec JavaScript ou sous forme d'annotations HTML, vous pouvez écrire des tests déterministes pour effectuer les tâches suivantes :

• Vérifiez la logique de l'outil.
• Vérifiez que les dépendances ont été appelées correctement.
• Vérifiez que l'interface utilisateur a été mise à jour comme prévu, ainsi que tous les autres effets secondaires intentionnels.
• Vérifiez que les informations renvoyées correspondent à la valeur attendue.
• Validez les paramètres de test.

Par exemple, si votre outil utilise une fonction SearchComponent, vous pouvez effectuer un test en transmettant une simulation de SearchComponent. N'oubliez pas de simuler l'environnement dans lequel l'outil fonctionne pour obtenir les meilleurs résultats possible. Il s'agit de la même technique que celle que vous utiliseriez pour écrire un autre test d'intégration d'application.

Exécuter des tests probabilistes

Si vous avez besoin d'une sortie de modèle pour appeler correctement les outils suivants, vous devez écrire des évaluations.

Les utilisateurs peuvent envoyer des requêtes directes au modèle pour lui demander spécifiquement ce que fait l'outil, ou des requêtes ambiguës qui impliquent l'utilisation d'un outil. Par exemple, "Ajoute du pepperoni à ma pizza" est une requête directe. "Je veux toute la viande sur ma pizza" est plus ambigu et nécessite que le modèle comprenne qu'il a besoin de l'outil add_topping et quels sont les ingrédients qui peuvent être définis comme de la viande.

Lorsque vous créez des ensembles de données pour vos évaluations, incluez à la fois des requêtes directes qui testent l'exécution de l'outil de référence et des requêtes ouvertes qui testent la logique de raisonnement et de sélection d'outil du modèle.

Si vous gérez un café, vous pouvez aider les utilisateurs qui demandent à leur agent de recommander le même café que celui qu'ils ont commandé le mois dernier. Écrivez un outil pour rechercher les commandes précédentes, OrderHistoryService, et un autre pour commander le café. Pour tester le service d'historique des commandes, vous pouvez envoyer un mock qui renvoie un ID de produit de café.

Dans cet exemple, vous évaluez si le modèle comprend l'intention de la requête, choisit le bon outil et si cet outil fournit les bonnes informations pour agir. Si le modèle n'appelle pas get_order_history, il ne saura pas quel item_id utiliser pour order_product.

Test de bout en bout

Écrivez des tests de bout en bout pour vous assurer que les utilisateurs et leurs agents peuvent effectuer leurs parcours avec succès. En plus de tester les outils individuels, vous vérifiez également que les actions en plusieurs étapes sont effectuées dans le bon ordre.

Par exemple, vous gérez une boutique de vêtements en ligne. Un utilisateur demande à son agent : "Je cherche à acheter une veste noire et un jean. Pourriez-vous me fournir une liste détaillée des matériaux utilisés ?"

Voici un exemple de parcours agentique réussi :

1. Accédez à la catégorie "Vêtements".
2. Trouvez l'un des vêtements demandés (l'ordre n'a pas d'importance).
3. Trouvez un élément spécifique (search_clothes).
4. Obtenez les informations détaillées sur le produit qui contiennent la liste des matériaux (get_product_details).
5. Répétez les étapes 2 à 4 pour chaque élément demandé.

Lorsque l'agent atteint l'étape 2, il peut rechercher la robe noire ou le jean en premier, l'ordre n'a pas d'importance. Toutefois, vous devez suivre les autres étapes dans l'ordre.

Écrivez une évaluation de bout en bout pour vérifier que l'agent appelle les outils dans l'ordre prévu :

{
  "messages": [
    {
      "role": "user",
      "content": "I am looking to buy a black jacket and a pair of jeans.
        Could you provide a breakdown of the materials used ?"
    }
  ],
  "expectedCall": [
    {
      "functionName": "navigate_to_category",
      "arguments": { "category": "clothes" }
    },
    {
      "unordered": [
        {
          "ordered": [
            {
              "functionName": "search_clothes",
              "arguments": { "query": "black jacket" }
            },
            {
              "functionName": "get_product_details",
              "arguments": { "productId": "JACKET002" }
            }
          ]
        },
        {
          "ordered": [
            {
              "functionName": "search_clothes",
              "arguments": { "query": "jeans" }
            },
            {
              "functionName": "get_product_details",
              "arguments": { "productId": "JEANS001" }
            }
          ]
        }
      ]
    }
  ]
}

Évaluer les échecs en milieu de chaîne

Il peut arriver qu'un agent doive appeler plusieurs outils de manière séquentielle. Que se passe-t-il si un outil échoue au milieu de ce processus ? Par exemple, un utilisateur souhaite commander une pizza avec son code promotionnel :

"Je voudrais une petite pizza au pesto. Utilise mon code promotionnel FreePizza."

Il est possible que l'agent échoue à l'étape add_discount_coupon et passe à la caisse pour une pizza à plein tarif. Pour tester l'outil add_discount_coupon, vous pouvez exécuter manuellement cette séquence d'appels d'outils, sans interagir avec un modèle, pour simuler ce scénario. Amenez votre application à l'état où vous prévoyez que l'outil échouera. Dans ce cas, il s'agit de l'outil start_checkout. Vous pouvez ensuite évaluer add_discount_coupon de manière isolée.

Tester WebMCP

Commencez à tester les évaluations pour les outils de manière isolée et à évaluer vos propres sites compatibles avec WebMCP à l'aide de n'importe quel agent compatible avec WebMCP :

• Téléchargez nos outils d'évaluation expérimentale sur GitHub.
• Consultez notre cours Créer des évaluations d'IA.