Evaluaties voor WebMCP

Kasper Kulikowski

Gepubliceerd: 19 mei 2026

WebMCP ondersteunt agents die gebruikmaken van generatieve AI-modellen. Om een ​​systeem te testen dat gebruikmaakt van generatieve AI, moeten uw tests probabilistische uitkomsten ondersteunen: één invoer kan leiden tot duizenden antwoorden met verschillende nauwkeurigheidsgraden. Deze testtechniek wordt evaluatie of eval genoemd.

Voordat je tools in productie neemt, moet je controleren of de agents begrijpen wanneer ze de tool moeten aanroepen, hoe ze deze moeten uitvoeren en welke antwoorden acceptabel zijn. Pak mogelijke fouten aan voordat ze zich voordoen.

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

• Controleer of het model het doel van uw tool begrijpt, op basis van de beschrijving en het schema ervan.
• Controleer of het model de juiste tool met de juiste parameters selecteert om de intentie van de gebruiker te ondersteunen.
• Bevestig dat het model de ontvangen informatie verwerkt, bijvoorbeeld door die informatie te gebruiken om een ​​andere tool aan te roepen.
• Verifieer succesvolle gebruikerstrajecten. Kan een medewerker, gegeven de intentie van de gebruiker, het gebruikerstraject op mijn website succesvol voltooien met de beschikbare tools?

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

Storingsmodi

Ontwikkelaars moeten hun systemen testen om storingen te voorkomen voordat ze zich voordoen. Daarvoor is het belangrijk te begrijpen wanneer het systeem kan falen, zowel op zichzelf als in interactie met externe factoren. Bij WebMCP kan de tool zelf falen en kunnen agents de tools mogelijk niet gebruiken zoals verwacht.

WebMCP-tools kunnen soms falen, en de agent kan ook falen in de samenwerking met WebMCP-tools. Stel bijvoorbeeld dat een gebruiker een T-shirt aan zijn winkelmandje wil toevoegen.

Mislukking	Voorbeeld	Problemen oplossen
De agent selecteert niet het juiste hulpmiddel of roept direct het verkeerde hulpmiddel aan.	De agent slaat de addToCart over en gaat direct naar checkout .	Is de description van het gereedschap duidelijk, volledig en geeft deze nauwkeurig weer wat het gereedschap doet? Is de functionName intuïtief en beschrijvend? Wordt de tool in de huidige staat/context correct beschikbaar gesteld aan het LLM? Is het schema van deze tool mogelijk te vergelijkbaar met dat van een andere tool, wat tot onduidelijkheid bij de aanroep kan leiden?
De agent roept de tools in de verkeerde volgorde aan.	De agent roept checkout aan en vervolgens addToCart .	Overlappen de beschrijvingen van de tools elkaar, waardoor de LLM in de war raakt over de vereiste volgorde? Biedt de uitvoer van een voorgaande tool de benodigde context voor de volgende toolaanroep? Is de status correct bijgewerkt en zijn alle nieuwe tools zoals verwacht beschikbaar gesteld aan het LLM? Is het volledige gebruiksscenario nog steeds correct als bepaalde tools in een andere volgorde worden aangeroepen? Heeft u de specifieke aanroepketen van de tool afzonderlijk getest door de voorafgaande aanroepen af ​​te dwingen om te bevestigen dat de LLM de juiste volgende stap kiest?
Agent roept tool aan met onjuiste argumenten	De agent roept addToCart aan, maar voegt schoenen toe in plaats van een t-shirt.	Is het inputSchema duidelijk gedefinieerd, inclusief enum waarden en een goede description voor elke eigenschap? Zijn alle vereiste parameters expliciet gemarkeerd en gecontroleerd? Geeft de beschrijving van het argument de LLM expliciet aanwijzingen over hoe gebruikersinvoer moet worden gekoppeld aan de verwachte gestructureerde gegevens (zoals een specifieke ID of indeling)?

