Testy WebMCP

Kasper Kulikowski

Opublikowano: 19 maja 2026 r.

WebMCP obsługuje agentów, którzy korzystają z modeli generatywnej AI. Aby przetestować dowolny system korzystający z generatywnej AI, musisz przeprowadzić testy, które uwzględniają wyniki probabilistyczne. Jedno wejście może prowadzić do tysięcy odpowiedzi o różnym stopniu dokładności. Ta technika testowania nazywa się oceną.

Zanim udostępnisz narzędzia w środowisku produkcyjnym, musisz potwierdzić, że agenci wiedzą, kiedy wywołać narzędzie, jak je uruchomić i jakie odpowiedzi są akceptowalne. Zajmij się potencjalnymi problemami, zanim się pojawią.

Napisz oceny, aby przetestować punkty styku systemu z dużym modelem językowym (LLM):

• Sprawdź, czy model rozumie cel narzędzia na podstawie jego opisu i schematu.
• Sprawdź, czy model wybiera odpowiednie narzędzie z prawidłowymi parametrami, aby uwzględnić intencje użytkownika.
• Sprawdź, czy model działa na podstawie otrzymanych informacji, np. czy używa informacji do wywołania innego narzędzia.
• Sprawdź, czy ścieżki użytkownika są prawidłowe. Czy agent może zrealizować ścieżkę użytkownika w mojej witrynie za pomocą udostępnionych narzędzi, biorąc pod uwagę intencje użytkownika?

W przypadku każdej interakcji z systemem, która nie komunikuje się z modelem, należy nadal pisać klasyczne testy deterministyczne.

Rodzaje błędów

Programiści powinni testować swoje systemy, aby zapobiegać awariom. Aby to zrobić, musisz wiedzieć, kiedy system może ulec awarii, zarówno samodzielnie, jak i w interakcji z czynnikami zewnętrznymi. W przypadku WebMCP może dojść do awarii samego narzędzia, a agenci mogą nie używać narzędzi zgodnie z oczekiwaniami.

Narzędzia WebMCP mogą ulec awarii, a agent może nie działać prawidłowo z narzędziami WebMCP. Załóżmy na przykład, że użytkownik chce dodać koszulkę do koszyka.

Niepowodzenie	Przykład	Rozwiązywanie problemów
Agent nie może wybrać prawidłowego narzędzia lub bezpośrednio wywołuje nieprawidłowe narzędzie.	Agent pomija addToCart i przechodzi bezpośrednio do checkout.	Czy description narzędzia jest jasny, kompletny i dokładnie odzwierciedla działanie narzędzia? Czy functionName jest intuicyjna i opisowa? Czy narzędzie jest prawidłowo udostępniane LLM w bieżącym stanie lub kontekście? Czy schemat tego narzędzia jest potencjalnie zbyt podobny do innego narzędzia, co prowadzi do niejednoznaczności wywołania?
Agent wywołuje narzędzia w nieprawidłowej kolejności	Agent wywołuje checkout, a potem addToCart.	Czy opisy narzędzi się pokrywają, co wprowadza LLM w błąd co do wymaganej sekwencji? Czy dane wyjściowe poprzedniego narzędzia zapewniają niezbędny kontekst dla następnego wywołania narzędzia? Czy stan jest prawidłowo aktualizowany, a nowe narzędzia są udostępniane LLM zgodnie z oczekiwaniami? Czy przypadek użycia typu end-to-end jest nadal prawidłowy, jeśli niektóre narzędzia są wywoływane w innej kolejności? Czy przetestowano konkretny łańcuch wywołań narzędzi w izolacji, wymuszając poprzednie wywołania, aby potwierdzić, że LLM wybiera prawidłowy następny krok?
Agent wywołuje narzędzie z nieprawidłowymi argumentami	Agent wywołuje addToCart, ale dodaje buty zamiast koszulki.	Czy inputSchema jest jasno zdefiniowany, w tym wartości enum i dobry description dla każdej właściwości? Czy wszystkie wymagane parametry są wyraźnie oznaczone i sprawdzone? Czy opis argumentu wyraźnie wskazuje LLM, jak mapować dane wejściowe użytkownika na oczekiwane dane strukturalne (np. konkretny identyfikator lub format)?

Co zrobić, jeśli użytkownik chce sprawdzić zawartość koszyka?

