WordPress ma wreszcie oficjalną, kanoniczną wtyczkę do obsługi Model Context Protocol. MCP Adapter w wersji 0.70 trafił 7 października 2026 do katalogu wordpress.org, a zespół AI projektu opisał go jako jedyne rekomendowane rozwiązanie do podłączania asystentów AI pod funkcje witryny. Dla właścicieli stron to moment, w którym agentowy dostęp do CMS-a przestaje być eksperymentem z GitHuba i staje się czymś, co można zainstalować jednym kliknięciem z panelu administracyjnego.
Premiera ma jednak drugie dno. Analizy przeprowadzone przez niezależnych testerów pokazują, że domyślna konfiguracja transportu HTTP sprawdza wyłącznie uprawnienie read, czyli to, które posiada każde zalogowane konto, łącznie z rolą subskrybenta. To nie jest luka w klasycznym rozumieniu, tylko domyślne ustawienie, które wymaga świadomej zmiany przy wdrożeniu produkcyjnym.
Kontekst: od repozytorium na GitHubie do katalogu wtyczek
Model Context Protocol to otwarty standard opracowany przez Anthropic, który pozwala systemom AI łączyć się z aplikacjami, danymi, wtyczkami i narzędziami w jednolity sposób. Zamiast pisać osobną integrację dla każdego asystenta, deweloper opisuje raz, co jego oprogramowanie potrafi, a klienci MCP (Claude, Cursor, VS Code i kolejne) odczytują tę listę w ustandaryzowanym formacie.
WordPress pracował nad własną implementacją od wielu miesięcy. Wcześniejsze wersje MCP Adaptera były dostępne wyłącznie przez stronę z wydaniami na GitHubie i mimo tej bariery zebrały ponad 40 tysięcy instalacji. Równolegle rozwijały się konkurencyjne podejścia, w tym archiwalne już repozytoria Automattic/wordpress-mcp oraz WordPress/abilities-api, co tworzyło dokładnie ten rodzaj rozdrobnienia, którego ekosystem wtyczek zwykle nie znosi.
Wersja 0.70 kończy ten etap. Jest to pierwsze wydanie opublikowane w oficjalnym repozytorium wordpress.org, a Director of Engineering Jason Adams podsumował je w komunikacie zespołu jednym zdaniem: MCP Adapter został wydany i jest kanoniczną wtyczką MCP dla WordPressa. Słowo „kanoniczna” ma tu konkretne znaczenie organizacyjne. Oznacza, że projekt utrzymuje ją oficjalnie, a autorzy innych wtyczek powinni budować na niej zamiast dublować jej funkcje.
Kluczowe fakty
Poniższa tabela zbiera najważniejsze parametry wydania, które warto sprawdzić przed instalacją na produkcji.
| Parametr | Wartość |
|---|---|
| Wersja | 0.70 (0.7.0), wydana 2 października 2026 |
| Data publikacji w katalogu | 7 października 2026 |
| Wydawca | zespół AI projektu WordPress (Automattic) |
| Wymagany WordPress | 6.9, testowana do 7.1 |
| Wymagany PHP | 7.4 lub nowszy |
| Licencja | GPL-2.0-or-later |
| Instalacje przed listingiem | ponad 40 000 z GitHuba |
| Endpoint HTTP | /wp-json/mcp/mcp-adapter-default-server |
| Uwierzytelnianie HTTP | hasła aplikacji WordPress przez Basic auth |
| Obsługiwane wersje protokołu | 2025-11-25 oraz 2026-07-28 |
| Status dojrzałości | przed 1.0, możliwe zmiany łamiące API |
Jak to działa technicznie
Architektura opiera się na dwóch warstwach i to rozróżnienie jest kluczowe dla zrozumienia całej układanki. Abilities API decyduje, co w ogóle istnieje w danej witrynie: deweloper rejestruje funkcję przez wp_register_ability(), podając etykietę, schemat wejścia, callback wykonawczy oraz callback uprawnień. MCP Adapter siada na tym jako warstwa tłumacząca i decyduje, co agent AI ma prawo zobaczyć oraz wywołać.
Po świeżej instalacji wtyczka wystawia bardzo oszczędny zestaw. Są to trzy meta-narzędzia bramkowe (discover-abilities, get-ability-info, execute-ability) oraz trzy odczytowe funkcje rdzenia: core/get-site-info, core/get-user-info i core/get-environment-info. Wszystkie pozostałe zarejestrowane zdolności pozostają prywatne, dopóki ktoś świadomie nie ustawi im flagi meta.mcp.public = true. To rozsądny domyślny stan, który zapobiega przypadkowemu wystawieniu całego panelu administracyjnego na zewnątrz.
Dostępne są dwie drogi transportu. STDIO działa przez WP-CLI i uruchamia serwer jako podproces na maszynie dewelopera, bez żadnej powierzchni sieciowej. Wariant HTTP korzysta z REST API i wymaga HTTPS oraz struktury bezpośrednich odnośników innej niż zwykła. Po inicjalizacji każde żądanie musi nieść nagłówek Mcp-Session-Id, a sesja wygasa po 24 godzinach bezczynności. Strumieniowanie SSE nie zostało jeszcze zaimplementowane, więc żądanie GET zwraca kod 405.
Co to znaczy dla SEO i AIO
Na pierwszy rzut oka wtyczka integracyjna dla asystentów AI wygląda na temat czysto deweloperski. W praktyce dotyka trzech obszarów, które zespoły SEO śledzą od miesięcy.
Po pierwsze, automatyzacja pracy operacyjnej. Jeżeli witryna wystawia zdolności przez MCP, asystent może odczytać dane o treściach, taksonomiach i konfiguracji bez ręcznego eksportu oraz bez pisania dedykowanego skryptu. Ten sam wzorzec opisywaliśmy już przy podłączaniu Search Console do asystenta w tekście o MCP w praktyce SEO. Różnica polega na tym, że teraz drugi koniec rury, czyli sam CMS, dostaje oficjalną i wspieraną implementację.
Po drugie, agenci jako nowa klasa odwiedzających. MCP Adapter nie jest kanałem widoczności w wyszukiwarkach i nie wpływa bezpośrednio na pozycje. Jest kanałem wykonawczym: agent nie czyta renderowanego HTML-a, tylko wywołuje opisaną funkcję i dostaje ustrukturyzowaną odpowiedź. To odwrócenie logiki, którą znamy z klasycznego crawlowania. Pokrewny ruch po stronie przeglądarki opisywaliśmy przy okazji wejścia WebMCP do przeglądarki ChatGPT, gdzie strony również zaczynają pełnić rolę narzędzi, a nie dokumentów.
Po trzecie, powierzchnia ryzyka. Każda nowa końcówka REST-owa to nowy element do audytu technicznego. Zespoły, które utrzymują setki witryn klienckich, muszą dopisać ten endpoint do listy kontrolnej razem z robots.txt, nagłówkami i konfiguracją botów AI.
Czy to wpłynie na cytowalność w modelach
Bezpośrednio nie. MCP nie jest protokołem indeksowania i modele nie przeszukują sieci w poszukiwaniu serwerów MCP, żeby zebrać treść do odpowiedzi. Wystawienie zdolności nie sprawi, że marka pojawi się częściej w odpowiedziach ChatGPT czy Gemini. Pośrednio jednak kierunek jest czytelny: ekosystem przestawia się z modelu „model czyta stronę” na model „agent wykonuje operację”, a witryny przygotowane pod drugi scenariusz będą miały łatwiejszy start, gdy pojawią się publiczne katalogi serwerów MCP.
Domyślne uprawnienia: szczegół, który łatwo przeoczyć
Najważniejsza praktyczna uwaga z testów wdrożeniowych dotyczy transportu HTTP. Domyślne sprawdzenie uprawnień weryfikuje capability read. Posiada je każde zalogowane konto w WordPressie, w tym subskrybent, czyli rola, którą wiele witryn nadaje automatycznie przy rejestracji. Bez jawnego callbacka uprawnień dla transportu subskrybent może dotrzeć do serwera MCP.
Skala realnego ryzyka zależy od tego, co faktycznie zostało wystawione. Przy domyślnym zestawie trzech odczytowych funkcji rdzenia konsekwencje są ograniczone, bo mówimy o informacjach o witrynie, koncie i środowisku. Problem rośnie liniowo z każdą zdolnością oznaczoną jako publiczna, zwłaszcza jeśli dotyczy zapisu, usuwania lub ustawień.
Zalecane minimum przy wdrożeniu produkcyjnym sprowadza się do kilku kroków:
- podnieść domyślny próg uprawnień transportu filtrem
mcp_adapter_default_transport_permission_user_capability, na przykład domanage_options, albo przekazać własny callback uprawnień, - założyć dedykowane konto WordPress wyłącznie dla dostępu MCP i nadać mu najwęższą możliwą rolę,
- nigdy nie używać
__return_truejako callbacka uprawnień dla zdolności zapisujących, usuwających lub zmieniających ustawienia, - na serwerach osiągalnych po HTTP preferować zdolności tylko do odczytu,
- wymusić HTTPS, ponieważ hasła aplikacji podróżują zakodowane w Base64, a nie zaszyfrowane,
- rotować hasła aplikacji przy każdej zmianie w składzie zespołu.
Jest jeszcze jeden niuans, który w praktyce bywa groźniejszy niż samo domyślne ustawienie. Jeśli callback uprawnień zwróci WP_Error lub rzuci wyjątek, żądanie zostaje odrzucone i zapisane jako nieudane. Jeśli natomiast zwróci true błędnie, dostęp jest przyznawany po cichu i nie trafia do żadnego logu. Wtyczka nie ma wbudowanego logowania, a obserwowalność wymaga własnej implementacji interfejsu McpObservabilityHandlerInterface. Innymi słowy, zbyt luźna konfiguracja nie zostawia śladu, po którym dałoby się ją wykryć poniewczasie.
Temat uprawnień administracyjnych nadawanych przez wtyczki nie jest w ekosystemie nowy. Podobna dyskusja toczyła się latem przy sprawie, w której Rank Math został oskarżony o ciche tworzenie hasła administratora. Wnioski z tamtej historii są aktualne: domyślne ustawienia wtyczek są czytane przez bardzo niewielu administratorów, a skutki skalują się przez całą flotę witryn.
Jak sprawdzić, czy witryna wystawia serwer MCP
Audyt jest prosty i warto wpisać go do standardowej listy kontrolnej, nawet jeśli nikt w zespole świadomie wtyczki nie instalował. Wystarczy sprawdzić, czy końcówka /wp-json/mcp/mcp-adapter-default-server odpowiada inaczej niż kodem 404. Odpowiedź 401 lub 403 oznacza, że serwer istnieje i wymaga uwierzytelnienia, co jest stanem oczekiwanym. Odpowiedź 405 na żądanie GET to normalne zachowanie wynikające z braku obsługi strumieniowania SSE i również potwierdza obecność serwera.
Druga rzecz do zweryfikowania to lista faktycznie wystawionych zdolności. Po uwierzytelnieniu i inicjalizacji sesji narzędzie discover-abilities zwraca komplet tego, co agent widzi. Jeśli na liście pojawia się cokolwiek poza trzema bramkowymi meta-narzędziami i trzema odczytowymi funkcjami rdzenia, ktoś w projekcie świadomie oznaczył dodatkowe zdolności jako publiczne i warto przejrzeć ich callbacki uprawnień jeden po drugim. Przy audycie witryn klienckich zbieranie tej listy do arkusza zajmuje kilka minut na stronę, a daje jednoznaczną odpowiedź na pytanie o realną powierzchnię ekspozycji.
Trzeci element to inwentaryzacja haseł aplikacji. Ponieważ transport HTTP korzysta właśnie z nich, każde aktywne hasło aplikacji przypisane do konta z wysokimi uprawnieniami jest potencjalnym kluczem do serwera MCP. Lista haseł aplikacji znajduje się w profilu każdego użytkownika, a konta nieaktywne od miesięcy to pierwsza pozycja do wyczyszczenia.
Czego ta wtyczka nie zmienia
Warto też jasno wskazać granice, bo wokół premiery narosło sporo nadinterpretacji. MCP Adapter nie przyspiesza indeksowania i nie wpływa na budżet crawlowania. Nie zastępuje pliku llms.txt ani ustawień w robots.txt dla botów AI, bo adresuje zupełnie inny scenariusz: uwierzytelniony agent wykonujący operację zamiast anonimowego crawlera czytającego dokument. Nie jest też kanałem dystrybucji treści i nie ma wpływu na to, czy model wybierze daną domenę jako źródło cytowania. Zespoły, które dziś pracują nad widocznością w odpowiedziach AI, nie powinny przestawiać priorytetów z powodu tej premiery, lecz potraktować ją jako sygnał o kierunku, w którym idzie cała warstwa integracyjna.
Reakcje branży
Odbiór premiery jest wyraźnie pozytywny, choć z zastrzeżeniami. Komentatorzy branżowi najczęściej podkreślają kwestię zgodności wstecznej. Jak ujął to jeden z deweloperów cytowanych w dyskusji po ogłoszeniu, kompatybilność wsteczna ma tu znaczenie, bo wtyczki WordPressa zwykle zostają w witrynach na lata. Protokół MCP zmienia się szybko, a CMS, który obsługuje około 40 procent sieci, nie może sobie pozwolić na rytm wydawniczy typowy dla startupów AI. Wersja 0.7.0 dodała wsparcie dla bezstanowej specyfikacji 2026-07-28, zachowując równolegle obsługę schematu 2025-11-25.
Druga oś dyskusji to dojrzałość. Numer wersji poniżej 1.0 nie jest ozdobnikiem. Wydania 0.3.0, 0.5.0 i 0.7.0 wprowadzały zmiany łamiące API, wersja 0.6.0 trafiła do użytkowników z wadliwym archiwum (poprawione tego samego dnia w 0.6.1), a 0.7.0 zaczęła odrzucać nieprawidłowe pola protokołu i wymaga od własnych transportów delegowania do rdzeniowych handlerów. Listing w katalogu wordpress.org dokłada do tego nowy czynnik: wtyczka przed 1.0 może się teraz automatycznie aktualizować na całej flocie witryn, jeśli administrator ma włączone automatyczne aktualizacje.
Trzeci wątek dotyczy braku warstwy środowiskowej. MCP Adapter nie oferuje stagingu, migawek ani możliwości cofnięcia zmian. Jeśli agent wykona błędną operację zapisu, efekt jest trwały. To główny argument, którym dostawcy hostowanych serwerów MCP uzasadniają swoje rozwiązania przy obsłudze wielu witryn klienckich.
Co dalej
Krótkoterminowo warto obserwować trzy rzeczy. Pierwsza to tempo dojścia do wersji 1.0, bo dopiero ona da zespołom podstawę do wdrożeń produkcyjnych bez obaw o zmiany łamiące API przy każdym wydaniu pomocniczym. Druga to implementacja SSE, której brak wyklucza część klientów MCP wymagających strumieniowania. Trzecia to adopcja Abilities API przez autorów popularnych wtyczek SEO, formularzy i e-commerce, bo bez zarejestrowanych zdolności sam adapter pozostaje pustą rurą.
Dłuższa perspektywa jest ciekawsza. Jeśli Abilities API rzeczywiście stanie się standardowym sposobem opisywania funkcji wtyczki, WordPress zyska coś, czego nie miał nigdy wcześniej: maszynowo czytelny katalog tego, co dana witryna potrafi zrobić. To fundament pod scenariusze, w których agent nie tylko czyta treść, lecz także składa zamówienie, aktualizuje cennik albo publikuje poprawkę. Dla zespołów SEO oznacza to, że audyt techniczny za rok może obejmować nie tylko pytanie, co bot widzi na stronie, lecz także pytanie, co agent może na niej wykonać.
Praktyczna rekomendacja na teraz jest umiarkowana. Na witrynach testowych i deweloperskich warto zainstalować wtyczkę i poznać model uprawnień, bo kierunek jest przesądzony. Na produkcji, zwłaszcza w sklepach i serwisach z danymi klientów, rozsądniej poczekać na 1.0, a jeśli wdrożenie jest konieczne wcześniej, zacząć od transportu STDIO oraz zdolności wyłącznie odczytowych i dopiero potem rozważać wystawienie czegokolwiek po HTTP.
FAQ
Czy MCP Adapter poprawi pozycje mojej strony w Google?
Nie. MCP Adapter to protokół wykonawczy dla asystentów AI, a nie kanał indeksowania. Nie wpływa na crawlowanie, renderowanie ani ranking w wyszukiwarce. Jego rola dotyczy automatyzacji i integracji z narzędziami agentowymi, a nie widoczności organicznej.
Czy po instalacji wtyczki moja witryna jest od razu otwarta dla AI?
Nie w pełni. Domyślnie wystawione są trzy meta-narzędzia bramkowe oraz trzy odczytowe funkcje rdzenia dotyczące informacji o witrynie, użytkowniku i środowisku. Pozostałe zdolności pozostają prywatne, dopóki ktoś nie ustawi im flagi publicznej. Trzeba jednak pamiętać, że domyślne uprawnienie transportu HTTP to read, które posiada każde zalogowane konto.
Jaka jest różnica między Abilities API a MCP Adapterem?
Abilities API to warstwa rejestracji: określa, jakie funkcje w ogóle istnieją w witrynie i jakie mają schematy wejścia oraz callbacki uprawnień. MCP Adapter to warstwa tłumacząca, która zamienia zarejestrowane zdolności na narzędzia, zasoby i prompty zrozumiałe dla klientów MCP, oraz decyduje, co agent może zobaczyć i wywołać.
Czy wtyczka nadaje się na produkcję?
Z zastrzeżeniami. Numer wersji poniżej 1.0 oznacza możliwe zmiany łamiące API między wydaniami pomocniczymi, co już zdarzało się w wersjach 0.3.0, 0.5.0 i 0.7.0. Brakuje też wbudowanego logowania oraz jakiejkolwiek warstwy stagingu, więc błędna operacja agenta jest nieodwracalna. Na krytycznych witrynach bezpieczniej zacząć od transportu STDIO i zdolności tylko do odczytu.
Jak zabezpieczyć dostęp HTTP do serwera MCP?
Najważniejsze kroki to podniesienie domyślnego progu uprawnień transportu filtrem mcp_adapter_default_transport_permission_user_capability lub własnym callbackiem, utworzenie dedykowanego konta o najwęższej roli, wymuszenie HTTPS (hasła aplikacji są jedynie kodowane w Base64), unikanie __return_true przy zdolnościach zapisujących oraz rotacja haseł aplikacji przy zmianach w zespole.