Jak sprawdzić, czy strona firmowa działa z agentem AI: test WebMCP krok po kroku

Żeby sprawdzić, czy strona działa z agentem AI przez WebMCP, potrzebujesz Chrome z włączoną obsługą tej funkcji w trybie testów, listy narzędzi, które miały zostać wdrożone, i kilkudziesięciu minut. Test ma dwa etapy: sprawdzasz, czy agent w przeglądarce widzi opisy narzędzi w kodzie strony, a potem weryfikujesz, czy wywołanie każdego z nich faktycznie coś robi: wysyła zapytanie, trafia do skrzynki lub CRM. Sama informacja "zrobione" od developera, bez takiego testu, to za mało.

Typowa sytuacja wygląda tak: firma produkująca okna zleca wdrożenie WebMCP, żeby agent AI klienta mógł samodzielnie zapytać o dostępność modeli i wysłać formularz z zapytaniem ofertowym. Developer dostarcza gotowy kod. Właściciel otwiera stronę, formularz wygląda jak zawsze i nie ma pojęcia, co sprawdzić. Czy agent w ogóle zobaczy ten formularz? Czy opisy są wystarczające? Czy zapytanie testowe dotarło do CRM? Ten artykuł to lista kontrolna, którą przejdziesz samodzielnie albo razem z firmą wdrażającą.

Co właściwie testujesz, gdy sprawdzasz WebMCP

WebMCP to specyfikacja opracowywana w W3C Community Group przez Google i Microsoft. To jeszcze nie standard. Chrome udostępnia ją w origin trial: to faza testów, w której firmy mogą korzystać z funkcji przed jej oficjalnym wejściem do stabilnej wersji przeglądarki. Wejście do Chrome w wersji stabilnej planowane jest na koniec 2026 roku. Edge też testuje WebMCP. Safari nie zapowiedział wsparcia.

Kiedy przeglądarka nie obsługuje WebMCP, po prostu ignoruje dodatkowe atrybuty na formularzach. Strona wygląda i działa tak samo jak zawsze dla zwykłego użytkownika. Nic się nie psuje.

WebMCP łączy się z szerszym ekosystemem: MCP (Model Context Protocol) to otwarty standard łączenia asystentów AI z programami i usługami, rozwijany pod opieką Linux Foundation. WebMCP to jego rozszerzenie na strony internetowe, pozwalające agentowi AI odczytać dostępne narzędzia bezpośrednio przez przeglądarkę.

Mechanizm działa przez obiekt navigator.modelContext w JavaScript. Kiedy agent AI otwiera Waszą stronę w przeglądarce z WebMCP, może wywołać getTools() i zobaczyć listę narzędzi. Każde narzędzie to zazwyczaj formularz opisany atrybutami: toolname (nazwa), tooldescription (opis, do czego służy) i toolparamdescription (opis każdego pola). Dzięki temu agent rozumie, czym jest formularz wyceny, a czym formularz serwisowy, bez analizowania całego kodu HTML.

Testujesz trzy rzeczy:

• czy atrybuty są dodane i wypełnione sensownie,
• czy opisy są precyzyjne na tyle, żeby agent wiedział, kiedy użyć danego narzędzia,
• czy po wypełnieniu formularza dane faktycznie docierają do Waszego systemu.

Jak przygotować Chrome do testu

Masz dwie drogi. Pierwsza: developer wdrożył token origin trial bezpośrednio w kodzie strony. Wystarczy wtedy otworzyć ją w aktualnym Chrome bez żadnych dodatkowych ustawień. Druga: włączasz flagę eksperymentalną ręcznie.

Jak włączyć flagę:

• Otwórz Chrome i wpisz w pasku adresu chrome://flags.
• W polu wyszukiwania wpisz "Model Context" lub "WebMCP".
• Ustaw flagę na "Enabled".
• Kliknij "Relaunch" na dole strony.

Po restarcie Chrome obsługuje navigator.modelContext. Edge: analogiczna procedura przez edge://flags.

Rób testy na osobnym profilu Chrome albo osobnej instancji przeglądarki. Eksperymentalne flagi mogą wpływać na stabilność innych stron i na sesje logowania.