Wat als de gebruiker wil controleren wat er in zijn winkelmandje zit?

Mislukking	Voorbeeld	Problemen oplossen
De uitvoer van de tool is onjuist of de tool mist iets.	De gebruiker vraagt ​​om viewCart te bekijken, maar de agent geeft de totale kosten van de winkelwagen weer in plaats van de productnamen en individuele prijzen.	Bevat de onderliggende logica van de tool fouten (controleer met deterministische tests)? Is de UI-status correct bijgewerkt en heeft de agent de juiste informatie over het neveneffect ontvangen? Als de uitvoer door de LLM wordt gebruikt voor volgende aanroepen, is de uitvoer dan duidelijk geformatteerd voor verwerking door de LLM? Is de output te uitgebreid? Bevat deze alleen de minimaal noodzakelijke informatie die het LLM nodig heeft voor de volgende actie?

Tot slot kan een tool op allerlei manieren falen als JavaScript niet werkt. Om dit probleem op te lossen, kunt u het volgende onderzoeken:

• Handelt de toolcode alle mogelijke runtimefouten en uitzonderingen correct af?
• Wordt de foutmelding correct teruggekoppeld aan de agent en het model?
• Zijn de externe API's of services waarop de tool vertrouwt, in goede staat?
• Is de foutstructuur duidelijk genoeg zodat het model onderscheid kan maken tussen een tijdelijk probleem (opnieuw proberen) en een kritieke fout?

Testtools afzonderlijk.

Als een medewerker niet weet welke tool hij moet gebruiken voor een verzoek als: "Ik wil graag een kleine pizza", dan heeft hij geen schijn van kans in een complex klanttraject.

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

TIP: Je kunt een WebMCP-tooloproep activeren using navigator.modelContext.executeTool(...) .

Meet de nauwkeurigheid van gesprekken

Bekijk onze demo, de WebMCP zaMaker . Wanneer de gebruiker vraagt: "Ik wil graag een kleine pizza", kunt u een reactie van het model verwachten die aangeeft dat er een set_pizza_size aanroep moet worden uitgevoerd met het argument "size":"Small" .

De functie expectedCall definieert de verwachte functie en het bijbehorende argument. Deze aanpak bevestigt dat de agent de juiste tool kiest om de intentie van de gebruiker 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 ​​op regels gebaseerde, deterministische test uit te voeren:

Het is mogelijk om uw WebMCP-tools te koppelen aan de levenscyclus van een component. Dit betekent dat u moet testen wanneer de status van uw applicatie overeenkomt met wat WebMCP verwacht. Om dit te beheren, kunt u een volledige lijst met tools opgeven die relevant zijn voor de status die u wilt evalueren. Bijvoorbeeld: een gebruiker is aan het co-browsen met zijn agent 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 van WebMCP worden de tools add_topping , set_pizza_size en set_pizza_style weergegeven. Om elk van deze tools afzonderlijk nauwkeurig te testen, moet u ze allemaal opnemen om een ​​gesimuleerde, complete situatie te creëren.

LET OP: Een agent heeft mogelijk toegang tot extra tools, maar het beste wat u kunt doen, is de tools die u ter beschikking stelt, evalueren.

Nu je weet dat de agent de juiste tool aanroept wanneer dat nodig is, kun je testen of de toolaanroep de juiste parameters heeft en of het resultaat aan de verwachtingen voldoet. Er zijn twee stappen: deterministische tests en probabilistische tests.

Voer deterministische tests uit.

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

• Controleer de logica van de tool.
• Controleer of de afhankelijkheden correct zijn aangeroepen.
• Bevestig dat de gebruikersinterface naar verwachting is bijgewerkt, evenals eventuele andere opzettelijke neveneffecten.
• Controleer of de geretourneerde informatie overeenkomt met de verwachte waarde.
• Testparameters valideren.

