WebMCP w sklepie na Shoperze, WooCommerce i PrestaShopie: co da się wdrożyć na każdej platformie?

Na Shoperze i IdoSell możesz wdrożyć WebMCP przez skrypt JavaScript w nagłówku szablonu, ale logika koszyka i checkoutu jest zarządzana przez platformę i nie wchodzi w skład edytowalnych plików. WooCommerce, PrestaShop i Magento dają pełny dostęp do kodu, więc tam można opisać każdy krok zakupu, każde pole formularza i każdą akcję. Na każdej z tych platform przeglądarka bez WebMCP po prostu pomija dodane atrybuty: sklep działa tak samo jak przed wdrożeniem, nic się nie psuje.

O co w tym właściwie chodzi, zanim przejdziemy do platform

Scenka, którą widzimy coraz częściej: klient rozmawia z asystentem AI na telefonie albo w przeglądarce i mówi: "Kup mi trzy kartony wody gazowanej, tej co brałem ostatnio." Asystent trafia na stronę sklepu i musi wiedzieć, co robi przycisk "Dodaj do koszyka", gdzie wpisać ilość, co oznacza "Kontynuuj zakupy" i jak wygląda formularz adresowy. Bez opisu strony asystent działa w ciemno: widzi HTML, ale nie rozumie, co który element robi w kontekście zakupu.

Do tego służy WebMCP. To projekt specyfikacji w grupie W3C Community Group, który przygotowują razem Google i Microsoft. Nie jest jeszcze standardem. Chrome testuje go w ramach origin trial, stabilna wersja planowana jest pod koniec 2026 roku, Edge też go testuje. Safari nie zapowiedziało wsparcia. Wdrożenie robi się przez trzy rzeczy: skrypt JavaScript inicjujący navigator.modelContext, atrybut toolname na elementach HTML, atrybut tooldescription opisujący, co dany element robi, i opcjonalnie toolparamdescription przy polach formularzy. WebMCP korzysta z MCP, czyli Model Context Protocol: otwartego standardu łączenia asystentów AI z programami, rozwijanego pod opieką Linux Foundation.

Przeglądarka bez WebMCP nie wie, że te atrybuty są, i po prostu je pomija. Sklep wygląda i działa tak samo dla każdego, kto nie ma asystenta AI. Dlatego wdrożenie można robić etapami, bez ryzyka.

Shoper i IdoSell: gdzie masz ręce związane

Shoper i IdoSell to platformy SaaS. Serwer, aktualizacje i rdzeń sklepu należą do platformy: Ty zarządzasz sklepem przez panel, a do kodu masz dostęp ograniczony do szablonu frontendowego.

Co możesz zrobić bez problemu:

• Skrypt JavaScript w sekcji head szablonu: obie platformy pozwalają wkleić własny kod do nagłówka każdej strony. Tu inicjujesz navigator.modelContext i opisujesz ogólny kontekst: branżę sklepu, dostępne kategorie, język, sposób kontaktu.
• Edycja plików szablonu: karta produktu, lista kategorii, strona wyników wyszukiwania. Atrybuty toolname i tooldescription możesz dodawać do przycisków, linków i formularzy widocznych w tych plikach.
• Formularz "Zapytaj o produkt" i wyszukiwarka: to najłatwiejszy start. Formularz kontaktowy i pole wyszukiwarki są zazwyczaj częścią szablonu, więc można je opisać od ręki.
• Strona konta klienta i historia zamówień: jeśli te widoki wchodzą w skład edytowalnego szablonu, możesz je opisać.

Gdzie się zatrzymujesz:

• Koszyk i checkout: na Shoperze i IdoSell proces zakupu, wybór płatności i dostawa to kod zarządzany przez platformę. Pliki checkoutu nie wchodzą w skład edytowalnego szablonu.
• Logika cenowa i stany magazynowe: asystent AI może je odczytać, jeśli są widoczne w HTML strony produktu, ale wpływanie na nie przez WebMCP jest poza zasięgiem szablonu.
• Custom akcje przy koszyku: dodanie własnego pola, zmiana kolejności kroków, obsługa kodu rabatowego w checkoucie. To wymaga oficjalnego API platformy albo bezpośredniej rozmowy z supportem Shopera lub IdoSell.

U jednego klienta na Shoperze wdrożenie szło sprawnie do momentu, gdy chcieliśmy opisać przycisk "Zamawiam i płacę" w checkoucie. Plik z tym elementem okazał się generowany przez rdzeń platformy, poza edytowalnym szablonem. Ostatecznie opisaliśmy wejście do koszyka, przycisk "Przejdź do kasy" na stronie koszyka i wszystkie formularze szablonu. Sam przycisk finalnego zamówienia zostawiliśmy bez opisu, co i tak jest dobrą praktyką: asystent nie powinien składać zamówień bez potwierdzenia klienta.