Niepowodzenie	Przykład	Rozwiązywanie problemów
Dane wyjściowe narzędzia są nieprawidłowe lub narzędzie pomija coś.	Użytkownik prosi o viewCart, ale agent wyświetla łączny koszt koszyka zamiast nazw produktów i cen jednostkowych.	Czy podstawowa logika narzędzia zawiera błędy (sprawdź za pomocą testów deterministycznych)? Czy stan interfejsu został prawidłowo zaktualizowany, a agent otrzymał prawidłowe informacje o efekcie ubocznym? Jeśli dane wyjściowe są używane przez LLM do kolejnych wywołań, czy są one sformatowane w sposób zrozumiały dla LLM? Czy dane wyjściowe są zbyt szczegółowe? Czy zawierają tylko minimalne niezbędne informacje, których LLM potrzebuje do wykonania następnej czynności?

Wreszcie narzędzie może ulec awarii w dowolny sposób, w jaki może ulec awarii JavaScript. Aby rozwiązać problem, sprawdź te kwestie:

• Czy kod narzędzia prawidłowo obsługuje wszystkie potencjalne błędy i wyjątki w czasie działania?
• Czy błąd jest zgłaszany agentowi i modelowi w sposób prawidłowy?
• Czy zewnętrzne interfejsy API lub usługi, na których polega narzędzie, działają prawidłowo?
• Czy struktura błędu jest wystarczająco jasna, aby model mógł odróżnić problem tymczasowy (ponowienie) od krytycznej awarii?

Testowanie narzędzi w izolacji

Jeśli agent nie może określić, które narzędzie wywołać w przypadku prośby takiej jak „Chcę małą pizzę”, nie będzie miał szans w złożonej ścieżce użytkownika.

Testując narzędzia w izolacji, możesz zoptymalizować schematy i opisy, zanim uruchomisz symulację przeglądarki.

WSKAZÓWKA: wywołanie narzędzia WebMCP możesz wywołać za pomocą using navigator.modelContext.executeTool(...).

Pomiar dokładności wywołań

Zapoznaj się z naszą wersją demonstracyjną, the WebMCP zaMaker. Gdy użytkownik wpisze „Chcę małą pizzę”, możesz oczekiwać odpowiedzi modelu wskazującej na zamiar wykonania wywołania set_pizza_size z "size":"Small" argumentem.

Funkcja expectedCall definiuje oczekiwaną funkcję i argument. To podejście potwierdza, że agent wybierze odpowiednie narzędzie, aby uwzględnić intencje użytkownika, na podstawie podanego schematu.

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

expectedCall służy do przeprowadzania testu deterministycznego opartego na regułach:

Narzędzia WebMCP można powiązać z cyklem życia komponentu, co oznacza, że musisz przetestować, kiedy stan aplikacji odpowiada temu, czego oczekuje WebMCP. Aby to zrobić, podaj pełną listę narzędzi, które są istotne dla stanu, który chcesz ocenić. Na przykład użytkownik przegląda witrynę razem z agentem i otwiera 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" }
   }
 ]
...

Po otwarciu WebMCP udostępnia narzędzia add_topping, set_pizza_size i set_pizza_style. Aby dokładnie przetestować każde z tych narzędzi, musisz uwzględnić wszystkie narzędzia, aby utworzyć symulowany, kompletny stan.

UWAGA: agent może mieć dostęp do dodatkowych narzędzi, ale możesz ocenić tylko te narzędzia, które udostępniasz.

Teraz, gdy wiesz, że agent wywołuje odpowiednie narzędzie w razie potrzeby, możesz sprawdzić, czy wywołanie narzędzia ma prawidłowe parametry i czy wynik jest zgodny z oczekiwaniami. Są 2 kroki: testy deterministyczne i testy probabilistyczne.

Uruchamianie testów deterministycznych

Narzędzia WebMCP są tworzone w JavaScript lub jako adnotacje HTML, więc możesz pisać testy deterministyczne, aby wykonywać te zadania:

• Sprawdź logikę narzędzia.
• Sprawdź, czy zależności zostały prawidłowo wywołane.
• Sprawdź, czy interfejs użytkownika został zaktualizowany zgodnie z oczekiwaniami, a także inne zamierzone efekty uboczne.
• Sprawdź, czy zwrócone informacje są zgodne z oczekiwaną wartością.
• Sprawdź parametry testu.

Jeśli na przykład narzędzie używa funkcji SearchComponent, możesz przetestować je, przekazując atrapę SearchComponent. Aby uzyskać jak najlepsze wyniki, pamiętaj o symulowaniu środowiska, w którym działa narzędzie. Jest to ta sama metoda, której używasz do pisania innego testu integracji aplikacji.

