Jak agent AI klienta może sam znaleźć produkt i dodać go do koszyka w Twoim sklepie?

Agent zakupowy klienta może wyszukać produkt w Twoim sklepie, sprawdzić, czy konkretny rozmiar i kolor są na stanie, policzyć koszt i termin dostawy, a potem dodać produkt do koszyka. Żeby to działało poprawnie, sklep musi wdrożyć WebMCP: opisać swoje narzędzia w sposób, który przeglądarka przekaże asystentowi AI. Płatność i finalne zatwierdzenie zamówienia zawsze zostawia się człowiekowi.

Buty w rozmiarze 43, dostawa na piątek: jak to wygląda od strony klienta

Klientka otwiera asystenta AI na telefonie i pisze: "Znajdź mi czarne buty do biegania w rozmiarze 43. Muszę je mieć przed weekendem, najlepiej w piątek." Zamyka telefon i zajmuje się czymś innym.

Asystent wchodzi do sklepu przez przeglądarkę. Zamiast klikać jak człowiek, sprawdza najpierw listę dostępnych narzędzi. Sklep ma wdrożone WebMCP, więc asystent widzi: narzędzie wyszukaj_produkty z parametrami: kategoria, kolor, rozmiar, zakres ceny. Wysyła zapytanie. Dostaje listę modeli. Dla każdego wywołuje sprawdz_wariant: czy rozmiar 43 jest w magazynie, ile sztuk zostało. Potem koszty_dostawy dla kodu pocztowego klientki: kurier standard dotrze w sobotę, ekspres w czwartek.

Asystent wybiera model z dostawą w czwartek, dodaje do koszyka przez dodaj_do_koszyka z wariantem: kolor czarny, rozmiar 43. Klientka dostaje powiadomienie: "Znalazłam buty X w rozmiarze 43, dostawa w czwartek. Zatwierdź, żeby przejść do płatności." Klika, płaci. Agent nie dotknął danych karty.

To nie jest wizja przyszłości. To scenariusz, który technicznie jest możliwy już teraz w sklepach z WebMCP, zanim Chrome wejdzie ze stabilną wersją pod koniec 2026 roku.

Sześć narzędzi, bez których agent się gubi w Twoim sklepie

WebMCP nie robi nic samo z siebie. Sklep musi opisać narzędzia, które asystent może wywołać. Bez tych opisów asystent próbuje odczytywać stronę jak tekst i błądzi przy każdym kroku.

Minimalne narzędzia dla agenta zakupowego:

• Wyszukiwarka z filtrami: kategoria, rozmiar, kolor, zakres ceny, dostępność w magazynie. Opis musi mówić, jakie wartości filtrów są możliwe, nie tylko że filtr istnieje. Asystent bez tej wiedzy wysyła losowe wartości i dostaje pusty wynik.
• Sprawdzenie wariantu: czy konkretny SKU (rozmiar 43, kolor czarny) jest na stanie, ile sztuk, kiedy wróci do magazynu, jeśli teraz go nie ma.
• Koszty i termin dostawy: dla kodu pocztowego kupującego, z rozróżnieniem na metody: paczkomat, kurier standard, kurier ekspres. Wynik powinien zawierać cenę i przewidywaną datę, nie tylko liczbę dni roboczych.
• Dodawanie do koszyka: ID produktu, wariant, ilość. Narzędzie zwraca potwierdzenie, że produkt trafił do koszyka zalogowanego użytkownika, z nowym stanem koszyka.
• Status zamówienia: dla zalogowanego klienta: numer zamówienia, etap realizacji, przewidywana dostawa, link do śledzenia przesyłki.
• Zwrot i reklamacja: zgłoszenie zwrotu do konkretnego zamówienia, wybór powodu, wygenerowanie etykiety zwrotnej lub podanie instrukcji.

Każde z tych narzędzi ma w WebMCP opis po ludzku: co robi, co przyjmuje za parametry, co zwraca. Asystent czyta te opisy przed pierwszym wywołaniem i planuje kolejność działań. To jest dokładnie ta sama idea, co MCP (Model Context Protocol), otwarty standard łączenia asystentów AI z programami, rozwijany pod opieką Linux Foundation. WebMCP przenosi tę ideę do przeglądarki.

Co traci sklep, gdy agent musi zgadywać po ekranie

Przez lata agenci zakupowi działali przez tak zwane scraping: wczytywali HTML strony, próbowali rozpoznać elementy, klikali. Klientom wyglądało to imponująco. W praktyce sypało się przy każdym wdrożeniu.