WooCommerce: pełny dostęp, pełna odpowiedzialność

WooCommerce działa na WordPressie na własnym serwerze. Masz pełną kontrolę nad bazą danych i każdym plikiem PHP w szablonie. To daje zupełnie inną swobodę przy WebMCP.

Możliwości:

• Każdy plik szablonu do edycji: karta produktu, kategoria, wyniki wyszukiwania, koszyk, checkout, potwierdzenie zamówienia. Atrybuty WebMCP możesz wstawić wszędzie.
• Wtyczka WordPressa z własną logiką: wdrożenie WebMCP można zamknąć w osobnej wtyczce. Wtyczka dodaje atrybuty do wybranych elementów WooCommerce przez system filtrów i akcji WordPressa. Przy aktualizacji szablonu atrybuty zostają, bo są w osobnym kodzie.
• Opis koszyka i checkoutu w detalach: pole "Ulica i numer", "Kod pocztowy", "Wybór dostawy", "Kod rabatowy". Przy polu checkoutu atrybut toolparamdescription może powiedzieć asystentowi AI dokładnie, jakiego formatu oczekujesz: "podaj ulicę, numer domu i numer lokalu, format: Ulica 12/3".
• Integracja z REST API WooCommerce: to kolejny, bardziej zaawansowany krok. Możesz połączyć opisy WebMCP z faktycznym serwerem MCP, który korzysta z API WooCommerce do sprawdzania stanów i przyjmowania zamówień. To jednak osobna warstwa, niezależna od samego WebMCP w szablonie.

Wdrożenie na WooCommerce trwa krócej niż na SaaS, bo programista ma dostęp do wszystkiego. Ryzyko leży gdzie indziej: duże sklepy z dziesiątkami wtyczek i niestandardowych szablonów wymagają mapowania, żeby atrybuty WebMCP nie kolidowały z istniejącym kodem JavaScript. Warto zacząć od jednej sekcji, sprawdzić, i dopiero rozszerzać.

PrestaShop i Magento: własny serwer, własne reguły

PrestaShop to open source instalowany na własnym serwerze. Struktura motywów jest dobrze udokumentowana, a system modułów pozwala rozszerzać sklep bez dotykania rdzenia. Sytuacja przy WebMCP jest zbliżona do WooCommerce.

• Pliki szablonu (TPL): karta produktu, listing kategorii, koszyk, checkout. Każdy z nich edytujesz bezpośrednio. Atrybuty WebMCP dodajesz do konkretnych elementów w tych plikach.
• Moduł PrestaShop: wdrożenie WebMCP można zbudować jako moduł, który przez hooki PrestaShopa wstrzykuje atrybuty do wybranych elementów. Moduł nie zmienia rdzenia, więc aktualizacja platformy go nie nadpisze.
• Pola checkoutu: formularz adresowy, wybór przewoźnika, pole na kod rabatowy. W PrestaShopie mają standardową strukturę w plikach szablonu, więc opisy można dodać raz i działają przez cały sklep.

Magento (Adobe Commerce) to platforma self-hosted z pełnym dostępem do kodu. Szablony działają przez system layoutów XML, co jest bardziej rozbudowane technicznie, ale zasada ta sama: masz dostęp do każdego elementu i możesz go opisać. Wdrożenie na Magento wymaga programisty z doświadczeniem w tej platformie, bo sama struktura szablonów jest bardziej złożona.

Jeśli chcesz zobaczyć, jak wdrożenie WebMCP w sklepie wygląda od strony technicznej dla każdej z tych platform, na tej stronie zebraliśmy szczegóły i możliwe zakresy prac.

Koszyk i checkout: największa różnica między SaaS a własnym serwerem

To jest miejsce, gdzie różnice platform najbardziej uderzają.

Asystent AI klienta, który pomaga w zakupach, musi wiedzieć: jak trafić do koszyka, jak zmienić ilość produktu, gdzie wpisać kod rabatowy, jak wybrać opcję dostawy i co oznacza komunikat o błędzie przy adresie. To są konkretne elementy interfejsu, które trzeba opisać, żeby asystent działał pewnie, a nie zgadywał.

Na platformach SaaS (Shoper, IdoSell) przynajmniej część tych kroków jest w kodzie poza zasięgiem edytowalnego szablonu. Możesz opisać wejście do koszyka i kontekst strony, ale szczegółowych atrybutów toolparamdescription przy polach checkoutu często nie wstawisz bez wsparcia platformy.

Na WooCommerce i PrestaShopie możesz opisać każde pole. Atrybut przy polu "Imię i nazwisko" może powiedzieć asystentowi: "wpisz imię i nazwisko odbiorcy zamówienia". Proste zdanie, ale zmniejsza liczbę błędów przy automatycznym uzupełnianiu i sprawia, że asystent wie, czego dokładnie oczekuje formularz.

