WebMCP testen met evaluaties

Kasper Kulikowski

Gepubliceerd: 19 mei 2026, Laatste update: 28 mei 2026

Uitleg	Web	Extensies	Chrome-status	Intentie
GitHub	Origin-proefperiode		Bekijken	Intentie om te experimenteren

WebMCP ondersteunt agenten die generatieve AI-modellen gebruiken. Als je een systeem wilt testen dat generatieve AI gebruikt, moeten je tests probabilistische uitkomsten ondersteunen: één invoer kan leiden tot duizenden antwoorden met verschillende nauwkeurigheidsniveaus. Deze testtechniek wordt evaluaties of evals genoemd.

Voordat u tools vrijgeeft voor productie, moet u bevestigen dat de agenten begrijpen wanneer ze de tool moeten aanroepen, hoe ze deze moeten uitvoeren en welke antwoorden acceptabel zijn. Pak mogelijke problemen aan voordat ze zich voordoen.

Schrijf evaluaties om de contactpunten van je systeem met een groot taalmodel (LLM) te testen:

• Controleer of het model het doel van je tool begrijpt op basis van de beschrijving en het schema.
• Verifieer dat het model de juiste tool met de juiste parameters kiest om de gebruiksintentie te ondersteunen.
• Bevestig dat het model reageert op informatie die het heeft gekregen, bijvoorbeeld om informatie te gebruiken om een ander hulpmiddel aan te roepen.
• Verifieer succesvolle gebruikerstrajecten. Kan een medewerker, gezien de intentie van de gebruiker, het gebruikerstraject op mijn website afronden met de beschikbare tools?

Je moet klassieke deterministische tests blijven schrijven voor elke systeeminteractie die niet met het model communiceert.

Foutmodi

Ontwikkelaars moeten hun systemen testen om storingen te voorkomen voordat ze optreden. Daarvoor moet je weten wanneer het systeem kan mislukken, zowel op zichzelf als in interactie met externe factoren. Voor WebMCP kan de tool zelf mislukken en kunnen medewerkers de tools niet gebruiken zoals verwacht.

WebMCP-tools kunnen mislukken en de agent kan mislukken met WebMCP-tools. Stel dat uw gebruiker een T-shirt aan de winkelwagen wil toevoegen.

Mislukt	Voorbeeld	Problemen oplossen
De agent selecteert niet de juiste tool of roept de verkeerde tool rechtstreeks aan.	De agent slaat addToCart over en gaat rechtstreeks naar checkout.	Is de description van de tool duidelijk, volledig en geeft deze nauwkeurig weer wat de tool doet? Is de functionName intuïtief en beschrijvend? Is de tool in de huidige staat/context correct beschikbaar voor het LLM? Is het schema van deze tool misschien te vergelijkbaar met een andere tool, waardoor er onduidelijkheid ontstaat over de aanroep?
De agent roept tools in de verkeerde volgorde aan	De agent belt eerst checkout en daarna addToCart.	Overlappen de toolbeschrijvingen elkaar, waardoor het LLM in de war raakt over de vereiste volgorde? Biedt de uitvoer van een eerdere tool de nodige context voor de volgende toolaanroep? Wordt de status correct geüpdatet en worden nieuwe tools zoals verwacht aan het LLM getoond? Is de use case van begin tot eind nog steeds correct als bepaalde tools in een andere volgorde worden aangeroepen? Heb je de specifieke tool-aanroepketen afzonderlijk getest door de voorgaande aanroepen te forceren om te bevestigen dat het LLM de juiste volgende stap kiest?
De agent roept de tool aan met onjuiste argumenten	De agent roept addToCart, maar voegt schoenen toe in plaats van een T-shirt.	Is de inputSchema duidelijk gedefinieerd, inclusief enum-waarden en een goede description voor elke property? Zijn alle vereiste parameters expliciet gemarkeerd en gecontroleerd? Begeleidt de beschrijving van het argument het LLM expliciet bij het toewijzen van gebruikersinvoer aan de verwachte gestructureerde gegevens (zoals een specifieke ID of indeling)?

Wat als de gebruiker wil checken wat er in de winkelwagen zit?