Uruchamianie testów probabilistycznych

Jeśli do prawidłowego wywołania następnych narzędzi potrzebujesz danych wyjściowych modelu, musisz napisać oceny.

Użytkownicy mogą wysyłać do modelu bezpośrednie zapytania, które dotyczą konkretnie tego, co robi narzędzie, lub niejednoznaczne zapytania, które sugerują, że należy użyć narzędzia. Na przykład „Dodaj pepperoni do mojej pizzy” to bezpośrednie zapytanie. „Chcę wszystkie rodzaje mięsa na pizzy” jest bardziej niejednoznaczne i wymaga od modelu zrozumienia, że potrzebuje narzędzia add_topping i które dodatki można uznać za mięso.

Podczas tworzenia zbiorów danych na potrzeby ocen uwzględnij zarówno bezpośrednie zapytania, które testują podstawowe działanie narzędzia, jak i otwarte zapytania, które testują logikę rozumowania modelu i wyboru narzędzia.

Jeśli prowadzisz kawiarnię, możesz obsługiwać użytkowników, którzy proszą agenta o ponowne zamówienie tej samej kawy, którą zamówili w zeszłym miesiącu. Napisz narzędzie do wyszukiwania poprzednich zamówień, OrderHistoryService, i inne do zamawiania kawy. Aby przetestować usługę historii zamówień, możesz wysłać atrapę, która zwraca identyfikator produktu kawy.

W tym przykładzie oceniasz, czy model rozumie intencje zapytania, wybiera odpowiednie narzędzie i czy to narzędzie dostarcza odpowiednie informacje do podjęcia działania. Jeśli model nie wywoła get_order_history, nie będzie wiedział, jakiego item_id użyć w przypadku order_product.

Testowanie kompleksowe

Napisz testy kompleksowe, aby mieć pewność, że użytkownicy i ich agenci mogą pomyślnie realizować swoje ścieżki. Oprócz testowania poszczególnych narzędzi testujesz też, czy działania wieloetapowe są wykonywane w prawidłowej kolejności.

Załóżmy, że prowadzisz internetowy sklep odzieżowy. Użytkownik pyta agenta: „Chcę kupić czarną kurtkę i parę dżinsów. Czy możesz podać listę użytych materiałów?”

Pomyślna ścieżka agenta może wyglądać tak:

1. Przejdź do kategorii odzieży.
2. Znajdź jeden z żądanych elementów odzieży (kolejność nie ma znaczenia).
3. Znajdź konkretny element (search_clothes).
4. Pobierz szczegóły produktu, które zawierają listę materiałów (get_product_details).
5. Powtórz kroki 2–4 dla każdego żądanego elementu.

Gdy agent dotrze do kroku 2, może najpierw wyszukać czarną kurtkę lub dżinsy. Kolejność nie ma znaczenia. Jednak pozostałe kroki muszą być wykonywane kolejno.

Napisz ocenę kompleksową, aby sprawdzić, czy agent wywołuje narzędzia w oczekiwanej kolejności:

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

Ocena awarii w środku łańcucha

Czasami agent musi wywołać kilka narzędzi kolejno. Co się stanie, jeśli narzędzie ulegnie awarii w środku tego procesu? Na przykład użytkownik chce zamówić pizzę z kodem kuponu:

„Chcę małą pizzę pesto. Użyj mojego kodu promocyjnego FreePizza”.

Możliwe, że agent nie będzie mógł użyć narzędzia add_discount_coupon i przejdzie do płatności za pizzę w pełnej cenie. Aby przetestować narzędzie add_discount_coupon, możesz ręcznie wykonać tę sekwencję wywołań narzędzi bez interakcji z modelem, aby zasymulować ten scenariusz. Doprowadź aplikację do stanu, w którym spodziewasz się awarii narzędzia. W tym przypadku jest to po narzędziu start_checkout. Następnie możesz ocenić add_discount_coupon w izolacji.

Eksperymentowanie z WebMCP

Zacznij eksperymentować z ocenami narzędzi w izolacji i oceniać własne witryny z obsługą WebMCP za pomocą dowolnego agenta zgodnego z WebMCP:

• Pobierz nasze eksperymentalne narzędzia do oceny na GitHubie.
• Zapoznaj się z naszym kursem Tworzenie ocen AI.