Co to jest WebMCP i co przygotować na stronie, zanim agenci AI zaczną z niej korzystać

Agent AI, który dostał polecenie „wyślij zapytanie o wycenę do tej firmy”, trafia na formularz z pięcioma polami i przyciskiem „Wyślij”. Nie wie, czy pole „temat” ma dostać nazwę usługi czy tytuł wiadomości, w jakim formacie wpisać telefon i czy po kliknięciu wiadomość pójdzie od razu, czy pojawi się jeszcze jeden ekran. Radzi sobie, jak umie: czyta etykiety z drzewa dostępności, o którym pisaliśmy w drugim wpisie serii, i zgaduje. WebMCP ma to zgadywanie zakończyć.

W tym wpisie tłumaczymy, czym jest WebMCP, kto go rozwija i jak wygląda w kodzie na przykładzie formularza kontaktowego. Pokazujemy też, co z WebMCP sprawdza Lighthouse, dlaczego te kontrole mają dziś wagę zero, i co zrobić już teraz, żeby dopisanie atrybutów za kilka miesięcy zajęło godzinę, a nie tydzień.

Problem: agent zgaduje, co robi Twój formularz

Agent w przeglądarce widzi stronę przez drzewo dostępności: listę elementów z rolami i nazwami. Dla dobrze zbudowanego formularza to wystarcza, żeby odróżnić pole „Imię” od pola „Telefon”. Nie wystarcza, żeby wiedzieć, co ten formularz robi i jakie dane przyjmuje. Etykieta „Temat” nie mówi, czy wpisać tam „wycena strony www”, czy „pytanie o ofertę”. Przycisk „Wyślij” nie mówi, czy wiadomość trafi od razu do skrzynki firmy, czy tylko do kolejnego kroku. Pole „Data” nie mówi, czy oczekuje zapisu 05.09.2026, czy 2026-09-05.

Człowiek rozwiązuje te wątpliwości w sekundę, bo widzi kontekst całej strony i zna zwyczaje. Agent rozwiązuje je zgadywaniem, a każde zgadywanie kończy się jednym z trzech wyników: dobrym trafieniem, złymi danymi w Twojej skrzynce albo przerwaniem zadania. Google opisuje ten problem w dokumentacji WebMCP wprost: zamiast agenta zgadującego przeznaczenie elementów interfejsu, strona deklaruje, jakie działania udostępnia i jakich danych każde z nich wymaga.

Co to jest WebMCP i kto za tym stoi?

WebMCP to proponowany standard internetowy, w którym strona udostępnia agentom „narzędzia” (tools). Narzędzie to opisana czynność: ma nazwę, opis w ludzkim języku i listę parametrów z opisami. „Wyślij zapytanie o wycenę: imię, e-mail, telefon, opis potrzeby” jest narzędziem. „Dodaj produkt o numerze X w rozmiarze Y do koszyka” jest narzędziem. Agent czyta listę narzędzi, wybiera właściwe, podaje parametry i dostaje odpowiedź, bez klikania na ślepo.

Za propozycją stoi Google. Chrome udostępnił WebMCP w programie origin trial od wersji 149, ogłoszonym 9 czerwca 2026. Origin trial to ograniczony czasowo program, w którym właściciel strony rejestruje domenę, dostaje token i może testować eksperymentalną funkcję u prawdziwych użytkowników, a Google zbiera opinie przed domknięciem specyfikacji. Sama specyfikacja powstaje otwarcie w grupie Web Machine Learning Community Group przy W3C, w repozytorium webmachinelearning/webmcp na GitHubie, gdzie każdy może zgłosić uwagi. Do testów lokalnych, bez rejestracji, służy flaga chrome://flags/#enable-webmcp-testing.

Google dołożył też narzędzia dla programistów: panel DevTools pokazuje narzędzia zarejestrowane na stronie, pozwala je ręcznie wywołać i sprawdzić schemat danych, a rozszerzenie Model Context Tool Inspector testuje je z modelem Gemini. Dzięki temu programista widzi, jak agent „rozumie” formularz, zanim jakikolwiek agent na nim zadziała.

Dwa sposoby: atrybuty w HTML i JavaScript

Pierwszy sposób jest deklaratywny i nie wymaga ani linii JavaScriptu. Do istniejącego formularza dopisuje się trzy atrybuty: toolname (nazwa narzędzia), tooldescription (opis, co formularz robi) i toolparamdescription (opis każdego pola). Czwarty, toolautosubmit, pozwala agentowi wysłać formularz bez dodatkowego kliknięcia. Tak wygląda formularz kontaktowy po zmianie:

<!-- toolname: krótka nazwa zadania, bez spacji; tooldescription: co formularz robi, pełnym zdaniem -->
<form method="post" action="/wyslij-zapytanie"
      toolname="zapytanie_o_wycene"
      tooldescription="Wysyła zapytanie o wycenę usługi do agencji. Odpowiedź w ciągu jednego dnia roboczego.">

  <!-- każde pole ma name (dla agenta to nazwa parametru) i label (nazwa dostępna) -->
  <label for="imie">Imię i nazwisko</label>
  <input id="imie" name="imie" type="text" required
         toolparamdescription="Imię i nazwisko osoby kontaktowej">

  <label for="email">E-mail</label>
  <input id="email" name="email" type="email" required autocomplete="email"
         toolparamdescription="Adres e-mail, na który wyślemy wycenę">

  <label for="telefon">Telefon</label>
  <input id="telefon" name="telefon" type="tel" autocomplete="tel"
         toolparamdescription="Numer telefonu w formacie 9 cyfr bez spacji, pole nieobowiązkowe">

  <label for="usluga">Usługa</label>
  <select id="usluga" name="usluga"
          toolparamdescription="Usługa, której dotyczy wycena: google-ads, meta-ads, seo, strona-www">
    <option value="google-ads">Google Ads</option>
    <option value="meta-ads">Meta Ads</option>
    <option value="seo">SEO</option>
    <option value="strona-www">Strona www</option>
  </select>

  <label for="opis">Opis potrzeby</label>
  <textarea id="opis" name="opis"
            toolparamdescription="Kilka zdań o firmie, celu i budżecie miesięcznym"></textarea>

  <!-- toolautosubmit: agent może wysłać formularz od razu po wypełnieniu -->
  <button type="submit" toolautosubmit>Wyślij zapytanie</button>
</form>

Zwróć uwagę, że opisy pól podają to, czego etykieta nie mówi: format telefonu, dozwolone wartości listy, co ma zawierać opis. To dokładnie te informacje, przy których agent dziś zgaduje. Etykiety label zostają, bo z nich korzysta człowiek i czytnik ekranu, a atrybut name jest obowiązkowy, bo dla agenta to nazwa parametru.

Drugi sposób jest imperatywny: strona rejestruje narzędzie w JavaScripcie, ze schematem danych wejściowych i funkcją, która wykonuje zadanie. Ten sposób pasuje do czynności, które nie są zwykłym formularzem, na przykład do dodania produktu do koszyka w sklepie ładującym treść skryptami. Skrócony przykład:

// rejestracja narzędzia: nazwa, opis, schemat parametrów, funkcja wykonująca
navigator.modelContext.registerTool({
  name: 'dodaj_do_koszyka',
  description: 'Dodaje produkt w wybranym rozmiarze do koszyka.',
  inputSchema: {
    type: 'object',
    properties: {
      sku: { type: 'string', description: 'Numer katalogowy produktu' },
      rozmiar: { type: 'string', description: 'Rozmiar: S, M, L lub XL' },
      ilosc: { type: 'integer', description: 'Liczba sztuk, od 1 do 10' }
    },
    required: ['sku', 'rozmiar']
  }
}, async (params) => {
  return await dodajDoKoszyka(params.sku, params.rozmiar, params.ilosc || 1);
});

// kontekst dla agenta: dane, które pomagają dobrać parametry
navigator.modelContext.provideContext('dostepne_rozmiary', ['S', 'M', 'L', 'XL']);

W dokumentacji Lighthouse ten sam interfejs występuje też w zapisie document.modelContext, więc programista może spotkać obie formy; dokumentacja WebMCP w dziale AI w Chrome używa navigator.modelContext i ją traktujemy jako wzorzec. Obie drogi da się łączyć: formularz kontaktowy dostaje atrybuty, a koszyk rejestrację w skrypcie.

Co sprawdza Lighthouse?

Kategoria Przeglądanie agentowe w Lighthouse, dostępna od Chrome 150, zawiera trzy pozycje związane z WebMCP. Żadna z nich nie wchodzi do ułamka, który widzisz u góry raportu; mają wagę zero. Do wyniku liczą się tylko drzewo dostępności, stabilność układu i plik llms.txt, opisane w pierwszym wpisie serii.