Mislukt	Voorbeeld	Problemen oplossen
De tooluitvoer is onjuist of de tool mist iets.	De gebruiker vraagt om viewCart, maar de medewerker geeft de totale kosten van de winkelwagen in plaats van de productnamen en afzonderlijke prijzen.	Bevat de onderliggende toollogica bugs (check met deterministische tests)? Is de UI-status correct geüpdatet en heeft de agent de juiste informatie over de bijwerking gekregen? Als de uitvoer door het LLM wordt gebruikt voor daaropvolgende aanroepen, is de uitvoer dan duidelijk opgemaakt voor LLM-opname? Is de uitvoer te uitgebreid? Bevat het alleen de minimale essentiële informatie die het LLM nodig heeft voor de volgende actie?

Ten slotte kan een tool op elke manier mislukken waarop JavaScript mislukt. Onderzoek het volgende om problemen op te lossen:

• Verwerkt de toolcode alle mogelijke runtime-fouten en -uitzonderingen correct?
• Wordt de fout op een goede manier teruggegeven aan de agent en het model?
• Zijn de externe API's of services waarop de tool vertrouwt, in orde?
• Is de foutstructuur duidelijk genoeg zodat het model onderscheid kan maken tussen een tijdelijk probleem (opnieuw proberen) en een kritieke fout?

Testtools geïsoleerd

Als een agent niet kan bepalen welke tool moet worden aangeroepen voor een verzoek als 'Ik wil een kleine pizza', heeft de agent geen kans in een complex gebruikerstraject.

Door tools afzonderlijk te testen, kunt u uw schema's en beschrijvingen optimaliseren voordat u een browsersimulatie uitvoert.

Gespreksnauwkeurigheid meten

Neem een kijkje bij onze demo, de WebMCP zaMaker. Als de gebruiker vraagt 'Ik wil een kleine pizza', kun je een modelreactie verwachten die aangeeft dat je een set_pizza_size-aanroep wilt uitvoeren met het argument "size":"Small".

De functie expectedCall definieert de verwachte functie en het argument. Deze aanpak bevestigt dat de agent de juiste tool kiest om de gebruikersintentie te ondersteunen op basis van het aangeleverde schema.

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

expectedCall wordt gebruikt om een regelgebaseerde, deterministische test uit te voeren:

Je kunt je WebMCP-tools koppelen aan de levenscyclus van een component. Dit betekent dat je moet testen als de status van je app overeenkomt met wat WebMCP verwacht. Als je dit wilt beheren, geef je een volledige lijst met tools die relevant zijn voor de status die je wilt evalueren. Een gebruiker browst bijvoorbeeld samen met een medewerker en opent 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" }
   }
 ]
...

Bij het openen biedt WebMCP toegang tot de tools add_topping, set_pizza_size en set_pizza_style. Als u een van deze afzonderlijke tools nauwkeurig wilt testen, moet u alle tools opnemen om een gesimuleerde, complete status te maken.

OPMERKING: Een medewerker heeft misschien toegang tot extra tools, maar het beste wat je kunt doen, is de tools die je aanbiedt evalueren.

Nu u weet dat de agent de juiste tool aanroept als dat nodig is, kunt u testen of de toolaanroep de juiste parameters heeft en of het resultaat is zoals verwacht. Er zijn 2 stappen: deterministische tests en probabilistische tests.

Deterministische tests uitvoeren

Omdat WebMCP-tools zijn gemaakt met JavaScript of als HTML-annotaties, kunt u deterministische tests schrijven om de volgende taken uit te voeren:

• Verifieer de logica van de tool.
• Bevestig dat afhankelijkheden correct zijn aangeroepen.
• Bevestig dat de gebruikersinterface is geüpdatet zoals verwacht, samen met andere opzettelijke neveneffecten.
• Verifieer of de geretourneerde informatie overeenkomt met de verwachte waarde.
• Valideer testparameters.

Als je tool bijvoorbeeld een SearchComponent-functie gebruikt, kun je testen door een mock van SearchComponent door te geven. Simuleer de omgeving waarin de tool wordt gebruikt om de best mogelijke resultaten te krijgen. Dit is dezelfde techniek die je gebruikt als je een andere test voor Application Integration schrijft.