Ważna granica, niezależna od platformy: WebMCP samo w sobie nie składa zamówień autonomicznie. Opisujesz, co asystent AI może zrobić. To, czy asystent wykona akcję, zależy od tego, jak jest zbudowany po stronie klienta. Dobra praktyka jest taka: asystent sugeruje i pokazuje, co zrobi, klient potwierdza, zamówienie idzie.

Co opiszesz na każdej platformie bez dużego nakładu pracy

Bez względu na to, czy masz Shopera, WooCommerce czy PrestaShopa, te elementy możesz opisać stosunkowo łatwo:

• wyszukiwarka produktów: pole zapytania, co robi, na jakich danych szuka
• przyciski "Dodaj do koszyka" na karcie produktu
• filtry na listingu: kategoria, zakres cenowy, producent, dostępność
• formularz "Zapytaj o produkt" lub "Sprawdź dostępność"
• nawigacja główna i linki do kategorii
• strona konta klienta z historią zamówień i możliwością ponownego zamówienia

Koszyk i checkout to drugi etap. Na WooCommerce i PrestaShopie można go opisać w pełni. Na Shoperze i IdoSell: w zakresie, do którego daje dostęp edytor szablonu, z ewentualnym wsparciem supportu platformy w przypadku elementów rdzenia.

Lista kontrolna przed wdrożeniem: co sprawdzić na swojej platformie

Zanim programista zabierze się do pracy, warto odpowiedzieć na kilka pytań:

• SaaS czy własny serwer? Shoper, IdoSell i podobne to SaaS. WooCommerce, PrestaShop, Magento to własny serwer. Ta odpowiedź wyznacza zakres od razu.
• Dostęp do szablonu: czy masz dostęp do kodu szablonu przez panel lub FTP/SSH? Na SaaS sprawdź, które pliki udostępnia edytor szablonu.
• Czy możesz dodać własny skrypt do sekcji head? Na Shoperze i IdoSell to zwykle panel ustawień szablonu lub dedykowane pole w konfiguracji sklepu.
• Czy pliki koszyka i checkoutu wchodzą w skład edytowalnego szablonu? Na SaaS zapytaj supportu platformy, podając konkretne nazwy plików lub kroków procesu zakupu.
• Jaki jest formularz kontaktowy i gdzie jest w szablonie? To najłatwiejszy punkt startowy na każdej platformie.
• Czy wyszukiwarka jest własna platformy, czy zewnętrzna? Zewnętrzna wyszukiwarka (np. oparta na Elasticsearch lub usłudze SaaS) ma oddzielną strukturę HTML i może wymagać osobnego podejścia.
• Skąd pochodzi szablon? Gotowy szablon od dostawcy platformy a własny, pisany od zera, różni się strukturą. Własny szablon to zazwyczaj mniej ryzyka przy edycji.

Na Shoperze i IdoSell poproś support o listę plików szablonu, które możesz edytować, i zapytaj wprost, czy pliki checkoutu są w tej liście. Na WooCommerce i PrestaShopie wystarczy dostęp do serwera i dokumentacja szablonów danej platformy.

Od czego zaczynamy w praktyce

Typowo zaczynamy od audytu szablonu. Sprawdzamy, które elementy sklepu są opisane w edytowalnych plikach, a które generuje rdzeń platformy. Na tej podstawie powstaje mapa: co opiszemy od razu, co wymaga dodatkowego kroku, a co zostaje poza zasięgiem w aktualnej konfiguracji.

Potem priorytetyzujemy. Wyszukiwarka i karta produktu to absolutne minimum, bo tam asystent AI trafia najczęściej. Koszyk i checkout to drugi krok. Formularze zapytań o produkt i strona konta to trzeci.

Na WooCommerce i PrestaShopie cały pierwszy etap zajmuje zazwyczaj kilka dni programistycznych. Na Shoperze ten sam zakres może potrwać dłużej, jeśli checkout wymaga kontaktu z supportem platformy albo obejść przez dostępne API.

Chrome ma WebMCP w origin trial, stabilna wersja planowana jest na koniec 2026 roku. Edge też testuje. Safari nie zapowiedziało wsparcia. Wdrożenie dziś oznacza, że kiedy Chrome wyjdzie z wersją stabilną, Twój sklep jest gotowy. Sklep bez wdrożenia będzie wyglądał dla asystenta AI jak strona bez opisu: asystent będzie zgadywał, co który element robi. Różnica jest zauważalna w jakości odpowiedzi asystenta klienta.

Masz sklep na jednej z tych platform i chcesz wiedzieć, co konkretnie możesz opisać przed wdrożeniem? 15 minut rozmowy o WebMCP w sklepie wystarczy, żeby ocenić możliwości na Twojej platformie i ustalić zakres. Możesz też zobaczyć, jak WebMCP wygląda u firm, które wdrożyły to już u siebie: realne wdrożenia.