• Zarejestrowane narzędzia WebMCP: kontrola informacyjna. Wypisuje narzędzia, które strona udostępnia agentom, z obu źródeł: atrybutów formularzy i rejestracji w skrypcie. Pusta lista nie jest błędem, tylko informacją, że strona niczego nie deklaruje.
• Formularze bez deklaratywnego WebMCP: kontrola informacyjna. Wskazuje formularze, którym brakuje pary toolname i tooldescription, czyli kandydatów do opisania.
• Poprawność schematu WebMCP: jedyna z trzech, która potrafi oblać. Oblewa, gdy formularz ma tooldescription bez toolname albo odwrotnie, oraz gdy wymagane pole nie ma atrybutu name. Ostrzega, gdy pole nie ma ani toolparamdescription, ani etykiety.

Dwie z tych kontroli pokazują wynik „nie dotyczy” na stronie bez WebMCP, a trzecia oblewa dopiero przy błędnym wdrożeniu. Z tego wynika prosta zasada: brak WebMCP nie psuje wyniku, ale WebMCP zrobione po łebkach już tak, choć na razie tylko w raporcie, nie w ułamku. Jeśli dopisujesz atrybuty, dopisuj je parami i pilnuj atrybutu name na każdym polu.

Bezpieczeństwo i zgoda użytkownika

Strona, która pozwala agentowi wysyłać formularze i dodawać produkty do koszyka, musi mieć pewność, kto te narzędzia wywołuje. Specyfikacja rozwiązuje to dwoma mechanizmami. Pierwszy to zasada uprawnień (Permissions Policy) o nazwie tools: domyślnie narzędzia może rejestrować tylko strona główna karty i osadzenia z tej samej domeny, a ramka z obcej domeny dostaje taką możliwość dopiero, gdy właściciel strony wpisze jej allow=”tools”. Reklama albo widget osadzony z zewnątrz nie zarejestruje więc narzędzia w Twoim imieniu.

Drugi to nagłówek Origin-Agent-Cluster, który izoluje stronę w osobnym procesie przeglądarki, żeby narzędzie działało w stabilnym, przypisanym do domeny środowisku przez cały czas swojej pracy. Oba mechanizmy ustawia programista albo administrator serwera, bez udziału edytora treści.

Po stronie użytkownika wdrożenie deklaratywne ma jedną cechę, która buduje zaufanie: agent wypełnia widoczne pola prawdziwego formularza na otwartej stronie, więc osoba, która wydała polecenie, widzi, co zostanie wysłane, zanim to się stanie. To samo, co przy zwykłym formularzu, tylko bez ręcznego wpisywania.

Agentic commerce: co to znaczy dla sklepu?

Google w dokumentacji WebMCP podaje cztery rodzaje scenariuszy: rezerwacje, w tym wieloetapowe, jak podróż przez kilka miast; koszyk i zamówienie; wyszukiwanie z filtrami; wypełnianie formularzy. Trzy z nich to codzienność sklepu internetowego. Klient, który mówi asystentowi „znajdź kurtkę przeciwdeszczową w rozmiarze M do 300 zł i dodaj do koszyka w sklepie, który wysyła jutro”, uruchamia po kolei wyszukiwanie z filtrami, wybór wariantu i koszyk. Bez WebMCP agent robi to, klikając w interfejs zaprojektowany dla ludzi, i na każdym kroku może się pomylić. Z WebMCP dostaje trzy narzędzia z jasnymi parametrami.

O tym, jak zmienia się sprzedaż, gdy zakupy robi agent, pisaliśmy w dwóch wcześniejszych tekstach: jak przygotować kampanie paid media na agentic commerce oraz zakupy przez AI: 5 zmian Google, które wpłyną na sklepy internetowe. WebMCP jest techniczną stroną tego samego zjawiska: kampania sprowadza agenta do sklepu, a narzędzia pozwalają mu kupić.

Dla sklepów na gotowych platformach, jak Shoper, IdoSell czy WooCommerce, tempo wdrożenia zależy od dostawcy platformy albo od motywu. Formularze kontaktu i zapytania o produkt da się opisać atrybutami już dziś, w motywie potomnym. Koszyk i wyszukiwarka wymagają rejestracji w skrypcie, więc tu czekamy na wsparcie platform albo piszemy skrypt na zamówienie.

Czy robić to już teraz?

Pełne wdrożenie dziś ma sens tylko wtedy, gdy zarejestrujesz domenę w origin trial i chcesz testować z prawdziwymi użytkownikami Chrome. Dla większości firm rozsądny jest podział na dwa etapy: przygotowanie gruntu teraz i dopisanie atrybutów, gdy Chrome wypuści WebMCP z testów.

