Google prezentuje WebMCP: protokół (i API) do „agent-native” interakcji z WWW

W lutym 2026 Google (zespół Chrome) pokazało WebMCP (Web Model Context Protocol) w trybie early preview jako odpowiedź na rosnący problem: dzisiejsze agenty AI najczęściej „udają człowieka”, klikając po UI na podstawie zrzutów ekranu/DOM, co bywa wolne, kruche i nieprzewidywalne. WebMCP ma to odwrócić: strona sama publikuje kontrakt interakcji (zestaw narzędzi/akcji), które agent może wywołać w sposób strukturalny, zamiast zgadywać znaczenie przycisków.

Najważniejsza idea w 1 zdaniu

WebMCP pozwala witrynie wystawić „narzędzia” (tools) jako funkcje z opisem i schematem wejścia/wyjścia, które agent może bezpośrednio wywoływać przez przeglądarkę — szybciej i pewniej niż poprzez czystą „akt uację” UI (klikanie/scroll/typing).

Co dokładnie ogłosił Google i w jakim statusie to jest?

1) Early preview w Chrome (program EPP)

Google udostępniło WebMCP do prototypowania w ramach Early Preview Program (EPP) dla rozwiązań „AI on Chrome”. W praktyce oznacza to: szybkie iteracje, testy, demka i zbieranie feedbacku, zanim cokolwiek trafi do stabilnych wydań.

2) Równolegle: specyfikacja w W3C Community Group

Równolegle istnieje publiczna specyfikacja WebMCP – Draft Community Group Report (10 lutego 2026) w ramach Web Machine Learning Community Group. To ważny sygnał: kierunek ma ambicję standardu webowego, ale to jeszcze nie jest W3C Standard ani ścieżka standardyzacji W3C (na razie inkubacja w CG).

Dlaczego obecne „agent browsing” jest problemem?

W typowym trybie „agent przegląda stronę” model musi:

zrozumieć układ strony (często z obrazu lub DOM),
zgadnąć, które elementy są interaktywne,
odtworzyć sekwencję kroków (formularz, walidacje, modale, paginacje),
i radzić sobie z dynamicznym JS.

To działa… dopóki nie działa: drobna zmiana UI potrafi złamać przepływ, a koszt obliczeniowy i czas rosną. WebMCP przenosi ciężar z „zgadywania UI” na jawny, wersjonowalny kontrakt działań dostarczany przez samą witrynę.

Jak działa WebMCP: „Tool Contract” przez `navigator.modelContext`

W materiałach Google i w repozytorium/specyfikacji przewija się kluczowy element: nowe API w przeglądarce (wczesna forma) oparte o navigator.modelContext, dzięki któremu strona może zarejestrować narzędzia (tools) dla agentów.

Tools = funkcje z opisem + schema

Każde narzędzie jest jak „bezpieczny endpoint” w obrębie strony:

ma nazwę (np. searchFlights, createSupportTicket, addToCart),
ma opis w języku naturalnym (dla modelu),
ma schemat wejścia (struktura parametrów),
ma handler (implementacja), która robi realną rzecz w aplikacji webowej.

W efekcie agent nie musi klikać „Szukaj” i zgadywać, gdzie jest filtr — tylko wywołuje narzędzie z parametrami.

Dwa tryby: Declarative vs Imperative

Google opisuje WebMCP jako zestaw podejść do wystawiania akcji:

Declarative API

Dla „standardowych” interakcji możliwych do opisania wprost w HTML (np. formularze). To ma umożliwić proste udostępnienie działań bez budowania rozbudowanych integracji.

Imperative API

Dla złożonych przypadków, gdzie potrzebny jest JavaScript i logika aplikacji (dynamiczne UI, asynchroniczne kroki, walidacje, wiele stanów).

Przykładowe zastosowania (z materiałów Google)

Google podaje przykłady, w których WebMCP ma największy sens:

Customer support: agent wypełnia zgłoszenie z technicznymi detalami zamiast prosić użytkownika o przeklejanie danych,
E-commerce: wyszukiwanie/konfiguracja produktów i przechodzenie przez checkout „po narzędziach”, nie po kruchych kliknięciach,
Travel: filtrowanie wyników i rezerwacje z mniejszym ryzykiem błędu.

Bezpieczeństwo, prywatność i kontrola

Jedną z kluczowych tez WebMCP jest to, że interakcja odbywa się w obrębie przeglądarki i jej modelu bezpieczeństwa (origin, sesje użytkownika, uprawnienia), a nie przez „zewnętrzny bot” z osobnym logowaniem. To ma ułatwiać scenariusze „user-present” (użytkownik obok agenta, w tej samej sesji), a specyfikacja poświęca osobne sekcje rozważaniom dot. security/privacy.

Jak to się ma do MCP (Model Context Protocol)?

W dokumentach WebMCP często pojawia się analogia: strona z WebMCP jest jak „serwer MCP”, tylko że narzędzia są wystawiane po stronie klienta (w przeglądarce), a nie na backendzie.

W ekosystemie pojawiają się też warstwy „mostkujące” (polyfill/translator), które mają ułatwiać współpracę świata WebMCP z klientami MCP.

Co to może zmienić dla firm i właścicieli stron?

1) „Agent-Ready UX” stanie się osobną warstwą produktu

Tak jak kiedyś „mobile-friendly”, a potem „API-first”, tak teraz może dojść „agent-first”: nie tylko ładny interfejs dla człowieka, ale też jawne narzędzia dla agentów.

2) Koniec (części) problemów z kruchą automatyzacją

Zamiast utrzymywać kosztowną automatyzację opartą o selektory i DOM, strona może udostępniać stabilne akcje, które łatwiej wersjonować i testować.

3) Nowy obszar optymalizacji: „Toolability”

Jeśli agent ma kupować, rezerwować, składać wnioski czy zakładać tickety, to „czytanie treści” przestaje wystarczać — liczy się jak szybko i bezbłędnie da się wykonać zadanie.

Minimalny „mental model” wdrożenia

Zidentyfikuj 10–30 najważniejszych zadań użytkownika (np. „znajdź produkt”, „dobierz wariant”, „poproś o ofertę”, „złóż zgłoszenie”).
Zamień je na narzędzia (tools) z jasnym schematem wejścia/wyjścia.
Zadbaj o:
- walidacje,
- uprawnienia,
- potwierdzenia kroków wrażliwych (zakup/płatność),
- logowanie zdarzeń i testy regresji.
Dopiero potem myśl o „agentic funnel” i automatyzacji na większą skalę.