Als uw tool bijvoorbeeld een SearchComponent -functie gebruikt, kunt u testen door een mock van SearchComponent door te geven. Vergeet niet de omgeving waarin de tool werkt te simuleren voor de best mogelijke resultaten. Dit is dezelfde techniek die u zou gebruiken bij het schrijven van een andere applicatie-integratietest.

Voer probabilistische tests uit.

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

Gebruikers kunnen rechtstreekse vragen aan het model stellen die specifiek aangeven wat de tool doet, of een meer vage vraag die impliceert dat een tool gebruikt moet worden. Bijvoorbeeld: "Voeg pepperoni toe aan mijn pizza" is een directe vraag. "Ik wil al het vlees op mijn pizza" is ambigu en vereist dat het model begrijpt dat de tool `add_topping` nodig is en welke van de toppings als vlees kunnen worden gedefinieerd.

Bij het maken van datasets voor uw evaluaties dient u zowel directe query's op te nemen die de basisuitvoering van de tool testen, als open query's die de redenering van het model en de logica voor toolselectie testen.

Als je een koffiebar runt, kun je klanten helpen die hun medewerker vragen om dezelfde koffie opnieuw te bestellen die ze vorige maand besteld hebben. Schrijf een tool om eerdere bestellingen te doorzoeken, OrderHistoryService , en een andere tool om de koffie te bestellen. Om de OrderHistoryService te testen, kun je een mock-object versturen dat een product-ID van een koffieproduct retourneert.

In dit voorbeeld evalueer je of het model de intentie van de query begrijpt, de juiste tool kiest en of die tool de juiste informatie levert om actie te ondernemen. Als het model get_order_history niet aanroept, weet het niet welke item_id het moet gebruiken voor order_product .

End-to-end testen

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

Stel, u runt een online kledingwinkel. Een klant vraagt ​​aan uw medewerker: "Ik wil graag een zwart jasje en een spijkerbroek kopen. Kunt u een overzicht geven van de gebruikte materialen?"

Een succesvolle agentische reis zou er als volgt uit kunnen zien:

1. Ga naar de categorie kleding.
2. Zoek een van de gevraagde kledingstukken (de volgorde maakt niet uit).
3. Zoek naar een specifiek artikel ( search_clothes ).
4. Haal de productdetails op die de materiaallijst bevatten ( get_product_details ).
5. Herhaal stap 2-4 voor elk aangevraagd item.

Wanneer de agent stap 2 bereikt, kan hij eerst naar zwart zoeken of eerst naar jeans; de volgorde is niet belangrijk. De overige stappen moeten echter wel in de juiste volgorde worden uitgevoerd.

Schrijf een end-to-end evaluatie om te controleren of de agent de tools 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" }
            }
          ]
        }
      ]
    }
  ]
}

Evalueer defecten halverwege de keten.

Er kunnen momenten zijn waarop een agent meerdere tools achter elkaar moet aanroepen. Wat gebeurt er als een tool midden in dit proces uitvalt? Bijvoorbeeld, een gebruiker wil een pizza bestellen met zijn kortingscode:

"Ik wil graag een kleine pestopizza. Gebruik mijn promotiecode: FreePizza ."

Het is mogelijk dat de agent faalt bij het add_discount_coupon en doorgaat naar de afrekenpagina voor een pizza tegen de volledige prijs. Om de tool add_discount_coupon te testen, kunt u deze reeks toolaanroepen handmatig uitvoeren, zonder interactie met een model, om dit scenario te simuleren. Breng uw applicatie in de staat waarin u verwacht dat de tool faalt. In dit geval is dat na de ` start_checkout tool. Vervolgens kunt u de add_discount_coupon geïsoleerd evalueren.

Experimenteer met WebMCP

Begin met het experimenteren met evaluaties van tools afzonderlijk en evalueer uw eigen WebMCP-sites met een WebMCP-compatibele agent:

• Download onze experimentele evaluatietools op GitHub .
• Bekijk onze cursus ' AI-evaluaties maken' .