Konkretne miejsca, gdzie sklep bez WebMCP zawodzi agenta:

• Warianty produktu są niewidoczne w HTML. Ceny i dostępność rozmiarów wczytują się przez JavaScript po załadowaniu strony. Agent czyta surowy HTML, widzi jeden przycisk "Dodaj do koszyka" i klika, nie wiedząc, jaki wariant wybrał. Klientka dostaje buty w rozmiarze 41 i wraca z reklamacją.
• Filtry wyszukiwarki nie działają dla agenta. Sklep ma wyszukiwarkę z filtrem rozmiaru, ale jej wartości ładują się dynamicznie albo filtr to JavaScript bez semantycznych atrybutów. Agent wpisuje zapytanie w pole tekstowe i dostaje 200 wyników bez żadnego filtrowania.
• Ceny bez kontekstu. Agent widzi div.cena-produkt, ale nie wie, czy to cena brutto, netto, promocyjna czy przekreślona stara cena. Może podać klientce złą kwotę i stracić jej zaufanie.
• Termin dostawy to tekst, nie dane. "Dostawa w 2-3 dni robocze" nie mówi nic o konkretnej dacie. Agent nie potrafi odpowiedzieć na pytanie: "Czy dotrze przed weekendem?", bo nie ma kalendarza ani kalkulatora wbudowanego w tę informację.
• Koszyk wymaga precyzyjnej kolejności kroków. Wybierz wariant, kliknij "do koszyka", poczekaj na odpowiedź AJAX, sprawdź komunikat potwierdzenia. Agent pomija krok, dostaje błąd bez czytelnego komunikatu i próbuje od nowa lub odpuszcza.

Typowo wygląda to tak, że agent testowy trafia na stronę produktu, widzi przycisk, klika i... koszyk zostaje pusty, bo wariant nie był wybrany. Powtarza to kilka razy i ostatecznie informuje klienta, że "nie może sfinalizować zakupu w tym sklepie". Sprzedaż przepada, a właściciel sklepu nawet tego nie widzi w statystykach.

Jak zmierzyć, ile zakupów "przepada" przez brak WebMCP

W Google Analytics nie ma kolumny "agent AI nie ukończył zakupu". Ale da się to mierzyć, jeśli wiesz, gdzie patrzeć.

• Logi błędów agentów: jeśli sklep ma własny czat AI albo integrację z zewnętrznym asystentem, sprawdź, ile razy wywołanie wyszukiwarki albo koszyka zakończyło się błędem, pustą odpowiedzią lub przekroczeniem czasu.
• Sesje automatyczne bez konwersji: ruch z user-agentów oznaczonych jako zautomatyzowane, dużo wejść na strony produktów z konkretnym wariantem, zero dodań do koszyka. To ślad po agencie, który szuka i nie może sfinalizować.
• Po wdrożeniu WebMCP: każde narzędzie loguj osobno. Mierz stosunek wywołań wyszukaj_produkty do dodaj_do_koszyka. Duży gap między tymi liczbami oznacza, że agent szuka, ale odpada przy wyborze wariantu albo przy koszyku. Wiesz dokładnie, przy którym kroku tracisz transakcję.

Sklepy z własnym asystentem AI na stronie podłączają te zdarzenia do swojego systemu analytics jako custom events. Sklepy bez własnego asystenta też powinny te narzędzia logować, bo zewnętrzni asystenci klientów (w telefonach, w przeglądarkach) zaczną z nich korzystać od momentu, gdy Chrome wejdzie w stabilną wersję.

Jak to wygląda technicznie: co dostaje Twój programista

WebMCP działa na dwóch poziomach, które można wdrażać niezależnie.

Pierwszy to JavaScript: programista wywołuje navigator.modelContext.registerTool() z nazwą, opisem i funkcją obsługującą wywołanie. Asystent w przeglądarce widzi listę zarejestrowanych narzędzi i może je wywołać bezpośrednio, bez klikania po interfejsie. Opis wpisuje się po ludzku, np.: "Wyszukuje produkty w katalogu. Parametr: query (tekst), size (rozmiar buta, np. 43), color (kolor). Zwraca listę produktów z ID, nazwą, ceną brutto i dostępnością."

Drugi to atrybuty HTML na formularzach: toolname, tooldescription i toolparamdescription na polach input. To prostsza ścieżka dla formularzy, które już masz w sklepie. Nie przepisujesz logiki, tylko opisujesz, co formularz robi i co przyjmuje. Przeglądarka bez obsługi WebMCP ignoruje te atrybuty. Dla zwykłego kupującego strona działa identycznie jak przed wdrożeniem: żadnych wizualnych zmian, żadnych nowych ryzyk.

