Kto: Mariusz Szatkowski, programista WordPressa od 2006 roku, autor serwera MCP działającego na tej stronie i otwartoźródłowego serwera MCP dla WooCommerce. Pracuję sam, więc kod integracji piszę osobiście i nikomu nie przekazuję dostępów.
Co: serwery Model Context Protocol z wąskimi narzędziami, autoryzacja zgodna ze specyfikacją MCP, mosty do WordPressa, WooCommerce, Shopify i treści z headless CMS, logi wywołań i testy przed wdrożeniem.
Gdzie: zdalnie z Gdyni. Ustalenia prowadzę mailowo, w dokumentach i w repozytorium. Przed dostępem do danych osobowych podpisuję umowę powierzenia przetwarzania zgodnie z art. 28 RODO.
Ile: wyceniam każdą integrację osobno, według liczby systemów i narzędzi oraz tego, czy któreś zapisuje dane. Ofertę dostajesz na piśmie, z założeniami.
Integracja MCP z AI dla sklepów i serwisów na WordPressie
Model Context Protocol daje asystentowi AI listę konkretnych narzędzi zamiast hasła administratora wklejonego do czatu. Podłączam te narzędzia do systemów, które już masz, i tak je ograniczam, żeby asystent widział tylko to, na co się zgodzisz.
Jak wygląda sama usługa krok po kroku, opisuję na stronie tworzenie serwera MCP. Tutaj piszę o decyzjach architektonicznych i o tym, gdzie integracja może zaszkodzić.
Asystent w obsłudze klienta oszczędza czas, ale każdy skrót grozi wyciekiem danych osobowych albo odpowiedzią sprzeczną ze stanem magazynu. Dlatego zaczynam od mapy danych: historię zamówień często da się pokazać modelowi jako kategorie produktów, status i przedział wartości, bez nazwiska, adresu i telefonu. Pola potrzebne tylko do wysyłki zostają w sklepie.
Co MCP robi technicznie
MCP to protokół oparty na JSON-RPC 2.0. Aplikacja z modelem (host, na przykład Claude albo ChatGPT) łączy się przez klienta z serwerem, który udostępnia trzy rodzaje rzeczy: narzędzia, które model wywołuje, zasoby z danymi i szablony promptów. Aktualna wersja specyfikacji nosi datę 28 lipca 2026 i definiuje dwa standardowe transporty: stdio dla serwera uruchamianego lokalnie jako proces oraz Streamable HTTP dla serwera zdalnego, gdzie każda wiadomość to osobne żądanie POST na jeden endpoint.
Specyfikacja mówi też wprost, że narzędzie to wykonywanie dowolnego kodu, więc człowiek powinien mieć możliwość odrzucenia każdego wywołania, a opisy narzędzi z niezaufanych serwerów należy traktować jako niezaufane. Źródło: specyfikacja MCP.
Jak wybieram procesy do pilotażu
Prosisz o asystenta, więc zaczynam od pytania, do czego konkretnie. Przyślij listę zadań: podgląd statusu zamówienia, zasady zwrotów, wyszukiwanie w dokumentacji technicznej. Każde zadanie dostaje jeden z trzech poziomów: narzędzie działa samo, narzędzie wymaga potwierdzenia przez człowieka albo zadanie zostaje poza asystentem.
Przy okazji spisuję identyfikatory produktów, waluty na rynkach i wyjątki podatkowe. Bez tej mapy model uśrednia odpowiedzi i myli ceny. Przypadki brzegowe biorę z prawdziwych zgłoszeń z Twojego systemu obsługi klienta: zwrot części zamówienia, zamówienie podzielone na dwie paczki, reklamacja po terminie.
Jeśli chodzi raczej o automatyzację procesów niż o czat, zajrzyj na stronę o wdrożeniach AI w firmach.
Jak projektuję bezpieczny serwer MCP
Narzędzia
Każde narzędzie ma nazwę, opis i schemat wejścia w JSON Schema, a gdy zwraca dane strukturalne, także schemat wyjścia. Wolę deterministyczne operacje w rodzaju “pobierz podsumowanie zamówienia po ID” niż ogólne “napraw zamówienie”. Naprawy zostają w panelu administratora.
Błędy rozróżniam tak, jak przewiduje specyfikacja: błąd protokołu przy nieznanym narzędziu albo złym żądaniu, a błąd wykonania z isError: true przy złej dacie, braku rekordu czy braku uprawnień. Model dostaje wtedy informację, którą może poprawić, zamiast zgadywać.
Ta sama zasada działa na tej stronie: serwer pod https://wppoland.com/mcp udostępnia narzędzia tylko do odczytu, między innymi check_services i request_quote, bez klucza API. Opis architektury jest w przewodniku po publicznym serwerze MCP WPPoland. Wersję dla sklepu utrzymuję jako serwer MCP dla WooCommerce na GitHubie: tylko do odczytu, z narzędziami takimi jak get_product, list_orders i sales_report.
Autoryzacja i tokeny
Dla serwerów po HTTP specyfikacja opiera autoryzację na OAuth 2.1. Chroniony serwer MCP jest serwerem zasobów: publikuje metadane zgodnie z RFC 9728, przyjmuje tylko tokeny wydane dla siebie i nie przekazuje ich dalej. Klient wskazuje serwer parametrem resource z RFC 8707. Serwer lokalny po stdio bierze poświadczenia ze zmiennych środowiskowych. Źródło: autoryzacja w specyfikacji MCP.
Zakresy (scopes) ustawiam tak, żeby jedno narzędzie dało się wyłączyć przy incydencie bez gaszenia całego asystenta. Tam, gdzie WordPress albo WooCommerce mają już swoje uprawnienia, odwzorowuję je zamiast budować równoległą listę dostępu, która z czasem się rozjedzie.
Jakie dane wracają do modelu
Odpowiedź narzędzia nie zawiera zbędnych danych osobowych, ma znacznik czasu źródła oraz walutę i język, żeby model nie mieszał rynków. Treści z headless CMS oznaczam osobno od liczb ze sklepu. Przy stronie wielojęzycznej narzędzie zwraca kod języka, żeby asystent nie cytował polskiego opisu klientowi z Wielkiej Brytanii.
Limity ruchu w szczytach sprzedaży
Specyfikacja wymaga, żeby serwer walidował wejście, kontrolował dostęp, limitował wywołania i oczyszczał wyniki. Limit ma tu praktyczny sens: asystent potrafi wysłać zapytania szybciej niż ludzie, a API sklepu obsługuje też prawdziwych kupujących. Ustawiam osobne limity dla narzędzi od zamówień i od treści marketingowych, więc kampania mailowa nie zablokuje obsługi zwrotów. Dane, które mogą być lekko nieaktualne, idą z pamięci podręcznej.
Przed startem odtwarzam na stagingu test obciążenia, żeby sprawdzić ponawianie z opóźnieniem. Jeśli narzędzie czeka na synchroniczny webhook do ERP, loguję czas oczekiwania, bo inaczej asystent podaje stan zamówienia, którego ERP jeszcze nie zna.
MCP w WordPressie i WooCommerce
WordPress 6.9 wprowadził Abilities API. Funkcją wp_register_ability() rejestruje się operację z opisem, schematem wejścia i wyjścia oraz permission_callback, a WordPress udostępnia ją w REST API pod wp-abilities/v1 (ogłoszenie na make.wordpress.org). Pakiet MCP Adapter z inicjatywy AI Building Blocks zamienia te abilities na narzędzia, zasoby i prompty MCP. Łączy się z nim przez WP-CLI po stdio albo po HTTP. Ability jest dla MCP prywatna, dopóki nie oznaczy się jej jako publicznej, a domyślne sprawdzenie dostępu serwera to tylko is_user_logged_in(), więc uprawnienia dopisuję sam dla każdej operacji.
Gdy zastanawiasz się, czy wystarczy WordPress.com Agent z zapisem przez MCP, czy potrzebny jest własny adapter na Twoim serwerze, to porównanie pomoże wybrać przed startem.
Kilka rzeczy, których pilnuję w praktyce:
- Narzędzie, które ma widzieć aktualny stan magazynu, omija cache strony i pyta endpoint z krótkim czasem życia danych.
- W sklepie z HPOS zamówienia leżą we własnych tabelach WooCommerce, więc raporty korzystają z API zamówień, nie z zapytań do postmeta.
- W multisite narzędzie przyjmuje jawne ID strony, żeby model nie mieszał katalogów różnych marek.
- Dostęp po HTTP opieram na hasłach aplikacji WordPressa albo OAuth, z rotacją zapisaną w dokumentacji.
MCP z Shopify i sklepami na kilku platformach
W Shopify obowiązują limity platformy: Admin API w GraphQL liczy koszt zapytania, a po przekroczeniu limitu zwraca błąd i każe odczekać (limity Shopify). Narzędzie mówi wtedy asystentowi, że odpowiedź się opóźni, zamiast zmyślać dane. Kraj lub rynek przyjmuje jako jawny argument, żeby cena w czacie zgadzała się z kasą. W sklepie B2B z kontami firmowymi osobne zakresy Admin API dostają osobne narzędzia, więc pytanie klienta detalicznego nie odsłania cennika hurtowego.
W konfiguracji mieszanej zapisuję regułę pierwszeństwa: stany i ceny z platformy sklepu, opisy z CMS. Ta reguła siedzi w kodzie serwera.
Jak opublikować serwer MCP w ChatGPT i Claude
Aktualizacja, . Oba asystenty mają publiczne katalogi serwerów MCP, więc serwer zbudowany dla działu obsługi klienta sklepu można też udostępnić jego klientom.
Katalog wtyczek ChatGPT
OpenAI prowadzi jeden katalog wtyczek wspólny dla ChatGPT i Codex. Według changelogu Apps SDK od 22 lutego 2026 ChatGPT jest w pełni zgodny ze specyfikacją MCP Apps. Przed publikacją:
- zgłoszenie składa zweryfikowana osoba albo organizacja,
- wtyczka potrzebuje opublikowanej polityki prywatności i kontaktu do wsparcia,
- paczkę ZIP najpierw sprawdzają automaty, potem recenzent, a po akceptacji sam decydujesz, kiedy ją udostępnić,
- handel obejmuje na razie tylko towary fizyczne, z płatnością na Twojej domenie (Instant Checkout mają tylko wybrani partnerzy),
- dostępność możesz zawęzić listą krajów w polu
publication.countries, - po publikacji OpenAI codziennie skanuje hostowany serwer MCP.
Źródła: wytyczne, proces zgłoszenia.
Katalog konektorów Claude
- zgłoszenie przez claude.ai/directory/manage jako konektor MCP; może je złożyć każdy z płatnym planem Claude,
- serwer zdalny po HTTPS; serwer lokalny tylko w ramach wtyczki,
- OAuth 2.0 dla narzędzi działających na koncie użytkownika, bez uwierzytelniania dla danych publicznych,
- tytuł i adnotacja
readOnlyHintalbodestructiveHintprzy każdym narzędziu, - adres dokumentacji, adres polityki prywatności, kontakt do wsparcia, ikona i w pełni wypełnione konto testowe dla recenzenta,
- po zgłoszeniu automatyczna kontrola zasad i domyślnie oznaczenie Community; serwer z adresami przypisanymi do konkretnych klientów wymaga oznaczenia Verified.
Wpisy jako rozszerzenia desktopowe (MCPB) są wycofane. Źródło: dokumentacja Anthropic.
Co przygotowuję przed zgłoszeniem
Narzędzie oznaczone readOnlyHint naprawdę nie zmienia danych, co odpowiada podziałowi na odczyt i zapis opisanemu wyżej. Polityka prywatności mówi, co serwer przekazuje dostawcy modelu, i spełnia obowiązki informacyjne z art. 13 RODO. Konto testowe dla recenzenta działa na danych przykładowych, nigdy na prawdziwych zamówieniach. Sklep, który chce trafić do ChatGPT bez własnej wtyczki, zaczyna od feedu produktów i danych strukturalnych, o czym piszę na stronie o gotowości sklepu na zakupy przez AI.
Jak testuję integrację MCP
Mam zestaw stałych pytań z oczekiwanymi odpowiedziami i puszczam go po każdej zmianie narzędzi oraz po każdej zmianie modelu u dostawcy. Do zestawu należą też próby prompt injection i scenariusze, w których endpoint modelu albo sklepu zwraca błędy. Patrzę na trafność faktów, czas odpowiedzi narzędzi i to, jak często rozmowę musi przejąć człowiek.
Jeśli liczba tokenów rośnie szybciej niż jakość odpowiedzi, upraszczam narzędzia albo skracam kontekst. Gdy model kilka razy z rzędu próbuje obejść zasady narzędzia, sprawdzam, skąd się to bierze.
Dokumenty, które zostają po wdrożeniu
| Dokument | Po co | Kto przygotowuje |
|---|---|---|
| Opis narzędzi MCP | Akceptacja zakresu przez Twój dział prawny lub bezpieczeństwa | Ja |
| Umowa powierzenia przetwarzania | Art. 28 RODO, w tym informacja o dostawcy modelu | Ty i ja |
| Instrukcja wyłączania narzędzi | Szybkie odcięcie asystenta bez wyłączania sklepu | Ja |
| Wyniki testów | Ślad zmian w trafności odpowiedzi | Ja, w repozytorium |
Wszystko leży w Twoim repozytorium razem z kodem, więc osoba, która przejmie utrzymanie, nie musi pytać mnie o hasła ani o zrzuty ekranu.
Odpowiedzi MCP a dane strukturalne
Jeśli strona produktu używa w schema.org sku, gtin13 albo priceSpecification, narzędzie MCP zwraca te same identyfikatory i kwoty. Rozbieżność między danymi na stronie a odpowiedzią czatu to klient, który widzi dwie różne ceny. Przy nowej stronie lub zmianie oferty aktualizuję oba miejsca w tym samym wdrożeniu.
Jak zacząć
Przyślij mi listę API, z których ma korzystać asystent, opis zadań i to, czego asystent robić nie może. Odpowiem na piśmie planem z narzędziami, testami na stagingu i podziałem odpowiedzialności, zanim jakikolwiek token produkcyjny zostanie włączony. Pilotaż najlepiej zacząć od wąskiej grupy Twoich pracowników, a dopiero potem pokazać asystenta klientom.
