WebMCP mit Evals testen

Kasper Kulikowski

Veröffentlicht: 19. Mai 2026, zuletzt aktualisiert: 28. Mai 2026

Erklärvideo	Web	Erweiterungen	Chrome-Status	Absicht
GitHub	Ursprungstest		Ansicht	Absicht, Tests durchzuführen

WebMCP unterstützt Agenten, die generative KI-Modelle verwenden. Wenn Sie ein System mit generativer KI testen möchten, müssen Ihre Tests probabilistische Ergebnisse unterstützen: Eine Eingabe kann zu Tausenden von Antworten mit unterschiedlichem Genauigkeitsgrad führen. Diese Testmethode wird als Evaluierung bezeichnet.

Bevor Sie Tools in der Produktion freigeben, müssen Sie bestätigen, dass Agents wissen, wann sie das Tool aufrufen, wie sie es ausführen und welche Antworten akzeptabel sind. Mögliche Fehlerquellen beheben, bevor sie auftreten.

Bewertungen schreiben, um die Touchpoints Ihres Systems mit einem Large Language Model (LLM) zu testen:

• Prüfen Sie anhand der Beschreibung und des Schemas, ob das Modell den Zweck Ihres Tools versteht.
• Prüfen Sie, ob das Modell das richtige Tool mit den richtigen Parametern auswählt, um die Nutzerabsicht zu unterstützen.
• Bestätigen Sie, dass das Modell auf Informationen reagiert, die es erhalten hat, z. B. um Informationen zum Aufrufen eines anderen Tools zu verwenden.
• Erfolgreiche User Journeys überprüfen Kann ein Kundenservicemitarbeiter die User Journey auf meiner Website mit den bereitgestellten Tools erfolgreich abschließen, wenn man die Absicht des Nutzers berücksichtigt?

Sie sollten weiterhin klassische deterministische Tests für jede Systeminteraktion schreiben, bei der nicht mit dem Modell kommuniziert wird.

Fehlerszenarien

Entwickler sollten ihre Systeme testen, um Ausfälle zu verhindern, bevor sie auftreten. Dazu müssen Sie wissen, wann das System versagen kann, sowohl allein als auch in der Interaktion mit externen Faktoren. Bei WebMCP kann es zu Fehlern beim Tool selbst kommen und Agents können die Tools möglicherweise nicht wie erwartet verwenden.

WebMCP-Tools können fehlschlagen und der Agent kann mit WebMCP-Tools fehlschlagen. Angenommen, der Nutzer möchte ein T‑Shirt in den Einkaufswagen legen.

Fehler	Beispiel	Fehlerbehebung
Der Agent wählt das falsche Tool aus oder ruft das falsche Tool direkt auf.	Der Agent überspringt addToCart und geht direkt zu checkout.	Ist die description des Tools klar, vollständig und spiegelt sie genau wider, was das Tool tut? Ist die functionName intuitiv und beschreibend? Wird das Tool dem LLM im aktuellen Zustand/Kontext richtig zur Verfügung gestellt? Ist das Schema dieses Tools möglicherweise zu ähnlich wie das eines anderen Tools, was zu Unklarheiten beim Aufrufen führen könnte?
Der Agent ruft Tools in der falschen Reihenfolge auf.	Der KI-Agent ruft checkout und dann addToCart auf.	Gibt es Überschneidungen bei den Toolbeschreibungen, die das LLM hinsichtlich der erforderlichen Reihenfolge verwirren? Liefert die Ausgabe eines vorherigen Tools den erforderlichen Kontext für den nächsten Toolaufruf? Wird der Status korrekt aktualisiert und werden dem LLM neue Tools wie erwartet zur Verfügung gestellt? Ist der End-to-End-Anwendungsfall weiterhin korrekt, wenn bestimmte Tools in einer anderen Reihenfolge aufgerufen werden? Haben Sie die spezifische Tool-Aufrufkette isoliert getestet, indem Sie die vorherigen Aufrufe erzwungen haben, um zu bestätigen, dass das LLM den richtigen nächsten Schritt auswählt?
Der Agent ruft das Tool mit falschen Argumenten auf.	Der KI-Agent ruft addToCart auf, fügt aber Schuhe anstelle eines T-Shirts hinzu.	Ist inputSchema klar definiert, einschließlich enum-Werten und einer guten description für jede Property? Sind alle erforderlichen Parameter explizit gekennzeichnet und geprüft? Wird das LLM in der Beschreibung des Arguments explizit angeleitet, wie Nutzereingaben der erwarteten strukturierten Daten (z. B. einer bestimmten ID oder einem bestimmten Format) zugeordnet werden sollen?

Was passiert, wenn der Nutzer sehen möchte, was sich in seinem Warenkorb befindet?

