Wyobraź sobie klienta, który chce kupić buty do biegania. Nie otwiera sklepu, nie wybiera kategorii, nie ustawia filtrów i nie porównuje sześciu kart produktów. Zamiast tego mówi agentowi AI:
Znajdź męskie buty do biegania po asfalcie, w rozmiarze 43, do 500 zł. Sprawdź dostawę przed piątkiem i przygotuj koszyk.
Agent może dziś próbować wykonać takie zadanie. Otworzy stronę, przeanalizuje jej wygląd albo kod, rozpozna pola formularza i zacznie klikać. Czasem mu się uda. Czasem pomyli filtr ceny z rozmiarem, nie zauważy komunikatu o braku towaru albo zatrzyma się na niestandardowym selektorze wariantu.
WebMCP ma ograniczyć to zgadywanie. To proponowany standard przeglądarkowy, dzięki któremu strona może jawnie poinformować agenta: „potrafię wyszukać produkty”, „potrafię sprawdzić dostępność”, „potrafię dodać wariant do koszyka”. Każde takie działanie ma nazwę, opis, wymagane parametry i przewidywalny wynik.
Brzmi jak techniczny detal. Dla właściciela sklepu jest to jednak sygnał większej zmiany. Po latach projektowania stron dla ludzi, urządzeń mobilnych, wyszukiwarek i czytników ekranu pojawia się kolejny odbiorca: oprogramowanie działające w imieniu klienta.
Czym właściwie jest WebMCP?
WebMCP rozwija pomysł znany z narzędzi udostępnianych modelom AI. Zamiast pozwalać agentowi interpretować każdy element strony, serwis opisuje dostępne działania w formacie zrozumiałym dla maszyny.
W sklepie mogłyby to być na przykład:
- wyszukiwanie produktów według określonych cech,
- sprawdzanie ceny i dostępności wariantu,
- pobieranie warunków dostawy,
- porównywanie produktów,
- dodawanie towaru do koszyka,
- przygotowanie zgłoszenia do obsługi klienta.
Nie oznacza to, że znika tradycyjny interfejs. Klient nadal może przeglądać kategorie, czytać opisy, oglądać zdjęcia i korzystać z filtrów. WebMCP ma działać jako dodatkowa warstwa. Ta sama funkcja pozostaje dostępna dla człowieka, a agent otrzymuje jednoznaczny sposób jej wywołania.
W dokumentacji Chrome opisano dwa sposoby tworzenia takich narzędzi. Pierwszy wykorzystuje JavaScript i nadaje się do funkcji zależnych od stanu aplikacji. Drugi pozwala opisać istniejący formularz za pomocą atrybutów HTML. Przeglądarka może wtedy potraktować formularz jak narzędzie, wypełnić jego pola i pokazać użytkownikowi, co agent zamierza zrobić.
To ostatnie jest ważne: WebMCP nie zostało zaprojektowane wyłącznie jako niewidzialny automat. Oficjalne materiały Chrome podkreślają działanie na otwartej stronie i udział człowieka, zwłaszcza przy operacjach wrażliwych.
Dlaczego obecna automatyzacja stron jest zawodna?
Dzisiejszy agent przeglądarkowy często przypomina bardzo szybkiego, ale niedoświadczonego użytkownika. Widzi stronę, próbuje zrozumieć jej układ i wykonuje kolejne czynności. Może korzystać z obrazu, struktury DOM, nazw elementów, a czasem ze współrzędnych na ekranie.
Ten model ma kilka słabych punktów.
Po pierwsze, układ strony się zmienia. Zespół marketingowy wdraża nowy baner, narzędzie do testów A/B przenosi przycisk, a aplikacja ładuje inną wersję formularza na telefonie. Człowiek zwykle sobie z tym poradzi. Automat oparty na selektorach lub wcześniej rozpoznanej sekwencji może się zgubić.
Po drugie, znaczenie elementu nie zawsze wynika z jego wyglądu. Dwa podobne przyciski mogą wykonywać inne działania. Cena widoczna na karcie produktu może dotyczyć najtańszego wariantu, a nie wariantu wybranego przez klienta. Zielona etykieta może oznaczać „dostępny”, „nowość” albo „wysyłka jutro”.
Po trzecie, każdy dodatkowy krok zwiększa ryzyko błędu. Jeśli agent musi otworzyć kategorię, ustawić pięć filtrów, przejść do produktu, wybrać rozmiar i sprawdzić koszyk, niepowodzenie na dowolnym etapie może przerwać cały proces.
Jawne narzędzie skraca tę ścieżkę. Agent nie musi odkrywać znaczenia filtrów na podstawie ich położenia. Otrzymuje opis parametrów, na przykład typ nawierzchni, rozmiar, maksymalną cenę i termin dostawy. Sklep nadal wykonuje własną walidację i zwraca wynik.
Nie należy przy tym zakładać, że WebMCP usunie wszystkie problemy. Jeśli dane produktowe są niespójne, stany magazynowe aktualizują się z opóźnieniem albo różne części sklepu inaczej interpretują dostępność, agent otrzyma ten sam bałagan w bardziej uporządkowanym opakowaniu. Standard komunikacji nie naprawi procesu biznesowego.
WebMCP, MCP i API: trzy różne elementy układanki
Nazwa WebMCP łatwo prowadzi do nieporozumienia. Model Context Protocol, czyli MCP, służy do łączenia agentów z zewnętrznymi danymi, narzędziami i procesami. Serwer MCP może działać niezależnie od tego, czy użytkownik ma otwartą stronę sklepu.
WebMCP działa inaczej. Jego narzędzia są związane z aktualną stroną i kartą przeglądarki. Mogą korzystać z bieżącej sesji, widocznego interfejsu oraz stanu aplikacji. Gdy użytkownik zamknie kartę albo opuści serwis, narzędzia przestają być dostępne.
Najprostsze rozróżnienie wygląda tak:
- API udostępnia funkcje systemu innym systemom;
- MCP pozwala agentowi korzystać z usług i danych niezależnie od otwartej strony;
- WebMCP pomaga agentowi działać w kontekście strony, którą użytkownik właśnie odwiedza.
W dojrzałym rozwiązaniu te warstwy mogą się uzupełniać. Backend nadal odpowiada za reguły cenowe, dostępność, autoryzację, płatności i zapis zamówienia. MCP może udostępniać trwałe procesy agentom działającym w różnych środowiskach. WebMCP daje przeglądarce i agentowi dostęp do funkcji aktualnie otwartego sklepu.
Dla biznesu płynie z tego praktyczny wniosek: wdrożenie WebMCP nie powinno polegać na przenoszeniu logiki biznesowej do przeglądarki. Narzędzie na stronie jest wejściem do procesu, a nie miejscem, w którym należy omijać reguły backendu.
Co WebMCP może zmienić w e-commerce?
Najbardziej widowiskowa wizja brzmi: agent sam znajduje produkt i finalizuje zakup. To dobry materiał na demonstrację, ale niekoniecznie najlepszy pierwszy przypadek wdrożeniowy.
W handlu internetowym istnieje wiele mniej ryzykownych zadań, które klient chętnie delegowałby agentowi.
Wyszukiwanie z uwzględnieniem prawdziwej potrzeby
Klasyczna wyszukiwarka sklepu oczekuje frazy. Klient myśli natomiast w kategoriach sytuacji: „potrzebuję lekkiej kurtki na deszczowy city break” albo „szukam monitora do pracy z dokumentami, który zmieści się na biurku o szerokości 110 cm”.
Agent może przełożyć taki opis na parametry. WebMCP może dać mu kontrolowany sposób przekazania tych parametrów do mechanizmu sklepu. Nadal to sklep decyduje, które produkty spełniają warunki i jakie dane zwrócić.
Porównywanie wariantów i kompatybilności
W wielu branżach samo znalezienie produktu jest łatwe. Trudniejsze jest sprawdzenie, czy dany wariant pasuje do posiadanego urządzenia, mebla, samochodu lub sposobu użytkowania.
Dobrze zaprojektowane narzędzie mogłoby zwracać nie tylko listę wyników, ale również powód dopasowania, ograniczenia i brakujące informacje. Agent wiedziałby wtedy, kiedy powinien dopytać klienta, zamiast udawać pewność.
Dostępność i termin dostawy
Informacja „produkt dostępny” bywa zbyt ogólna. Klient chce wiedzieć, czy konkretny rozmiar lub kolor dotrze pod wskazany kod pocztowy przed określoną datą.
To dobry przypadek dla narzędzia odczytowego. Ma konkretny zestaw parametrów, daje mierzalny wynik i nie wywołuje operacji finansowej.
Przygotowanie koszyka
Agent może znaleźć produkty, wybrać warianty i przygotować koszyk, ale pozostawić użytkownikowi sprawdzenie ceny, dostawy oraz finalne zatwierdzenie. Takie rozdzielenie oszczędza czas bez odbierania klientowi kontroli.
Obsługa posprzedażowa
Status zamówienia, warunki zwrotu, przygotowanie zgłoszenia czy wybór odpowiedniej kategorii reklamacji są procesami opartymi na formularzach. Agent może pomóc klientowi zebrać dane i wypełnić pola, a sklep zachowuje dotychczasowe reguły obsługi.
Gdzie kończy się wygoda, a zaczyna ryzyko?
Nie wszystkie narzędzia powinny mieć taki sam poziom autonomii. Sprawdzenie stanu zamówienia to inna klasa działania niż anulowanie subskrypcji, a przygotowanie koszyka różni się od obciążenia karty.
Przydatny podział obejmuje cztery poziomy:
- Odczyt informacji. Agent sprawdza cenę, dostępność, status lub warunki dostawy. Wymagana jest kontrola dostępu do danych klienta, ale samo działanie nie zmienia stanu systemu.
- Działania łatwe do cofnięcia. Dodanie produktu do koszyka, ustawienie filtra albo zapis wersji roboczej. Użytkownik powinien zobaczyć efekt i móc go anulować.
- Operacje finansowe lub prawne. Zakup, zwrot środków, zmiana płatnego planu, zawarcie umowy. Tu potrzebne jest jawne potwierdzenie.
- Operacje nieodwracalne. Usunięcie konta albo danych. Samo polecenie w rozmowie z agentem nie powinno wystarczyć.
Zasada jest prosta: im poważniejszy skutek, tym wyraźniejsza obecność człowieka. Projektowanie dla agentów nie może oznaczać projektowania poza wiedzą użytkownika.
Bezpieczeństwo nie jest dodatkiem do WebMCP
Strona może korzystać z wielu skryptów: własnych, analitycznych, reklamowych, personalizacyjnych i dostarczanych przez zewnętrzne moduły. Jeśli każdy z nich mógłby bez kontroli rejestrować narzędzia dla agenta, powstałaby nowa powierzchnia ataku.
Oficjalna dokumentacja WebMCP opisuje między innymi izolację originu i Permissions Policy. Narzędzia w osadzonych ramkach z innych domen mają podlegać dodatkowym ograniczeniom. To dobry fundament, ale właściciel serwisu nadal musi odpowiedzieć na bardziej przyziemne pytania:
- kto w organizacji zatwierdza nowe narzędzie,
- jakie dane agent może odczytać,
- czy wywołanie jest zapisywane w logach,
- jak rozpoznać działanie człowieka, a jak agenta,
- które operacje wymagają ponownego uwierzytelnienia,
- co się stanie, gdy agent powtórzy tę samą operację,
- jak wycofać błędne działanie,
- jak długo przechowywać dane związane z wykonaniem zadania.
Szczególnie ważna jest idempotencja. To techniczne określenie prostej zasady: ponowienie tej samej prośby nie powinno prowadzić do podwójnej płatności, dwóch rezerwacji albo wysłania pięciu identycznych zgłoszeń. Agenty mogą ponawiać wywołania po błędzie lub braku odpowiedzi. System musi być na to przygotowany.
Dochodzi też RODO. Agent działający w imieniu użytkownika może przekazywać dane osobowe pomiędzy rozmową a stroną. Firma musi wiedzieć, jakie dane otrzymuje, na jakiej podstawie je przetwarza i czy nie trafiają do narzędzia szerszego niż wymaga cel.
Co to oznacza dla marketingu, SEO i analityki?
Jeśli część użytkowników przestanie samodzielnie przechodzić przez kolejne ekrany, zmieni się sposób mierzenia ścieżki klienta.
Dzisiaj marketer analizuje odsłony list produktów, użycie filtrów, wejścia na kartę, dodanie do koszyka i finalizację zamówienia. Agent może skrócić te kroki do jednego wywołania narzędzia i prezentacji wyniku w swoim interfejsie. Tradycyjny lejek będzie wtedy niepełny.
Warto już teraz myśleć o zdarzeniach takich jak:
- wykrycie dostępnego narzędzia przez klienta agentowego,
- wywołanie narzędzia i jego cel,
- sukces, błąd lub przerwanie procesu,
- prośba o potwierdzenie użytkownika,
- przejście z rekomendacji agenta do koszyka,
- finalna transakcja oraz sposób jej atrybucji.
Nie wiadomo jeszcze, jaki model raportowania stanie się rynkowym standardem. Jeśli jednak agent wybiera produkt bez wyświetlenia klasycznej listy wyników, samo mierzenie odsłon i kliknięć nie wystarczy.
Podobne pytanie dotyczy SEO i GEO. Widoczność marki w odpowiedzi generowanej przez AI to dopiero pierwszy etap. Następny może dotyczyć wykonania zadania. Agent wybierze dostawcę, którego dane są wiarygodne, warunki zrozumiałe, a działanie możliwe do przeprowadzenia bez ryzyka.
Można nazwać to optymalizacją doświadczenia agenta, ale nie warto na siłę tworzyć kolejnego akronimu. Sens jest praktyczny: firma powinna być nie tylko łatwa do znalezienia. Powinna być również łatwa do zweryfikowania i bezpieczna we współpracy z oprogramowaniem reprezentującym klienta.
Czy WebMCP zwiększy konwersję?
To możliwe, ale dziś nie ma podstaw do podawania konkretnej obietnicy. Krótsza ścieżka może ograniczyć porzucenia. Agent może też lepiej dopasować produkt do warunków podanych przez klienta.
Są jednak scenariusze odwrotne. Jeśli agent łatwo porównuje wielu sprzedawców, presja cenowa może wzrosnąć. Marka straci część okazji do prezentacji treści, rekomendacji i argumentów sprzedażowych. Źle opisane narzędzie może prowadzić do gorszych rekomendacji niż tradycyjny interfejs.
Na konwersję wpłyną więc nie tylko techniczne możliwości WebMCP, ale jakość całego procesu:
- kompletność danych produktowych,
- aktualność dostępności i cen,
- jasne warunki dostawy oraz zwrotów,
- zrozumiałe reguły wariantów,
- sprawna walidacja po stronie sklepu,
- zaufanie klienta do agenta i sprzedawcy.
Dopiero testy na prawdziwych zadaniach pokażą, czy dana implementacja oszczędza czas i zwiększa skuteczność.
Czego nie należy robić?
Pierwszym błędem byłoby potraktowanie WebMCP jako kolejnego modułu do zainstalowania bez przeglądu procesów. Jeśli mechanizm cenowy, magazyn i regulamin zwrotów podają różne odpowiedzi, agent szybko ujawni te sprzeczności.
Drugim błędem jest rozpoczęcie od płatności lub anulowania zamówienia. Najpierw warto nauczyć się projektować narzędzia na operacjach odczytowych, gdzie koszt pomyłki jest niższy.
Trzeci błąd to oddanie logiki bezpieczeństwa frontendowi. Agent nie może uzyskać większych uprawnień niż użytkownik, którego reprezentuje. Każda operacja musi przejść normalną autoryzację i walidację backendową.
Czwarty to wiara, że jeden standard automatycznie zapewni obecność marki w każdym agencie i każdej przeglądarce. WebMCP jest propozycją, jego interfejs się zmienia, a implementacje przeglądarek nie muszą rozwijać się w tym samym tempie.
W artykule „WebMCP: The Future of AI-Native Websites” (Autor: Vijayasekhar Deepak) znalazły się przykłady używające navigator.webMCP i atrybutu webmcp-tool. Aktualna dokumentacja Chrome pokazuje inne interfejsy, między innymi document.modelContext oraz atrybuty formularzy toolname i tooldescription. To dobry przykład tempa zmian: materiały koncepcyjne mogą się zdezaktualizować niemal natychmiast.
Plan dla firmy: pięć kroków bez niepotrzebnego pośpiechu
Firma nie musi czekać na finalną wersję standardu, aby przygotować fundamenty. Większość potrzebnych prac przyniesie korzyści również tradycyjnemu sklepowi.
1. Uporządkuj procesy i dane
Zacznij od listy najważniejszych zadań klienta. Sprawdź, skąd sklep pobiera cenę, dostępność, warianty, koszt dostawy i status zamówienia. Zidentyfikuj miejsca, w których dwa systemy udzielają różnych odpowiedzi.
2. Wybierz jeden przypadek o niskim ryzyku
Dobry pilot powinien mieć jasne wejście i łatwy do sprawdzenia wynik. Przykłady to dostępność wariantu, termin dostawy, status zamówienia albo wyszukanie produktów według kilku cech.
3. Zaprojektuj kontrakt narzędzia
Ustal nazwę działania, jego cel, parametry, wymagane pola, format wyniku i komunikaty błędów. Opis powinien być czytelny zarówno dla modelu, jak i dla zespołu biznesowego.
4. Dodaj zabezpieczenia i pomiar
Określ uprawnienia, potwierdzenia, logowanie, obsługę ponowień oraz zasady przetwarzania danych. Zdefiniuj miary pilota: skuteczność wykonania zadania, liczbę błędów, czas realizacji i momenty, w których potrzebna była pomoc człowieka.
5. Uruchom kontrolowany test
Porównaj trzy ścieżki: człowieka korzystającego z interfejsu, agenta korzystającego z narzędzia oraz użytkownika, którego przeglądarka nie obsługuje WebMCP. Funkcja podstawowa musi nadal działać bez warstwy agentowej.
Czy trzeba działać już teraz?
Nie ma powodu, aby przebudowywać sklep wyłącznie pod WebMCP. Standard pozostaje w aktywnym rozwoju, a jego obecny kształt może się zmienić. Nie wiadomo też, jak szybko i w jakiej formie przyjmą go inne przeglądarki oraz platformy agentowe.
Jest natomiast dobry powód, aby potraktować WebMCP jako test gotowości organizacji. Czy kluczowe funkcje sklepu mają jasne kontrakty? Czy dane produktowe są spójne? Czy operacje można bezpiecznie ponawiać? Czy firma odróżnia podgląd od decyzji finansowej? Czy analityka poradzi sobie ze ścieżką, w której część pracy wykonuje agent?
Jeśli odpowiedzi są niejasne, problem nie zaczyna się od WebMCP. Standard jedynie go uwidacznia.
Podsumowanie
WebMCP opisuje internet, w którym strona nie jest wyłącznie zbiorem ekranów do oglądania. Staje się również katalogiem jasno nazwanych możliwości. Agent może dowiedzieć się, co serwis potrafi, jakie dane są potrzebne i jaki wynik powinien otrzymać.
Dla e-commerce nie oznacza to końca interfejsów, SEO ani tradycyjnej ścieżki zakupowej. Oznacza dodatkowy kanał obsługi klienta. Kanał, w którym użytkownika reprezentuje oprogramowanie.
Najbardziej rozsądny pierwszy krok nie prowadzi do autonomicznego zakupu. Prowadzi do uporządkowania danych, wybrania bezpiecznego zadania i sprawdzenia, czy agent potrafi wykonać je lepiej niż automat klikający po ekranie.
Pytanie dla właściciela sklepu nie brzmi więc: „czy mam już wdrożyć WebMCP?”. Lepsze pytanie brzmi:
Które zadania klienta potrafimy opisać na tyle jasno, aby bezpiecznie przekazać je agentowi?
Najczęściej zadawane pytania
-
Czy WebMCP jest już powszechnym standardem?
Nie. Jest proponowanym standardem przeglądarkowym rozwijanym i testowanym między innymi w ekosystemie Chrome. API pozostaje przedmiotem dyskusji i zmian.
-
Czy WebMCP zastąpi API sklepu?
Nie. API i backend nadal odpowiadają za dane, reguły biznesowe, autoryzację i zapis operacji. WebMCP udostępnia agentowi kontrolowany sposób działania w kontekście otwartej strony.
-
Czy agent będzie mógł kupować bez zgody użytkownika?
Techniczna możliwość wykonania narzędzia nie powinna oznaczać braku kontroli. Operacje finansowe, prawne i nieodwracalne powinny wymagać jawnego potwierdzenia oraz normalnej autoryzacji.
-
Czy WebMCP zastąpi SEO lub GEO?
Nie. Widoczność i wykonanie działania to dwa różne etapy. WebMCP może poszerzyć rolę serwisu w świecie agentów, ale nie zastępuje jakości treści, danych produktowych ani rozpoznawalności marki.
-
Od jakiego zastosowania zacząć w sklepie internetowym?
Od zadania odczytowego o niskim ryzyku: sprawdzenia dostępności wariantu, terminu dostawy, statusu zamówienia albo wyszukania produktów według jasno określonych cech.
Źródła
- Vijayasekhar Deepak, WebMCP: The Future of AI-Native Websites, 6 sierpnia 2026.
- Chrome for Developers, WebMCP, dokumentacja opublikowana 18 maja 2026 i zaktualizowana 7 sierpnia 2026.
- Chrome for Developers, WebMCP Imperative API.
- Chrome for Developers, WebMCP Declarative API.
- Chrome for Developers, When to use WebMCP and MCP.