Jeśli interesuje Cię gotowe wdrożenie WebMCP w sklepie dla firmy, opisaliśmy tam dokładniej, jak łączymy opisy narzędzi z istniejącym systemem zamówień i co wymaga zmian po stronie backendu.

W Polsce praktycznie nikt nie oferuje jeszcze takich wdrożeń komercyjnie. To nie znaczy, że nie warto zacząć: sklepy, które opiszą swoje narzędzia przed pełnym wejściem WebMCP do Chrome, będą gotowe na agentów klientów od pierwszego dnia, zamiast gonić zaległości.

Gdzie asystent kończy swoją rolę: płatność zostaje przy człowieku

Celowo nie ma w tej liście narzędzia "zapłać". I nie chodzi o to, że technicznie nie dałoby się tego zrobić.

Płatność to moment, w którym pieniądze opuszczają konto. Klient powinien zobaczyć: co kupuje, za ile, z jaką dostawą, i potwierdzić to świadomie. Asystent przygotowuje koszyk do stanu "gotowy do płatności", przekazuje kontrolę człowiekowi i czeka. Podobnie z anulowaniem zamówienia po złożeniu albo zmianą adresu dostawy: technicznie możesz udostępnić te narzędzia agentowi, ale każde powinno wymagać wyraźnego potwierdzenia od użytkownika. Decyzja, co jest "odwracalne", a co nie, należy do właściciela sklepu.

To nie jest ograniczenie WebMCP jako technologii. To świadomy projekt: agent robi za Ciebie szukanie i porównywanie, ale ostatnie słowo zawsze masz Ty.

Lista kontrolna przed wdrożeniem

Zanim developer włączy WebMCP w sklepie, warto sprawdzić, czy te elementy są już gotowe:

• Wyszukiwarka zwraca wyniki przez API (nie tylko przez stronę HTML) z filtrowaniem po rozmiarze, kategorii i dostępności.
• Każdy wariant produktu ma unikalny identyfikator (SKU lub ID) dostępny w API.
• Dostępność wariantu jest sprawdzalna w czasie rzeczywistym, a nie tylko z cache odświeżanego raz na dobę.
• Koszty dostawy można pobrać programowo, podając kod pocztowy lub kraj i wagę produktu.
• Koszyk działa przez API: dodaj produkt, pobierz stan koszyka, usuń produkt.
• Dla zalogowanego użytkownika: stan zamówień dostępny przez API z numerem, etapem i linkiem do śledzenia.
• Wywołania narzędzi WebMCP trafiają do logów, żebyś mógł mierzyć użycie i błędy.
• Jest strona podsumowania koszyka, na którą asystent może skierować klienta po dodaniu produktu, zanim przejdzie do płatności.

W większości platform: WooCommerce, Shoper, Magento, Shopify, koszyk i wyszukiwarka mają API od dawna. Zazwyczaj nie trzeba go budować od zera, tylko opisać go dla AI w formacie, który WebMCP rozumie. Audyt tego, co już działa, a co wymaga nowego endpointu, to dobry pierwszy krok przed wyceną wdrożenia.

Od czego zaczynamy

Nie musisz wdrażać wszystkich sześciu narzędzi naraz. Pierwsza wersja, która już daje wartość, to dwa: wyszukiwarka z filtrami i sprawdzenie wariantu. Te dwa wystarczą, żeby asystent klienta mógł odpowiedzieć na pytanie "czy masz to w moim rozmiarze i kolorze" bez odsyłania go na stronę do samodzielnego klikania. Koszyk i dostawę dodajesz w drugim kroku. Zwroty i status zamówienia to trzeci etap, przy obsłudze posprzedażowej.

Chrome wchodzi z WebMCP do stabilnej wersji planowo pod koniec 2026 roku. Edge testuje równolegle. Safari nie zapowiedział wsparcia. Sklepy, które opiszą swoje narzędzia przed tym terminem, będą gotowe na agentów klientów od pierwszego dnia.

Jeśli chcesz wiedzieć, co konkretnie trzeba zrobić w Twoim sklepie i ile to zajmie, zarezerwuj 15 minut rozmowy o WebMCP w sklepie. Przejdziemy przez Twoją platformę i powiemy, co już masz i co trzeba dopisać. Możesz też zobaczyć, jak to wygląda w praktyce, w realnych wdrożeniach.