Évaluations pour WebMCP

Kasper Kulikowski

Publié le 19 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 évaluation.

Avant de mettre des outils en production, vous devez vous assurer que les agents comprennent quand les appeler, comment les 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 paramètres appropriés pour répondre à l'intention utilisateur.
• Vérifiez 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 sont réussis. 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 utiliser les outils comme prévu.

Les outils WebMCP peuvent échouer et l'agent peut échouer avec les outils WebMCP. Supposons, par exemple, 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.	La description de l'outil est-elle claire, complète et reflète-t-elle 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 induit le LLM en erreur quant à la séquence requise ? La sortie d'un outil précédent fournit-elle le contexte nécessaire pour l'appel d'outil suivant ? 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'appels d'outils spécifique de manière isolée en forçant les appels précédents à 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 requis sont-ils explicitement marqué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 se passe-t-il 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 affiche le coût total du panier au lieu des noms de produits et des 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'interface utilisateur 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 des appels ultérieurs, est-elle clairement formatée pour l'ingestion par le LLM ? La sortie est-elle trop détaillée ? Ne contient-elle que les informations essentielles minimales dont le LLM a besoin pour l'action suivante ?

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 d'exécution et exceptions 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 en bon état ?
• La structure de l'erreur est-elle suffisamment claire pour que le modèle puisse faire la différence entre un problème temporaire (nouvelle tentative) et une défaillance 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 dans un parcours utilisateur complexe.

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

CONSEIL : Vous pouvez déclencher un appel d'outil WebMCP using navigator.modelContext.executeTool(...).

Mesurer la précision des appels

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

La fonction expectedCall définit la fonction et l'argument attendus. Cette approche confirme que l'agent choisira le bon outil pour prendre en charge l'intention 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 est utilisé pour effectuer un test déterministe basé sur des règles :

Vous pouvez associer vos outils WebMCP au cycle de vie d'un composant, ce qui signifie que vous devez tester lorsque l'état de votre application correspond à ce que WebMCP attend. Pour gérer cela, fournissez une liste complète des outils pertinents pour l'état que vous souhaitez évaluer. Par exemple, un utilisateur navigue en même temps que 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 avec précision chacun de ces outils, vous devez inclure tous les outils afin de créer un état simulé et complet.

REMARQUE : Un agent peut avoir accès à des outils supplémentaires, mais vous ne pouvez évaluer que les outils que vous fournissez.

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

Exécuter des tests déterministes

Étant donné que les outils WebMCP sont créés avec JavaScript ou sous forme d'annotations HTML, vous pouvez écrire des tests déterministes pour effectuer les tâches suivantes :

• Vérifier la logique de l'outil.
• Confirmer que les dépendances ont été appelées correctement.
• Confirmer que l'interface utilisateur a été mise à jour comme prévu, ainsi que tout autre effet secondaire intentionnel.
• Vérifier que les informations renvoyées correspondent à la valeur attendue.
• Valider 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 possibles. 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 qui demandent spécifiquement ce que fait l'outil, ou une requête ambiguë qui implique qu'un outil doit être utilisé. 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 ingrédients 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 base et des requêtes ouvertes qui testent le raisonnement du modèle et la logique de sélection des outils.

Si vous gérez un café, vous pouvez aider les utilisateurs qui demandent à leur agent de commander à nouveau 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 une simulation 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 mener à bien leurs parcours. En plus de tester les outils individuels, vous vérifiez également que les actions en plusieurs étapes sont effectuées dans le bon ordre.

Supposons que 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 donner la liste des matériaux utilisés ?"

Un parcours agent réussi peut se présenter comme suit :

1. Accédez à la catégorie Vêtements.
2. Recherchez l'un des vêtements demandés (l'ordre n'a pas d'importance).
3. Recherchez un article spécifique (search_clothes).
4. Obtenez les détails du produit contenant 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 d'abord la veste noire ou le jean, l'ordre n'a pas d'importance. Toutefois, les autres étapes doivent être suivies de manière séquentielle.

É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 au niveau de add_discount_coupon et passe à la caisse pour une pizza au prix plein. 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, afin de simuler ce scénario. Amenez votre application à l'état où vous prévoyez que l'outil échouera. Dans ce cas, c'est après 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érimentaux sur GitHub.
• Consultez notre cours Créer des évaluations d'IA.