Fehler	Beispiel	Fehlerbehebung
Die Tool-Ausgabe ist falsch oder es fehlt etwas.	Der Nutzer bittet um viewCart, aber der Kundenservicemitarbeiter gibt die Gesamtkosten des Einkaufswagens an, anstatt die Produktnamen und Einzelpreise.	Gibt es Fehler in der zugrunde liegenden Tool-Logik (mit deterministischen Tests prüfen)? Wurde der UI-Status korrekt aktualisiert und hat der Agent die richtigen Informationen zur Nebenwirkung erhalten? Wenn die Ausgabe vom LLM für nachfolgende Aufrufe verwendet wird, ist sie dann klar für die LLM-Aufnahme formatiert? Ist die Ausgabe zu ausführlich? Enthält sie nur die unbedingt erforderlichen Informationen, die das LLM für die nächste Aktion benötigt?

Schließlich kann ein Tool auf jede Art und Weise fehlschlagen, in der JavaScript fehlschlägt. Gehen Sie zur Fehlerbehebung so vor:

• Werden alle potenziellen Laufzeitfehler und Ausnahmen im Tool-Code richtig behandelt?
• Wird der Fehler auf angemessene Weise an den Agenten und das Modell zurückgemeldet?
• Sind die externen APIs oder Dienste, auf die sich das Tool stützt, fehlerfrei?
• Ist die Fehlerstruktur klar genug, damit das Modell zwischen einem vorübergehenden Problem (Wiederholungsversuch) und einem schwerwiegenden Fehler unterscheiden kann?

Tools isoliert testen

Wenn ein Agent nicht herausfinden kann, welches Tool für eine Anfrage wie „Ich möchte eine kleine Pizza“ aufgerufen werden soll, hat er bei einer komplexen User Journey keine Chance.

Wenn Sie Tools isoliert testen, können Sie Ihre Schemas und Beschreibungen optimieren, bevor Sie eine Browsersimulation ausführen.

Anrufgenauigkeit messen

Sehen Sie sich unsere Demo WebMCP zaMaker an. Wenn der Nutzer „Ich möchte eine kleine Pizza“ eingibt, können Sie eine Modellantwort erwarten, die die Absicht angibt, einen set_pizza_size-Aufruf mit dem "size":"Small"-Argument auszuführen.

Die Funktion expectedCall definiert die erwartete Funktion und das erwartete Argument. So wird bestätigt, dass der Agent basierend auf dem bereitgestellten Schema das richtige Tool auswählt, um die Nutzerabsicht zu unterstützen.

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

expectedCall wird verwendet, um einen regelbasierten, deterministischen Test durchzuführen:

Sie können Ihre WebMCP-Tools an den Lebenszyklus einer Komponente binden. Das bedeutet, dass Sie testen müssen, wann der Anwendungsstatus dem entspricht, was WebMCP erwartet. Geben Sie dazu eine vollständige Tool-Liste an, die für den Status relevant ist, den Sie auswerten möchten. Ein Nutzer sieht sich beispielsweise gemeinsam mit seinem KI-Agenten Inhalte an und öffnet 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" }
   }
 ]
...

Beim Öffnen von WebMCP werden die Tools add_topping, set_pizza_size und set_pizza_style angezeigt. Wenn Sie eines dieser einzelnen Tools genau testen möchten, sollten Sie alle Tools einbeziehen, um einen simulierten, vollständigen Zustand zu erstellen.

HINWEIS: Ein Agent hat möglicherweise Zugriff auf zusätzliche Tools, aber Sie können nur die von Ihnen bereitgestellten Tools bewerten.

Nachdem Sie wissen, dass der Agent das richtige Tool nach Bedarf aufruft, können Sie testen, ob der Toolaufruf die richtigen Parameter enthält und das Ergebnis wie erwartet ist. Es gibt zwei Schritte: deterministische Tests und probabilistische Tests.

Deterministische Tests ausführen

Da WebMCP-Tools mit JavaScript oder als HTML-Anmerkungen erstellt werden, können Sie deterministische Tests schreiben, um die folgenden Aufgaben auszuführen:

• Überprüfen Sie die Tool-Logik.
• Prüfen Sie, ob Abhängigkeiten richtig aufgerufen wurden.
• Prüfen Sie, ob die Benutzeroberfläche wie erwartet aktualisiert wurde und ob es weitere beabsichtigte Nebeneffekte gibt.
• Prüfen Sie, ob die zurückgegebenen Informationen dem erwarteten Wert entsprechen.
• Testparameter validieren

Wenn Ihr Tool beispielsweise eine SearchComponent-Funktion verwendet, können Sie es testen, indem Sie einen Mock von SearchComponent übergeben. Denken Sie daran, die Umgebung zu simulieren, in der das Tool verwendet wird, um die bestmöglichen Ergebnisse zu erzielen. Das ist dieselbe Technik, die Sie auch beim Schreiben eines anderen Anwendungsintegrationstests verwenden würden.

