WebMCP mit Evals testen

Kasper Kulikowski

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

Erklärvideo	Web	Erweiterungen	Chrome-Status	Absicht
GitHub	Ursprungstest		Ansicht	Absicht zum Testen

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 unterschiedlicher Genauigkeit führen. Diese Testmethode wird als Evaluierung bezeichnet.

Bevor Sie Tools in der Produktion freigeben, müssen Sie bestätigen, dass Agenten wissen, wann sie das Tool aufrufen, wie sie es ausführen und welche Antworten akzeptabel sind. Beheben Sie potenzielle Fehler, bevor sie auftreten.

Erstellen Sie Evaluierungen, 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 Absicht des Nutzers zu unterstützen.
• Bestätigen Sie, dass das Modell auf Informationen reagiert, die es erhalten hat, z. B. um ein anderes Tool aufzurufen.
• Prüfen Sie erfolgreiche User Journeys. Kann ein Agent die User Journey auf meiner Website mit den bereitgestellten Tools erfolgreich abschließen?

Sie sollten weiterhin klassische deterministische Tests für jede Systeminteraktion schreiben, bei der keine Kommunikation mit dem Modell stattfindet.

Fehlerszenarien

Entwickler sollten ihre Systeme testen, um Fehler zu vermeiden, bevor sie auftreten. Dazu müssen Sie wissen, wann das System ausfallen kann, sowohl allein als auch in der Interaktion mit externen Faktoren. Bei WebMCP kann das Tool selbst ausfallen und Agenten können die Tools möglicherweise nicht wie erwartet verwenden.

WebMCP-Tools können ausfallen und der Agent kann bei der Verwendung von WebMCP-Tools Fehler verursachen. Angenommen, ein Nutzer möchte ein T‑Shirt in den Warenkorb legen.

Fehler	Beispiel	Fehlerbehebung
Der Agent kann das richtige Tool nicht auswählen oder ruft direkt das falsche Tool 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 der functionName intuitiv und beschreibend? Wird das Tool im aktuellen Status/Kontext korrekt für das LLM bereitgestellt? Ist das Schema dieses Tools möglicherweise zu ähnlich zu einem anderen Tool, was zu Unklarheiten beim Aufruf führt?
Der Agent ruft Tools in der falschen Reihenfolge auf.	Der Agent ruft checkout und dann addToCart auf.	Überschneiden sich die Toolbeschreibungen und verwirren das LLM hinsichtlich der erforderlichen Reihenfolge? Liefert die Ausgabe eines vorherigen Tools den erforderlichen Kontext für den nächsten Toolaufruf? Wird der Status korrekt aktualisiert und werden neue Tools wie erwartet für das LLM bereitgestellt? Ist der End-to-End-Anwendungsfall noch korrekt, wenn bestimmte Tools in einer anderen Reihenfolge aufgerufen werden? Haben Sie die spezifische Toolaufrufkette 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 Agent ruft addToCart auf, legt aber Schuhe anstelle eines T‑Shirts in den Warenkorb.	Ist das inputSchema klar definiert, einschließlich enum-Werten und einer guten description für jede Property? Sind alle erforderlichen Parameter explizit gekennzeichnet und geprüft? Enthält die Beschreibung des Arguments explizite Anweisungen für das LLM, wie die Nutzereingabe den erwarteten strukturierten Daten (z. B. einer bestimmten ID oder einem bestimmten Format) zugeordnet werden soll?

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