Lewa kolumna to praca, która i tak podnosi wynik w kategorii Przeglądanie agentowe, bo pokrywa się z kontrolą drzewa dostępności. Prawa kolumna zajmuje przy przygotowanym gruncie około godziny na formularz, bo sprowadza się do wpisania atrybutów, których treść już masz w lewej kolumnie.

Grzegorz Wysocki
CEO emedia

Komentarz autora: WebMCP to jedyny z tematów tej serii, którego nie wdrażamy jeszcze u siebie, bo standard jest w testach i może się zmienić. Wdrażamy za to lewą kolumnę tabeli, czyli porządek w formularzach: name, etykieta, typ pola, zwykły przycisk wysyłki. Ta praca ma wartość bez względu na to, co stanie się z WebMCP, bo z tych samych rzeczy korzysta dziś agent czytający drzewo dostępności. Gdy Chrome domknie standard, dopisanie trzech atrybutów do naszego formularza kontaktowego zajmie godzinę i wtedy ten wpis dostanie aktualizację z naszym własnym przykładem.

Jak emedia może w tym pomóc?

Zaczynamy od przeglądu formularzy i czynności, które klient załatwia na stronie: kontakt, wycena, rezerwacja, zapytanie o produkt, koszyk. Dla każdej sprawdzamy lewą kolumnę tabeli i spisujemy braki z czasem naprawy. Porządek w formularzach robimy w ramach usług Web development, a w sklepach na WooCommerce i Shoperze przygotowujemy też spis przyszłych narzędzi, żeby rejestracja w skrypcie była gotowa do wdrożenia, gdy platforma je udostępni. Firmom, które chcą testować już w origin trial, pomagamy zarejestrować domenę i sprawdzić narzędzia w DevTools.

Podsumowanie

WebMCP pozwala stronie zadeklarować agentom AI, jakie zadania da się na niej wykonać i jakich danych każde wymaga, zamiast zostawiać agentowi zgadywanie po etykietach. Wdraża się go trzema atrybutami w HTML formularza albo rejestracją narzędzia w JavaScripcie przez navigator.modelContext. Chrome testuje standard w origin trial od wersji 149, ogłoszonym 9 czerwca 2026, a specyfikacja powstaje otwarcie przy W3C. Lighthouse pokazuje trzy kontrole WebMCP, ale żadna nie liczy się do wyniku, więc dziś opłaca się przygotować grunt: name i etykieta na każdym polu, poprawne typy, zwykły przycisk wysyłki i spis czynności, które za kilka miesięcy staną się listą narzędzi.

Przeczytaj także

• Jak pozycjonować firmę w AI, żeby ChatGPT i Gemini polecały ją klientom
• Jak przygotować stronę na agentów AI i dostać 3/3 w Lighthouse
• Jak poprawić dostępność strony w WordPressie, żeby agent AI znalazł każdy przycisk
• Jak zrobić plik llms.txt na stronie firmowej
• Jak poprawić Cumulative Layout Shift (CLS) w WordPressie, żeby strona przestała skakać
• Jak przygotować kampanie paid media na agentic commerce w 2026 roku?
• Zakupy przez AI: 5 zmian Google, które wpłyną na sklepy internetowe

Najczęstsze pytania

Jak to powstaje. Tematy, decyzje o zakresie wdrożenia i ostatnie słowo: Grzegorz Wysocki. Redakcja i porządkowanie źródeł: Claude (Anthropic). Diagram: rysunek własny, zrzut makiety HTML. Model obrazu nie brał udziału. Przykłady kodu napisane na potrzeby wpisu, nie pochodzą z wdrożenia na emedia.pl.

Na czym to stoi. Chrome for Developers, dokumentacja WebMCP w dziale AI w Chrome, stan na 4 września 2026; wpis „Join the WebMCP origin trial” na blogu Chrome for Developers, 9 czerwca 2026; dokumentacja kontroli WebMCP w kategorii Agentic Browsing w Lighthouse (zarejestrowane narzędzia, formularze bez deklaratywnego WebMCP, poprawność schematu), stan na 4 września 2026; repozytorium specyfikacji webmachinelearning/webmcp w grupie Web Machine Learning Community Group; InfoQ, czerwiec 2026, o udostępnieniu WebMCP w Chrome. Czego nie wiemy, o tym piszemy wprost: Google nie podał terminu zakończenia origin trial ani daty, od której WebMCP będzie dostępne bez rejestracji.

Realizacja: artykuł zrealizowany przez człowieka we współpracy z systemami AI. Redakcję i publikację firmuje autor.

Opublikowano 05.09.2026

Więcej na ten temat: agenci AI Lighthouse dostępność Widoczność w AI