Probabilistische Tests ausführen

Wenn Sie eine Modellausgabe benötigen, um die nächsten Tools richtig aufzurufen, müssen Sie Evals schreiben.

Nutzer können dem Modell direkte Anfragen stellen, in denen sie explizit nach der Funktion des Tools fragen, oder mehrdeutige Anfragen, die implizieren, dass ein Tool verwendet werden sollte. „Füge meiner Pizza Salami hinzu“ ist beispielsweise eine direkte Anfrage. „Ich möchte, dass auf meiner Pizza nur Fleisch ist“ ist mehrdeutig und erfordert, dass das Modell das Tool „add_topping“ verwendet und versteht, welche der Beläge als Fleisch definiert werden können.

Wenn Sie Datasets für Ihre Tests erstellen, sollten Sie sowohl direkte Anfragen, mit denen die Ausführung von Standardtools getestet wird, als auch offene Anfragen einbeziehen, mit denen die Logik für die Modellierung und die Auswahl von Tools getestet wird.

Wenn Sie ein Café betreiben, können Sie Nutzer unterstützen, die ihren Agenten bitten, denselben Kaffee nachzubestellen, den sie letzten Monat bestellt haben. Schreibe ein Tool zum Suchen nach früheren Bestellungen, OrderHistoryService, und ein weiteres zum Bestellen des Kaffees. Um den Bestellverlauf-Dienst zu testen, können Sie ein Mock senden, das eine Kaffeeprodukt-ID zurückgibt.

In diesem Beispiel bewerten Sie, ob das Modell die Intention der Anfrage versteht, das richtige Tool auswählt und ob dieses Tool die richtigen Informationen für die Ausführung einer Aktion liefert. Wenn das Modell get_order_history nicht aufruft, weiß es nicht, welche item_id für order_product verwendet werden soll.

End-to-End-Tests

Schreiben Sie End-to-End-Tests, um sicherzustellen, dass Nutzer und ihre Kundenservicemitarbeiter ihre Prozesse erfolgreich abschließen können. Sie testen nicht nur die einzelnen Tools, sondern auch, ob mehrstufige Aktionen in der richtigen Reihenfolge ausgeführt werden.

Angenommen, Sie betreiben einen Onlineshop für Kleidung. Ein Nutzer fragt seinen Kundenservicemitarbeiter: „Ich möchte eine schwarze Jacke und eine Jeans kaufen. Könnten Sie eine Aufschlüsselung der verwendeten Materialien bereitstellen?“

Ein erfolgreicher Ablauf könnte so aussehen:

1. Rufen Sie die Kategorie „Kleidung“ auf.
2. Finde eines der angeforderten Kleidungsstücke (die Reihenfolge ist unwichtig).
3. Bestimmten Artikel finden (search_clothes)
4. Rufen Sie die Produktdetails mit der Materialliste (get_product_details) ab.
5. Wiederholen Sie die Schritte 2 bis 4 für jeden angeforderten Artikel.

Wenn der Agent Schritt 2 erreicht, kann er zuerst nach dem schwarzen Hemd oder nach der Jeans suchen. Die Reihenfolge ist nicht wichtig. Die restlichen Schritte müssen jedoch nacheinander ausgeführt werden.

Schreiben Sie eine End-to-End-Bewertung, um zu prüfen, ob der Agent Tools in der erwarteten Reihenfolge aufruft:

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

Fehler in der Mitte der Kette bewerten

Es kann vorkommen, dass ein Agent mehrere Tools nacheinander aufrufen muss. Was passiert, wenn ein Tool während dieses Vorgangs fehlschlägt? Beispiel: Ein Nutzer möchte mit seinem Gutscheincode eine Pizza bestellen:

„Ich möchte eine kleine Pesto-Pizza. Verwende meinen Gutscheincode FreePizza.“

Es ist möglich, dass der Agent bei add_discount_coupon fehlschlägt und mit dem Kauf einer Pizza zum vollen Preis fortfährt. Um das add_discount_coupon-Tool zu testen, können Sie diese Folge von Tool-Aufrufen manuell ausführen, ohne mit einem Modell zu interagieren, um dieses Szenario zu simulieren. Bringen Sie Ihre Anwendung in den Zustand, in dem das Tool voraussichtlich fehlschlägt. In diesem Fall ist das nach dem Tool start_checkout. Anschließend können Sie die add_discount_coupon isoliert bewerten.

WebMCP ausprobieren

Beginnen Sie damit, die Evaluierung von Tools isoliert zu testen und Ihre eigenen WebMCP-fähigen Websites mit einem beliebigen WebMCP-kompatiblen Agenten zu bewerten:

• Laden Sie unsere experimentellen Auswertungstools auf GitHub herunter.
• Kurs „KI-Bewertungen erstellen“