Spis treści
Wyobraź sobie, że ktoś przychodzi na Twoją stronę z zawiązanymi oczami, dostaje opis obrazka i ma na jego podstawie wypełnić formularz kontaktowy. Mniej więcej tak wygląda dziś praca agenta w przeglądarce. Robi zrzut, zgaduje, który prostokąt jest przyciskiem „wyślij”, klika, robi kolejny zrzut, sprawdza, czy się udało. Za każdą rundę płacisz tokenami, a przy okazji ten cały łańcuch rozsypuje się przy pierwszym redesignie.
WebMCP jest odpowiedzią na dokładnie ten problem. I na żaden inny.
To jest sedno, bo połowa materiałów, które teraz krążą po LinkedInie, sprzedaje WebMCP jako „SEO dla agentów”. Nie jest. Widoczność i wykonanie to dwie osobne sprawy, a mylenie ich kosztuje najwięcej tych firm, które wcale nie potrzebują wdrożenia.
Agent widzi Twoją stronę tak, jak Ty widzisz zrzut ekranu
Zacznijmy od tego, co się psuje. Agent w karcie przeglądarki operuje na tym samym interfejsie co człowiek: na pikselach i na drzewie DOM. Musi wywnioskować, że pole z etykietą „Imię” chce imienia, a nie imienia i nazwiska razem. Musi zgadnąć, czy <select> z trzema pozycjami to wybór działu, czy sposób dostawy. Każda taka decyzja jest interpretacją, a interpretacja czasem trafia.
Objaśnienie z explainera WebMCP jest krótsze niż mój akapit: „Any task that a user can accomplish through a page’s UI can be turned into a tool by reusing much of the page’s existing client-side code”. Zadanie, które człowiek może wykonać klikając, można opisać jako narzędzie, korzystając z kodu, który już masz.
I tyle. Bez magii.
Czym WebMCP jest naprawdę
WebMCP to propozycja standardu przeglądarkowego, która pojawia się na stronie jako document.modelContext. Uwaga na starsze teksty, także te sprzed kilku miesięcy: przez długi czas API nazywało się navigator.modelContext i pod tą nazwą wciąż krąży w połowie tutoriali. Dokumentacja Chrome zaktualizowana 1 września 2026 mówi już wyłącznie o document.
Strona rejestruje przez to API narzędzia. Narzędzie ma nazwę, opis w naturalnym języku i schemat wejścia w JSON Schema. Agent pyta „co potrafisz”, dostaje listę, wybiera jedno i podaje ustrukturyzowane argumenty. Bez zgadywania, który przycisk to ten właściwy.
Są dwa sposoby, żeby to zrobić.
Deklaratywny to dwa atrybuty na istniejącym formularzu HTML: toolname i tooldescription. Przeglądarka sama przerabia pola formularza na schemat wejścia, biorąc opisy z etykiet albo z opcjonalnego toolparamdescription. Chrome opisuje ten wariant w kartotece funkcji jako taki, który „requires only adding attributes to existing form elements” i nie wymaga przebudowy strony. Kiedy agent woła narzędzie, przeglądarka przenosi fokus na formularz i wypełnia pola, a formularz zostaje widoczny dla człowieka.
Imperatywny to document.modelContext.registerTool() w JavaScripcie, z własną funkcją execute. Tu opisujesz nie formularz, tylko czynność aplikacji: wyszukiwanie, filtrowanie, zmianę stanu, nawigację do właściwego kroku.
Narzędzie WebMCP wykonuje się na oczach użytkownika, w jego zalogowanej sesji, w jego karcie. Agent nie dostaje kopii Twojej aplikacji do swojego okna. Jest u Ciebie w gościach.
To sformułowanie jest z dokumentacji Chrome i warto je zapamiętać, bo dobrze pokazuje różnicę wobec wszystkiego, co znasz z integracji: „Instead of your application being a guest within an agent, the agent is a guest on your platform”.
Trzy warstwy, które prawie wszyscy mylą
Tu leży cały nieporozumieniowy węzeł. Rozplączmy go raz.
Warstwa pierwsza to czytanie. Crawler, indeks, model, który streszcza Twoją ofertę. Załatwiasz ją strukturą treści, czystym markdownem i plikiem llms.txt. Działa dla każdego agenta na świecie, także dla tych, które nigdy nie otworzą przeglądarki. Nasz punkt odniesienia w researchu konkurencji, Phenomenon Studio, ma dokładnie to: publiczny llms.txt i wygenerowaną z niego stronę z faktami o firmie. Zero WebMCP. I to nie jest zaniedbanie, tylko trafna kolejność.
Warstwa druga to MCP serwerowy. Protokół łączący agenta z Twoim backendem, niezależnie od przeglądarki. Uniwersalny, trwały, działa w tle, ma SDK w kilku językach.
Warstwa trzecia to WebMCP. Tylko przeglądarka, tylko otwarta karta, tylko żywa sesja. Dokumentacja Chrome nazywa te narzędzia ulotnymi wprost: „WebMCP tools are ephemeral. They exist only when your page is open”.
Czytanie, MCP serwerowy i WebMCP rozwiązują trzy różne problemy - i tylko ostatni z nich potrzebuje otwartej karty
Jedna warstwa nie zastępuje drugiej. Zapisz sobie zdanie z dokumentacji Google, jeśli ktoś w Twojej firmie będzie próbował, żeby WebMCP „załatwiło temat AI”: „WebMCP is not an extension or a replacement of MCP”.
Gdzie to stoi 4 września 2026
Z daleka wygląda to na standard gotowy do wysyłki. Z bliska - nie bardzo.
W kartotece Chrome (funkcja 5117755740913664) WebMCP ma aktywny etap „Prepare to ship”, ale status wysyłki wciąż brzmi „Proposed”, a pole is_released stoi na false. Przeglądy TAG, bezpieczeństwa i prywatności są w toku. Dev trial ruszył w Chrome 146 za flagą, origin trial obejmuje wersje od 149 do 156. Dziś stabilny Chrome to 153.0.8010.27, czyli jesteśmy w połowie tego okna, a wersja 156 wchodzi do kanału stabilnego 20 października 2026.
Firefox: „No signal”. WebKit: „No signal”. Dosłownie te dwa słowa, bez komentarza.
Specyfikacja to Draft Community Group Report z 3 września 2026, redagowany przez trzy osoby: jedną z Microsoftu i dwie z Google. Community Group to inkubacja, nie ścieżka rekomendacji W3C.
A kto dziś naprawdę woła te narzędzia? Tu jest najciekawszy kawałek i on się zmienił w sierpniu.
OpenAI uruchomił „Site tools”, własną implementację WebMCP we wbudowanej przeglądarce aplikacji desktopowej ChatGPT. Narzędzia odkrywają ChatGPT Work i Codex, użytkownik widzi je w panelu przy pasku adresu, każde wywołanie przechodzi przegląd bezpieczeństwa. Ale jest haczyk i on jest gruby: dokumentacja OpenAI wymienia dwa nieobsługiwane fragmenty API, a pierwszym z nich jest API deklaratywne. „Tools defined through HTML form attributes aren’t available as site tools”. Czyli formularz z toolname i tooldescription jest dla ChatGPT niewidoczny. Widzi tylko registerTool.
Cloudflare wypuścił 6 sierpnia developer preview: przełącznik w panelu, który wstrzykuje mostek WebMCP do każdej strony na krawędzi, bez ruszania kodu serwisu. Ich zdalna przeglądarka BrowserRun już potrafi wołać narzędzia.
Anthropic, czyli rozszerzenie Claude w Chrome: zgłoszenie o wsparcie WebMCP wisiało od marca i zostało zamknięte 8 kwietnia 2026 jako „not planned”, automatycznie, po okresie bezczynności. Na dziś tamtędy nie zadziała.
Do tego rozszerzenie Model Context Tool Inspector od Google, którym testuje się własne narzędzia, i garść rozszerzeń na polyfillu - Google podaje w kartotece, że w Chrome Web Store jest około dziewięciu takich pozycji z oceną cztery gwiazdki lub wyższą.
Cztery klienty, dwa API i jeden wniosek: formularz z atrybutami jest najtańszy, ale widzi go najmniej narzędzi
Test w dwóch pytaniach, czy to w ogóle Twój problem
Nie potrzebujesz warsztatu ani audytu, żeby to rozstrzygnąć. Wystarczą dwa pytania.
Czy Twoja strona ma czynność, nie tylko treść? Koszyk, rezerwacja, konfigurator, filtry na tysiącu ofert, panel klienta, wieloetapowy formularz zgłoszeniowy. Coś, co użytkownik robi, a nie tylko czyta.
Czy ta czynność jest dziś dla agenta zgadywanką? Kalendarz z własnym widżetem daty. Filtr, który przeładowuje wyniki bez zmiany adresu. Formularz, w którym trzeba trafić w zależność między dwoma polami.
Dwa razy „tak” i masz realny powód, żeby zacząć. Choć jedno „nie” i lepszy zwrot dostaniesz z treści.
Koszyk i konfigurator przechodzą ten test, wizytówka z jednym formularzem kontaktowym nie
Nie warto zaczynać od WebMCP
- Serwis wizerunkowy, którego jedyną czynnością jest formularz kontaktowy.
- Blog i baza wiedzy, gdzie cała wartość siedzi w treści do przeczytania.
- Landing z jednym CTA prowadzącym na zewnętrzny system rezerwacji.
- Aplikacja, do której i tak wchodzi się przez logowanie za paywallem.
Warto zacząć od WebMCP
- Sklep z filtrami, koszykiem i historią zamówień.
- System rezerwacji, w którym wybór terminu ma własną, nieoczywistą logikę.
- Konfigurator produktu z kilkunastoma parametrami zależnymi od siebie.
- Panel klienta, w którym powtarzalne zadania zajmują użytkownikowi kwadrans.
- Wyszukiwarka ofert, gdzie różnica między dobrym a złym filtrem to setki wyników.
Co zrobiliśmy u siebie i czego świadomie nie zrobiliśmy
Nasz serwis wpada dokładnie w tę pierwszą kategorię, więc potraktowaliśmy WebMCP jako dwugodzinny eksperyment, nie projekt. Dwa formularze leadowe, kontakt i bezpłatna konsultacja, dostały toolname i tooldescription. Nazwy narzędzi są angielskie i te same dla obu wersji językowych: sendContactRequest i bookFreeConsultation. Opisy tłumaczymy, bo agent czyta je jak zdanie i podejmuje na ich podstawie decyzję.
Trzy decyzje, których nie widać w kodzie, a które były w tym wdrożeniu najważniejsze.
Po pierwsze, atrybuty są opt-in per strona, nie wpięte na stałe w komponent formularza. Powód jest brutalnie praktyczny: modal kontaktowy stoi w naszym layoucie bazowym, czyli na każdej stronie serwisu. Deklaratywne narzędzie rejestruje się także w ukrytym formularzu, a przeglądarka przy wywołaniu próbowałaby taki formularz sfokusować. Rejestracja narzędzia „sam kontakt” na stronie o cenniku to szum, który psuje agentowi wybór.
Po drugie, bez toolautosubmit. Ten atrybut wysyła formularz bez kliknięcia człowieka. Nasz formularz przechodzi przez Turnstile i zapisuje leada w CRM-ie. Agent może go wypełnić do końca, ale przycisk naciska człowiek. Kropka.
Po trzecie, w zdarzeniu wysyłki czytamy flagę agentInvoked i dopisujemy ją do notatki w CRM jako ślad, że zgłoszenie przyszło od agenta. Wyłącznie jako informację. Nigdy do autoryzacji, nigdy do omijania weryfikacji - bo pole, które przychodzi z przeglądarki, jest deklaracją, a nie dowodem.
Zaczęliśmy od wariantu deklaratywnego, bo był najtańszy: dwa atrybuty na formularzu, który i tak już mieliśmy. Tą drogą dociera Chrome z włączoną flagą albo z rejestracją w origin trialu i rozszerzenia zgodne z pełnym API. Nie dociera ChatGPT - jego dokumentacja wprost mówi, że atrybutów na formularzu nie widzi. Dlatego na tych samych dwóch formularzach obok toolname i tooldescription stoi dziś document.modelContext.registerTool(), z tą samą nazwą i tym samym opisem narzędzia, żeby obie rejestracje się nie rozjechały. execute wypełnia pola i zwraca wynik, formularza nie wysyła - zostaje to samo zatwierdzenie przez człowieka i ten sam Turnstile co w wersji deklaratywnej. Chrome i ChatGPT sięgają po to samo narzędzie dwiema drogami. Claude w przeglądarce po żadną z nich.
Czy żałuję? Nie bardzo - przy dwóch formularzach leadowych dołożenie registerTool i skryptu, który pilnuje limitów znaków w opisach narzędzi, to popołudnie, nie sprint. Ale gdyby to była aplikacja z koszykiem, ta sama kolejność - najpierw najtańsze, lukę dogonić później - byłaby kosztowną pomyłką: tam odległość między dwoma atrybutami a przebudową na registerTool liczy się w tygodniach, nie w popołudniu.
Kolejność, w której to się opłaca
Na koniec praktyka. Jeżeli chcesz być użyteczny dla agentów, rób to od najtańszego.
Najpierw treść i struktura. Nagłówki, które mówią o czym jest sekcja. Odpowiedzi na pytania klientów zapisane wprost, a nie ukryte w akordeonie ładowanym JavaScriptem. Nazwy pól formularza, które znaczą to, co znaczą. To pomaga jednocześnie ludziom, wyszukiwarce i agentom, i nie kosztuje nic poza pracą redakcyjną.
Potem czytelna wersja maszynowa: bliźniaki markdown i llms.txt. Nadal warstwa czytania, nadal działa wszędzie.
Potem serwer MCP, ale tylko jeśli masz backend z sensownymi operacjami i klientów, którzy naprawdę chcą się z nim łączyć.
I dopiero na końcu WebMCP, przy realnej czynności. Wersja deklaratywna jako sonda, wersja imperatywna na registerTool, jeśli chcesz, żeby zobaczyła ją dzisiejsza aplikacja ChatGPT. Zacznij od jednego, najważniejszego zadania użytkownika, nie od piętnastu narzędzi naraz - dokumentacja Chrome przypomina, że każde narzędzie zjada kawałek okna kontekstu agenta i utrudnia mu wybór.
Jeżeli projektujesz właśnie funkcję AI w swoim produkcie, to warstwa interfejsu ma osobne reguły i rozkładamy je w tekście o wzorcach UX i stanach funkcji AI. Jeżeli Twoja funkcja rozmawia z użytkownikiem, dochodzi jeszcze strona formalna, czyli obowiązki przejrzystości z artykułu 50 AI Act.
A jeśli chcesz sprawdzić, które czynności w Twoim produkcie w ogóle warto wystawić agentom, tym zajmujemy się w usłudze Agenci AI. Zakres i wycena zawsze zależą od tego, co aplikacja robi, więc najprościej napisz do nas i pokaż produkt.
Współzałożyciel i CEO Agencji UX Wzór. Od 9 lat prowadzi projekty UX/UI dla startupów, software house'ów i dużych firm - od audytów, badań i analizy biznesowej, przez strategię produktu, po wdrożenie. Specjalizuje się w projektach na styku e-commerce, SaaS i fintech. Praktyk Interaktywnego projektu - projektowania UX/UI bezpośrednio w kodzie.
