WebMCP — gdy strona staje się narzędziem dla agenta

Wyobraź sobie że agent AI próbuje zarezerwować hotel. Bez WebMCP wygląda to mniej więcej tak: agent robi screenshot strony, analizuje piksele, próbuje zgadnąć który prostokąt jest przyciskiem „Szukaj”, klika — i modli się żeby frontend nie zmienił się od ostatniego razu. To jest model billionów parametrów udający myszkę komputerową.

WebMCP kończy z tym absurdem.

Zamiast zgadywać po wyglądzie — agent wywołuje funkcję. Zamiast klikać w przycisk który może zniknąć po aktualizacji CSS — wywołuje book_hotel({ city: "Kraków", checkIn: "2026-05-10" }). Zamiast parsować DOM w poszukiwaniu sensu — dostaje kontrakt: co ta strona potrafi zrobić, jakie parametry przyjmuje, co zwraca.

To jest zasadnicza zmiana. WebMCP zamienia stronę internetową z interfejsu dla człowieka w narzędzie dla agenta.

Czym dokładnie jest WebMCP

WebMCP (Web Model Context Protocol) to propozycja standardu przeglądarkowego ogłoszona przez Google w lutym 2026 roku, współtworzona z Microsoftem i inkubowana przez grupę W3C Web Machine Learning Community Group. Standard jest dostępny w early preview w Chrome 146 Canary za flagą WebMCP for testing w chrome://flags. Microsoft Edge 147 dodał wsparcie w marcu 2026.

Nazwa nawiązuje do MCP (Model Context Protocol) Anthropic — ale to nie jest to samo. MCP działa po stronie serwera, łącząc agentów z zewnętrznymi narzędziami i bazami danych przez JSON-RPC. WebMCP działa wyłącznie w przeglądarce, przez API navigator.modelContext, i dotyczy tylko interakcji między agentem a konkretną stroną którą użytkownik właśnie ogląda.

Analogia którą Chrome proponuje jest trafna: MCP to infolinia firmy dostępna 24 godziny na dobę. WebMCP to ekspert w sklepie — dostępny tylko gdy jesteś na miejscu, ale zna kontekst którego infolinia nie widzi.

Dwa API — deklaratywne i imperatywne

WebMCP proponuje dwa sposoby na to żeby strona powiedziała agentowi co potrafi.

Declarative API — podejście dla istniejących stron, minimalna zmiana kodu. Standardowe formularze HTML wzbogacone o atrybuty które agent rozumie:

<form
  toolname="search_flights"
  tooldescription="Wyszukaj dostępne loty między miastami">
  <input name="origin" placeholder="Skąd">
  <input name="destination" placeholder="Dokąd">
  <input name="date" type="date">
  <button type="submit">Szukaj</button>
</form>

Agent widzi ten formularz nie jako zestaw pól do kliknięcia, ale jako narzędzie z nazwą, opisem i zdefiniowanymi parametrami. Wie co formularz robi zanim go użyje. Opcjonalny atrybut toolautosubmit pozwala agentowi wysłać formularz automatycznie bez czekania na potwierdzenie użytkownika — tam gdzie to ma sens.

Imperative API — podejście dla bardziej złożonych interakcji które wymagają JavaScript:

navigator.modelContext.registerTool({
  name: "add_to_cart",
  description: "Dodaj produkt do koszyka",
  inputSchema: {
    type: "object",
    properties: {
      productId: { type: "string" },
      quantity: { type: "number" }
    },
    required: ["productId"]
  },
  execute: async (params) => {
    await cart.add(params.productId, params.quantity);
    return { success: true, cartTotal: cart.getTotal() };
  }
});

Agent może teraz zapytać stronę „co potrafisz?” i dostać listę dostępnych narzędzi z dokładnymi schematami wejść i wyjść. Wywołuje narzędzie jak funkcję, dostaje wynik — bez screenshotów, bez zgadywania, bez kruchych selektorów CSS.

Human-in-the-loop wbudowany w standard

Ważna rzecz na którą warto zwrócić uwagę: WebMCP jest projektowane wokół modelu cooperative, nie autonomicznego. Standard nie zakłada że agent działa bez nadzoru użytkownika — zakłada że użytkownik jest obecny i agent wspiera jego działania.

Narzędzia WebMCP mogą wymagać potwierdzenia przed wykonaniem wrażliwej akcji. W demie hotelowym Cloudflare narzędzie complete_booking zatrzymuje się i czeka na kliknięcie „Potwierdź rezerwację” przez użytkownika przed finalizacją. To jest human-in-the-loop wbudowany na poziomie protokołu, nie jako opcjonalne zabezpieczenie.