Probabilistische tests uitvoeren

Als u een modeluitvoer nodig heeft om de volgende tools correct aan te roepen, moet u evaluaties schrijven.

Gebruikers kunnen rechtstreekse query's aan het model geven waarin ze specifiek vragen wat de tool doet, of een dubbelzinnige query die impliceert dat er een tool moet worden gebruikt. 'Voeg pepperoni toe aan mijn pizza' is bijvoorbeeld een directe zoekopdracht. 'Ik wil al het vlees op mijn pizza' is dubbelzinniger en vereist dat het model begrijpt dat het de tool add_topping nodig heeft en welke van de toppings als vlees kunnen worden gedefinieerd.

Neem bij het maken van datasets voor je evaluaties zowel directe query's op die de uitvoering van de basistool testen als open query's die de redeneer- en toolselectielogica van het model testen.

Als u een koffiebar heeft, kunt u gebruikers ondersteunen die hun agent vragen dezelfde koffie opnieuw te bestellen als vorige maand. Schrijf een tool om eerdere bestellingen te zoeken, OrderHistoryService, en een andere om de koffie te bestellen. Als je de service voor bestelgeschiedenis wilt testen, kun je een mock sturen die een koffieproduct-ID retourneert.

In dit voorbeeld beoordeelt u of het model de intentie van de query begrijpt, de juiste tool kiest en of die tool de juiste informatie biedt om actie te ondernemen. Als het model get_order_history niet aanroept, weet het niet wat het moet gebruiken voor item_idorder_product.

End-to-end testen

Schrijf end-to-end tests om er zeker van te zijn dat gebruikers en hun agenten hun trajecten kunnen afronden. Naast het testen van de afzonderlijke tools test je ook of acties met meerdere stappen in de juiste volgorde worden uitgevoerd.

Stel dat u een online kledingwinkel heeft. Een gebruiker vraagt hun agent: 'Ik wil een zwarte jas en een spijkerbroek kopen. Kunt u een overzicht geven van de gebruikte materialen?'

Een geslaagde reis met agenten kan er zo uitzien:

1. Ga naar de kledingcategorie.
2. Vind een van de gevraagde kledingstukken (de volgorde is niet belangrijk).
3. Zoek een specifiek item (search_clothes).
4. Haal de productdetails op die de materiaallijst (get_product_details) bevatten.
5. Herhaal stap 2-4 voor elk gevraagd item.

Als de agent stap 2 bereikt, kan deze zoeken naar de zwarte broek of de jeans. De volgorde is niet belangrijk. De rest van de stappen moet je wel in de juiste volgorde uitvoeren.

Schrijf een end-to-end evaluatie om te verifiëren dat de agent de tools voor gesprekken in de verwachte volgorde aanroept:

{
  "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" }
            }
          ]
        }
      ]
    }
  ]
}

Fouten in het midden van de keten evalueren

Er kunnen momenten zijn waarop een medewerker meerdere tools achter elkaar moet aanroepen. Wat gebeurt er als een tool halverwege dit proces mislukt? Stel dat een gebruiker een pizza wil bestellen met een kortingscode:

Ik wil een kleine pesto-pizza. Gebruik mijn promotiecode, FreePizza.'

Het is mogelijk dat de agent mislukt bij de add_discount_coupon en doorgaat naar het afrekenen voor een pizza tegen de volledige prijs. Als je de tool add_discount_coupon wilt testen, kun je deze reeks toolaanroepen handmatig uitvoeren zonder interactie met een model om dit scenario te simuleren. Breng je app naar de status waarin je verwacht dat de tool mislukt. In dit geval is dat na de tool start_checkout. Daarna kunt u de add_discount_coupon afzonderlijk evalueren.

Experimenteren met WebMCP

Begin met experimenteren met evaluaties voor tools in isolatie en evalueer uw eigen sites die WebMCP ondersteunen met een WebMCP-compatibele agent:

• Download onze experimentele evaluatietools op GitHub.
• Volg onze cursus AI-beoordelingen maken.