Bewertungen für WebMCP

Kasper Kulikowski
Kasper Kulikowski
LinkedIn

Veröffentlicht am 19. Mai 2026

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 Bewertung 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 Bewertungen, 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.
  • Prüfen Sie, ob 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 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, Ihr 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, fügt aber Schuhe anstelle eines T-Shirts hinzu.
  • Ist das inputSchema klar definiert, einschließlich enum-Werten und einer guten description für jede Property?
  • Sind alle erforderlichen Parameter explizit markiert und geprüft?
  • Leitet die Beschreibung des Arguments das LLM explizit an, 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 übersieht etwas.

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 ordnungsgemäß an den Agenten und das Modell zurückgemeldet?
  • Sind externe APIs oder Dienste, auf die sich das Tool verlässt, fehlerfrei?
  • 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.

TIPP: Sie können einen WebMCP-Toolaufruf auslösen using navigator.modelContext.executeTool(...).

Genauigkeit des Aufrufs 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. Mit diesem Ansatz wird bestätigt, dass der Agent anhand des bereitgestellten Schemas 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 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 bewerten möchten. Ein Nutzer führt beispielsweise gemeinsam mit seinem Agenten eine Co-Browsing-Sitzung durch und öffnet WebMCP zaMaker.

Status der App

[
...
  {
    "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)",
  ...
  },
...
]

Erwarteter Aufruf

...
 "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 bewerten.

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 verwenden würden, wenn Sie einen anderen Test zur Application Integration schreiben.

Probabilistische Tests ausführen

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

Nutzer können direkte Abfragen an das Modell 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 Bewertungen 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. Erstellen Sie ein Tool zum Suchen nach früheren Bestellungen, OrderHistoryService, und ein weiteres zum Bestellen des Kaffees. 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, um sicherzustellen, 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-Bekleidungsgeschäft. 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 agentengestützte Journey könnte so aussehen:

  1. Zur Kategorie „Kleidung“ navigieren.
  2. Eines der angeforderten Kleidungsstücke suchen (Reihenfolge ist unwichtig).
  3. Bestimmten Artikel suchen (search_clothes).
  4. Produktdetails mit der Materialliste abrufen (get_product_details).
  5. Schritte 2 bis 4 für jeden angeforderten Artikel wiederholen.

Wenn der Agent Schritt 2 erreicht, kann er zuerst nach der schwarzen Jacke oder den Jeans suchen. Die Reihenfolge ist unwichtig. Die restlichen Schritte müssen jedoch sequenziell 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

Beispielhafte Tool-Aufrufe für einen Nutzer, der eine Pizza mit Rabatt bestellt.
Wenn ein Nutzer eine Pizza mit einem Rabattgutschein bestellen möchte, wird eine Kette von Tools sequenziell aufgerufen: start_pizza_creator, set_pizza_style, set_pizza_size, start_checkout, add_discount_coupon, und complete_checkout. Der Aufruf von add_discount_coupon ist fehlgeschlagen, aber der Vorgang konnte trotzdem abgeschlossen werden. Das bedeutet, dass der Nutzer keinen Rabatt erhalten hat.

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. Bringen Sie Ihre Anwendung in den Zustand, in dem Sie erwarten, dass das Tool ausfällt. In diesem Fall ist das nach dem Tool start_checkout. Anschließend können Sie add_discount_coupon isoliert bewerten.

Mit WebMCP experimentieren

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