Fehler	Beispiel	Fehlerbehebung
Die Toolausgabe ist falsch oder das Tool lässt etwas aus.	Der Nutzer bittet um viewCart, aber der Agent gibt die Gesamtkosten des Warenkorbs aus, anstatt die Produktnamen und Einzelpreise.	Enthält die zugrunde liegende Toollogik Fehler? (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 minimal erforderlichen Informationen, die das LLM für die nächste Aktion benötigt?

Schließlich kann ein Tool auf jede Weise ausfallen, auf die JavaScript ausfällt. Zur Fehlerbehebung sollten Sie Folgendes untersuchen:

• Verarbeitet der Toolcode alle potenziellen Laufzeitfehler und Ausnahmen korrekt?
• Wird der Fehler auf angemessene Weise an den Agenten und das Modell zurückgemeldet?
• Funktionieren die externen APIs oder Dienste, auf die sich das Tool stützt?
• Ist die Fehlerstruktur klar genug, damit das Modell zwischen einem vorübergehenden Problem (Wiederholung) und einem kritischen Fehler unterscheiden kann?

Tools isoliert testen

Wenn ein Agent nicht weiß, welches Tool er für eine Anfrage wie „Ich möchte eine kleine Pizza“ aufrufen 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.

Aufrufgenauigkeit messen

Sehen Sie sich unsere Demo an, den WebMCP zaMaker. 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. Dieser Ansatz bestätigt, dass der Agent anhand des bereitgestellten Schemas das richtige Tool auswählt, um die Absicht des Nutzers 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 mit dem Lebenszyklus einer Komponente verknüpfen. Das bedeutet, dass Sie testen müssen, wann der Status Ihrer Anwendung mit dem übereinstimmt, was WebMCP erwartet. Dazu müssen Sie eine vollständige Toolliste bereitstellen, die für den Status relevant ist, den Sie auswerten möchten. Ein Nutzer führt beispielsweise gemeinsam mit seinem Agenten eine Co-Browsing-Sitzung durch 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 stellt WebMCP die Tools add_topping, set_pizza_size und set_pizza_style bereit. Um eines dieser einzelnen Tools genau zu testen, sollten Sie alle Tools einbeziehen, um einen simulierten, vollständigen Status zu erstellen.

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

Nachdem Sie nun wissen, dass der Agent das richtige Tool nach Bedarf aufruft, können Sie prüfen, 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:

• Toollogik prüfen.
• Bestätigen, dass Abhängigkeiten korrekt aufgerufen wurden.
• Bestätigen, dass die Benutzeroberfläche wie erwartet aktualisiert wurde, zusammen mit allen anderen beabsichtigten Nebenwirkungen.
• Prüfen, ob die zurückgegebenen Informationen mit dem erwarteten Wert übereinstimmen.
• Testparameter validieren.

Wenn Ihr Tool beispielsweise eine Funktion SearchComponent verwendet, können Sie es testen, indem Sie ein Mock von SearchComponent übergeben. Denken Sie daran, die Umgebung zu simulieren, in der das Tool ausgeführt wird, um die bestmöglichen Ergebnisse zu erzielen. Dies ist dasselbe Verfahren, das Sie beim Schreiben eines anderen Tests zur Application Integration verwenden würden.

Probabilistische Tests ausführen

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

Nutzer können dem Modell direkte Abfragen senden, in denen sie speziell nach der Funktion des Tools fragen, oder eine mehrdeutige Abfrage, die impliziert, dass ein Tool verwendet werden sollte. „Füge meiner Pizza Pepperoni hinzu“ ist eine direkte Abfrage. „Ich möchte alles Fleisch auf meiner Pizza“ ist mehrdeutig und erfordert, dass das Modell versteht, dass es das Tool „add_topping“ benötigt und welche der Beläge als Fleisch definiert werden können.

Wenn Sie Datensätze für Ihre Evaluierungen erstellen, fügen Sie sowohl direkte Abfragen ein, mit denen die Toolausführung getestet wird, als auch offene Abfragen, mit denen die Logik für die Modellbegründung und die Toolauswahl 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. Schreiben Sie ein Tool, um nach früheren Bestellungen zu suchen (OrderHistoryService), und ein weiteres, um den Kaffee zu bestellen. Um den Bestellverlaufsdienst zu testen, können Sie ein Mock senden, das eine Kaffee-Produkt-ID zurückgibt.

In diesem Beispiel bewerten Sie, ob das Modell die Absicht der Abfrage versteht, das richtige Tool auswählt und ob dieses Tool die richtigen Informationen liefert, um Maßnahmen zu ergreifen. 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, damit Sie sicher sein können, dass Nutzer und ihre Agenten ihre Journeys erfolgreich abschließen können. Neben dem Testen der einzelnen Tools testen Sie auch, ob mehrstufige Aktionen in der richtigen Reihenfolge ausgeführt werden.

Angenommen, Sie betreiben einen Online-Bekleidungsshop. Ein Nutzer fragt seinen Agenten: „Ich möchte eine schwarze Jacke und ein Paar Jeans kaufen. Können Sie mir eine Aufschlüsselung der verwendeten Materialien geben?“

Eine erfolgreiche Agent-Journey könnte so aussehen:

1. Zur Kategorie „Kleidung“ navigieren.
2. Eines der angeforderten Kleidungsstücke suchen (Reihenfolge ist unwichtig).
3. Bestimmtes Element suchen (search_clothes).
4. Produktdetails mit der Materialliste abrufen (get_product_details).
5. Wiederholen Sie die Schritte 2 bis 4 für jedes angeforderte Element.

Wenn der Agent Schritt 2 erreicht, kann er zuerst nach der schwarzen Jacke oder den Jeans suchen. Die Reihenfolge ist unwichtig. Die übrigen Schritte müssen jedoch sequenziell ausgeführt werden.

Schreiben Sie eine End-to-End-Evaluierung, 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 sequenziell aufrufen muss. Was passiert, wenn ein Tool in der Mitte dieses Vorgangs ausfällt? Ein Nutzer möchte beispielsweise eine Pizza mit seinem Gutscheincode bestellen:

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

Es ist möglich, dass der Agent bei add_discount_coupon ausfällt und mit dem Bezahlvorgang für eine Pizza zum vollen Preis fortfährt. Um das Tool add_discount_coupon zu testen, können Sie diese Toolaufruffolge manuell ausführen, ohne mit einem Modell zu interagieren, um dieses Szenario zu simulieren. Versetzen Sie Ihre Anwendung in den Status, in dem das Tool voraussichtlich ausfallen wird. In diesem Fall ist das nach dem Tool start_checkout. Anschließend können Sie add_discount_coupon isoliert auswerten.

Mit WebMCP experimentieren

Beginnen Sie mit Evaluierungen für Tools isoliert und bewerten Sie Ihre eigenen WebMCP-fähigen Websites mit einem beliebigen WebMCP-kompatiblen Agenten:

• Laden Sie unsere experimentellen Evaluierungstools auf GitHub herunter.
• Sehen Sie sich unseren Kurs „KI-Evaluierungen erstellen“ an.