Jeden krok przed testem: poproś developera o listę wszystkich wdrożonych narzędzi z nazwami toolname. Bez tej listy nie wiesz, czego szukasz w konsoli.

Lista kontrolna do przejścia krok po kroku

Poniżej lista do odhaczenia. Przejdź ją dla każdego narzędzia dostarczonego przez developera.

Przed testem:

• Masz listę wdrożonych narzędzi z nazwami i opisami.
• Chrome ma włączoną obsługę WebMCP (flaga lub token origin trial w kodzie strony).
• Masz dostęp do skrzynki mailowej lub panelu CRM, do których mają trafiać zapytania.
• Masz przygotowane fikcyjne dane testowe: adres e-mail, nazwa firmy, numer telefonu.

Dla każdego narzędzia:

• Otwórz stronę w przygotowanym Chrome i naciśnij F12, żeby otworzyć konsolę.
• W zakładce "Console" wpisz: navigator.modelContext. Jeśli wynik to "undefined", albo flaga nie jest włączona, albo strona nie eksportuje żadnych narzędzi. W obu przypadkach to błąd do wyjaśnienia z developerem.
• Wpisz: navigator.modelContext.getTools() i przejrzyj listę. Czy każda nazwa narzędzia jest zrozumiała? Czy opis odpowiada temu, co miało być wdrożone? Czy liczba narzędzi zgadza się z listą dostarczoną przez developera?
• Sprawdź opisy pól: czy każde pole formularza ma atrybut toolparamdescription wyjaśniający, co to pole oznacza? Na przykład "numer NIP firmy zamawiającej", a nie samo "NIP".
• Wypełnij formularz testowymi danymi i wyślij go ręcznie, tak jak zrobiłby to agent AI.
• Sprawdź w skrzynce lub CRM, czy zapytanie dotarło z poprawnymi danymi.

Po teście wszystkich narzędzi:

• Otwórz stronę w Firefox lub Safari i upewnij się, że formularze działają normalnie dla zwykłego użytkownika.
• Sprawdź, czy strona nie wyświetla błędów JavaScript w konsoli, gdy WebMCP nie jest dostępne.

Jak sprawdzić, że zapytanie dotarło do skrzynki lub systemu

To najważniejszy etap testu. Widoczność narzędzia przez agenta to jedno. Liczy się to, co dzieje się po wysłaniu formularza.

Formularz wysyłający e-mail: sprawdź skrzynkę i folder spam w ciągu 2-3 minut od wysłania testowego. Czy mail zawiera wszystkie pola, które wypełniłeś podczas testu? Poproś developera, żeby zapytania przez agenta były oznaczone w temacie lub nagłówkach, na przykład dopiskiem "źródło: WebMCP". Bez takiego tagowania nie będziesz wiedzieć, czy cokolwiek trafia z tego kanału po uruchomieniu produkcyjnym.

Formularz wysyłający do CRM: otwórz panel i sprawdź, czy pojawił się nowy kontakt albo nowe zdarzenie z poprawnymi danymi. Jeśli system ma logi aktywności, przejrzyj wpisy z ostatnich kilku minut.

Narzędzie zwracające dane: jeśli narzędzie ma odpowiadać na pytania, na przykład o dostępność produktu albo status zamówienia, sprawdź w konsoli Chrome, czy odpowiedź zawiera sensowne dane, a nie błąd 4xx lub 5xx.

U jednego klienta z branży meblarskiej trafiliśmy podczas testu na taki problem: formularz wyceny miał walidację JavaScript, która sprawdzała, czy użytkownik kliknął w pole i opuścił je przez zdarzenia focus i blur. Agent wypełniał pola bez tych zdarzeń i formularz nie wysyłał danych. Wizualnie wyglądało na gotowe, CRM nie dostał żadnego zapytania. Taki błąd wychodzi właśnie podczas testu, nie na etapie wdrożenia.

Co zapisać w raporcie z testu

Raport nie musi być długi. Ma jeden cel: pokazać, co działa, co nie działa i co wymaga poprawki przed odbiorem.

Minimalny raport zawiera:

• datę testu i informację o konfiguracji przeglądarki (Chrome z flagą albo z tokenem origin trial w kodzie strony),
• listę narzędzi z trzema kolumnami: nazwa narzędzia, opis widoczny przez agenta (TAK/NIE), zapytanie dotarło do systemu (TAK/NIE),
• opis konkretnych błędów: co nie zadziałało, na którym kroku, jakie dane testowe były użyte,
• zrzuty ekranu konsoli dla każdego błędu.

Przykład jednego wiersza raportu: "Formularz 'Zapytanie o wycenę okien': opis widoczny TAK, dane dotarły do CRM NIE, błąd: walidacja JS blokuje wysyłkę bez zdarzenia blur na polu e-mail."

Taki raport daje firmie wdrażającej konkretną listę do naprawy. Tobie pozwala sprawdzić, czy kolejna dostarczona wersja naprawiła konkretne punkty. Bez raportu dyskusja o tym, "co nie działa", trwa niepotrzebnie długo.

Pytania, które warto zadać firmie wdrażającej

Jeśli nie chcesz samodzielnie wchodzić w konsolę Chrome, możesz zlecić przeprowadzenie testu firmie wdrażającej. Poproś o konkretne dowody, nie słowne potwierdzenie.

• Pokażcie listę wszystkich wdrożonych narzędzi z nazwami toolname i opisami tooldescription.
• Czy każde pole formularza ma atrybut toolparamdescription?
• Czy przeprowadziliście test z navigator.modelContext.getTools() i możecie pokazać wynik?
• Macie logi albo zrzuty ekranu potwierdzające, że zapytania testowe dotarły do skrzynki lub CRM?
• Co się dzieje ze stroną w przeglądarce bez WebMCP: Firefox, Safari?
• Jak odróżnić w skrzynce lub CRM zapytanie od agenta od zapytania ręcznego?

Dobra firma wdrażająca będzie miała te odpowiedzi gotowe albo przeprowadzi test razem z Tobą przy odbiorze. Jeśli słyszysz "zaufaj nam, wszystko działa", poproś o raport na piśmie.

Jeśli szukasz kogoś, kto poprowadzi wdrożenie WebMCP dla Waszej firmy i dostarczy raport z testu przy odbiorze, sprawdź, co robimy w tym zakresie.

Czego ten test nie sprawdzi

Test z Chrome z flagą WebMCP pokazuje, czy implementacja technicznie działa. Nie powie Ci jednak, czy opisy narzędzi są wystarczająco dobre, żeby popularne agenty faktycznie z nich skorzystały w prawdziwym ruchu. Opisy, które wydają się oczywiste dla developera, mogą być zbyt ogólne dla agenta, który nie zna Waszej branży ani nazewnictwa używanego w firmie. To wymaga testu z prawdziwym agentem AI, nie tylko z konsolą przeglądarki.

Nie sprawdzi też, czy agent rozróżni "formularz wyceny okien" od "formularza reklamacji", jeśli opisy są zbyt podobne. Ani czy backend wytrzyma kilka równoległych zapytań wysłanych przez agentów w tym samym momencie.

Dlatego warto zaplanować tydzień obserwacji po uruchomieniu. Sprawdź, czy w skrzynce lub CRM zaczynają pojawiać się zapytania z tagiem oznaczającym źródło "agent". Jeśli tak: wdrożenie działa w praktyce. Jeśli nic po tygodniu: wróć do listy kontrolnej i zacznij od weryfikacji atrybutów w kodzie strony.

Wdrożenie WebMCP to decyzja, którą można podjąć spokojnie: przeglądarka bez tej obsługi pomija je cicho, więc nic się nie psuje, a strona jest gotowa na agentów, gdy ruch z tego kanału zacznie rosnąć. Żeby jednak miało sens, musi być poprawnie zaimplementowane i potwierdzone testem. Jeśli chcesz omówić, jak taki test wygląda dla konkretnej strony i systemu w Waszej firmie, umów 15 minut rozmowy o WebMCP. Możesz zabrać tę listę kontrolną ze sobą. A jeśli ciekawią Cię przykłady z innych firm, zajrzyj do realnych wdrożeń.