Google właśnie pokazał mechanizm, który pozwala stronom internetowym mówić agentom AI wprost: oto co potrafię, oto jak możesz ze mnie skorzystać. Nazywa się webMCP i działa wewnątrz przeglądarki Chrome — na razie jako wczesny podgląd techniczny (Early Preview Program). Jeśli klasyczny protokół MCP łączy modele językowe z zewnętrznymi narzędziami po stronie serwera, to webMCP przenosi tę samą ideę na front — do aktywnej karty przeglądarki, tam gdzie użytkownik widzi stronę.
Czym właściwie jest webMCP i skąd się wzięło
Aby zrozumieć webMCP, trzeba najpierw cofnąć się o krok. Model Context Protocol (MCP) to otwarty standard opracowany przez Anthropic, który definiuje sposób, w jaki duże modele językowe odkrywają i wywołują zewnętrzne narzędzia — bazy danych, API, systemy plików. Serwer MCP opisuje dostępne „tools” w formacie JSON, a klient (agent AI) wybiera odpowiednie narzędzie, przekazuje parametry i odbiera wynik. Całość odbywa się po stronie backendu, zwykle przez połączenie HTTP lub stdio.
WebMCP zadaje inne pytanie: co jeśli narzędziem nie jest API, lecz sama strona internetowa? Sklep, portal podróżniczy, panel klienta — każdy z nich ma interfejs graficzny pełen przycisków, formularzy i filtrów. Dla człowieka to naturalne środowisko pracy. Dla agenta AI — labirynt DOM-u, który trzeba parsować, zgadywać intencje projektanta i liczyć się z tym, że przy następnej aktualizacji wszystko się zmieni.
WebMCP rozwiązuje ten problem. Twórca strony sam deklaruje zestaw akcji (tools) i encji (entities), które agent może wywołać. Zamiast skrobać HTML, agent otrzymuje ustrukturyzowany opis: „możesz wyszukać produkt”, „możesz dodać do koszyka”, „możesz zmienić datę rezerwacji”.
WebMCP a MCP – dwa światy tego samego protokołu
Na pierwszy rzut oka webMCP i MCP robią to samo: pozwalają agentowi AI korzystać z narzędzi. Różnica tkwi w miejscu, w którym te narzędzia żyją. MCP operuje po stronie serwera. Agent łączy się z dedykowanym endpointem, przesyła zapytanie i dostaje odpowiedź, bez udziału przeglądarki, bez karty, bez interfejsu graficznego. To świetnie sprawdza się przy integracjach z bazami danych, systemami CRM czy wewnętrznymi API firmy.
WebMCP działa wyłącznie w kontekście aktywnej karty Chrome. Agent widzi to, co widzi użytkownik, i może wykonywać akcje zdefiniowane przez stronę, ale tylko wtedy, gdy ta karta jest otwarta i aktywna. Nie zastępuje backendu. Uzupełnia go tam, gdzie backend nie wystarczy: w dynamicznych interfejsach, w procesach wymagających interakcji z UI, w scenariuszach, gdzie użytkownik chce, by agent „klikał za niego” w sposób bezpieczny i kontrolowany.
Oba podejścia mogą i powinny współistnieć. Agent AI może najpierw przez klasyczny MCP sprawdzić dostępność hoteli w API rezerwacyjnym, a potem przez webMCP wypełnić formularz na stronie linii lotniczej, bo ta akurat nie udostępnia publicznego API. Backend i frontend stają się komplementarnymi kanałami, a nie konkurentami.
Jak to wygląda od strony technicznej
Twórca strony rejestruje narzędzia (tools) za pomocą nowego API w przeglądarce. Każde narzędzie ma nazwę, opis w języku naturalnym i schemat parametrów wejściowych. Gdy agent AI — na przykład wbudowany asystent Chrome’a lub rozszerzenie korzystające z modelu językowego — odwiedza stronę, otrzymuje listę dostępnych narzędzi. Następnie może jedno z nich wywołać, przekazując odpowiednie argumenty. Strona obsługuje wywołanie i zwraca wynik.
Obok narzędzi webMCP wprowadza pojęcie encji (entities). To ustrukturyzowane opisy obiektów widocznych na stronie — produkty, rezerwacje, zgłoszenia. Dzięki nim agent nie musi interpretować wizualnego układu, by zrozumieć, na co patrzy. Otrzymuje gotowy kontekst semantyczny, uporządkowany i jednoznaczny.
Warto podkreślić jedną rzecz: webMCP nie daje agentowi wolnej ręki. Agent nie może klikać w dowolne elementy DOM-u ani wstrzykiwać kodu. Może wyłącznie korzystać z akcji, które strona jawnie mu udostępniła. To zasadnicza różnica w porównaniu z podejściem „computer use”, gdzie agent steruje myszką i klawiaturą. Tutaj kontrola zostaje po stronie twórcy witryny.
Gdzie webMCP ma sens – konkretne scenariusze
Zacznijmy od e-commerce. Sklep internetowy deklaruje narzędzia: wyszukaj produkt, filtruj po kategorii, dodaj do koszyka, zastosuj kod rabatowy. Użytkownik mówi agentowi: „Znajdź mi buty do biegania do 400 zł, rozmiar 43, dodaj najtańsze do koszyka”. Agent wywołuje kolejno odpowiednie narzędzia, nie zgadując selektorów CSS. Sklep zyskuje pewność, że agent korzysta z oficjalnych ścieżek, a nie z kruchych skryptów scrapujących.
Drugi scenariusz to obsługa klienta. Portal support’owy udostępnia narzędzia: sprawdź status zgłoszenia, dodaj komentarz, zmień priorytet. Agent działa jako warstwa pośrednia między użytkownikiem a stroną, automatyzując powtarzalne czynności bez potrzeby budowania osobnego API. Dla firm, które mają rozbudowany frontend, ale ograniczone zasoby backendowe, to istotna oszczędność.
Trzeci — branża turystyczna. Strona linii lotniczej lub agregatora podróży deklaruje: wyszukaj loty, zmień daty, wybierz miejsce. Agent może przeprowadzić użytkownika przez cały proces rezerwacji, operując na oficjalnych narzędziach strony zamiast na niestabilnych obejściach. To szczególnie cenne w złożonych formularzach wieloetapowych, gdzie tradycyjna automatyzacja łatwo się gubi.
Early Preview
Trzeba jasno powiedzieć: webMCP jest na wczesnym etapie. Google udostępnił go w ramach Early Preview Program, co oznacza, że API może się zmienić, a specyfikacja nie jest jeszcze zamrożona. Na dziś mechanizm działa wyłącznie w przeglądarce Chrome, wymaga aktywnej karty i nie obejmuje scenariuszy offline ani pracy w tle.
Lista ograniczeń jest uczciwa. WebMCP nie obsługuje jeszcze autoryzacji w rozbudowanym sensie, nie ma wbudowanego mechanizmu OAuth ani zarządzania sesjami agenta. Nie rozwiązuje kwestii prywatności danych przesyłanych między stroną a agentem w sposób, który satysfakcjonowałby regulatorów w każdym scenariuszu. Nie zastępuje też istniejących standardów dostępności — raczej je uzupełnia, dodając warstwę semantyczną skierowaną konkretnie do agentów AI.
Mimo to kierunek jest wyraźny. Jak zauważa zespół Chrome: „The web should be a first-class platform for AI agents” – sieć powinna być pełnoprawną platformą dla agentów AI. To nie tylko ambicja technologiczna, ale też pragmatyczne rozpoznanie faktu, że agenci AI już dziś próbują korzystać ze stron internetowych, tyle że na własną rękę, metodami kruchymi i nieefektywnymi.
Co to zmienia dla twórców stron
Dla deweloperów webMCP to nowa warstwa do zaimplementowania, ale też nowa szansa. Strona, która deklaruje swoje narzędzia, staje się „agent-friendly” — łatwiejsza do automatyzacji, bardziej przewidywalna w interakcji z AI, mniej podatna na scraping niszczący strukturę.
Warto myśleć o tym jak o odpowiedniku pliku robots.txt, ale dla agentów AI. Zamiast mówić robotom „nie indeksuj tej podstrony”, mówisz agentom „oto co możesz tu zrobić, a oto czego robić nie powinieneś”. To deklaratywne podejście do współpracy, nie do blokowania.
Integracja z istniejącymi stronami nie wymaga przepisywania aplikacji od zera. Twórca dodaje warstwę deklaracji narzędzi i encji — coś w rodzaju ustrukturyzowanego opisu tego, co strona już potrafi. Jeśli sklep ma już koszyk i wyszukiwarkę, webMCP pozwala opisać je w sposób zrozumiały dla modelu językowego.