Chrome definiuje trzy filary WebMCP: Context — dane które agent potrzebuje żeby rozumieć co robi użytkownik, Capabilities — akcje które agent może wykonać, Coordination — mechanizm przekazywania kontroli między agentem a użytkownikiem gdy agent napotka sytuację którą sam nie może rozwiązać.

To jest fundamentalna różnica wobec w pełni autonomicznych agentów którzy działają bez wiedzy użytkownika. WebMCP zakłada że użytkownik jest przy ekranie i agent mu asystuje — nie zastępuje go.

Czym WebMCP różni się od dotychczasowych podejść

Żeby zrozumieć co WebMCP zmienia, warto zobaczyć co zastępuje.

Dziś agent który chce coś zrobić na stronie ma kilka opcji — każda z problemami. Playwright i Puppeteer działają przez automatyzację przeglądarki: agent klika, wypełnia formularze, nawiguje. Kruche bo zależy od selektorów CSS które zmieniają się przy każdym redesignie. Wolne bo każda akcja to osobne renderowanie. Kosztowne w tokenach bo agent musi analizować HTML żeby zrozumieć kontekst.

Alternatywą jest screen scraping — agent robi screenshoty i analizuje co widzi. Jeszcze bardziej kruche, jeszcze wolniejsze, absolutnie nieprzewidywalne na stronach z animacjami i dynamicznym contentem.

WebMCP eliminuje te problemy przez to że strona sama deklaruje swoje możliwości. Agent nie musi zgadywać — dostaje kontrakt. Komunikacja przez navigator.modelContext jest prawie natychmiastowa bo omija renderowanie i parsowanie DOM. Schematy JSON eliminują hallucynacje — agent wie dokładnie jakich parametrów wymaga narzędzie i co zwróci.

Jak opisuje artykuł o szóstym filarze agent-readiness na webflux.pl, operacyjność strony — zdolność do bycia obsługiwanej przez agenta — jest jednym z kluczowych wymiarów gotowości na erę agentów. WebMCP to najbardziej bezpośrednia odpowiedź na pytanie jak tę operacyjność zapewnić.

Stan adopcji i co to znaczy dziś

WebMCP jest wciąż eksperymentalny. Chrome 146 Canary za flagą, Edge 147 z wbudowanym wsparciem, Firefox i Safari bez ogłoszonych planów. Formal launch oczekiwany w połowie do końca 2026 — Google I/O i Google Cloud Next wymieniane jako prawdopodobne miejsca szerszego ogłoszenia.

To nie jest standard który możesz wdrożyć produkcyjnie dziś i liczyć na szeroką adopcję. To jest standard który warto rozumieć i eksperymentować z nim teraz — bo gdy trafi do stable Chrome, strony które będą miały zaimplementowane narzędzia WebMCP będą od razu agent-ready dla milionów użytkowników Chrome.

Cloudflare już udostępnił WebMCP w swoim Browser Run dla deweloperów którzy chcą testować agentowe interakcje ze stronami. Demo hotelowe Google pozwala zobaczyć jak agent nawiguje przez search, wybór pokoju i rezerwację przez wywołania narzędzi zamiast klikania.

Co WebMCP oznacza dla twojej strony

Na dziś — warto zrozumieć kierunek i zacząć myśleć o swojej stronie jako o zbiorze narzędzi, nie tylko treści.

Pytanie które WebMCP stawia każdemu właścicielowi strony brzmi: co twoja strona potrafi zrobić? Nie jak wygląda, nie co opisuje — co robi. Jakie akcje są na niej dostępne? Wyszukiwanie, rezerwacja, dodanie do koszyka, wysłanie zapytania — każda z tych akcji to potencjalne narzędzie WebMCP.

Im wcześniej zaczniesz myśleć w tych kategoriach, tym łatwiej będzie wdrożenie gdy standard stanie się produkcyjny. A semantyczny HTML, jasna struktura i dane strukturalne — które są fundamentem agent-readiness już dziś — będą naturalnym fundamentem pod WebMCP jutro.

Jak sprawdzić czy strona zbudowana w Divi jest czytelna dla agentów na poziomie który umożliwi wdrożenie WebMCP — opisuje artykuł Agent-ready Divi 5 

Pojęcia powiązane w słowniku: MCP, Agent Skills, Operacyjność, Human-in-the-loop, Agent-readiness, Dane strukturalne

Powiązane artykuły: Sześć filarów agent-readiness, Agent-ready Divi 5