WordPress ma wreszcie jedną, oficjalną drogę podłączania agentów AI do witryny. Wtyczka MCP Adapter w wersji 0.7.0 trafiła do katalogu na WordPress.org, a jej autorem w karcie wtyczki jest po prostu WordPress.org, co w praktyce oznacza status wtyczki kanonicznej. Karta pokazuje już ponad 40 tysięcy aktywnych instalacji, choć wtyczka dopiero zadebiutowała w repozytorium: wcześniej przez ponad rok żyła wyłącznie na GitHubie i w Composerze.
Dla osób pracujących na WordPressie w SEO i w AIO to zmiana porządkująca bałagan, który narastał od wiosny. Zamiast kilku konkurencyjnych implementacji Model Context Protocol, każda z własnym modelem uprawnień, pojawia się jeden serwer protokołu utrzymywany w organizacji WordPress.
Co dokładnie trafiło do repozytorium
MCP Adapter nie jest wtyczką, która sama dodaje funkcje AI. To warstwa serwera i transportu: most między Abilities API WordPressa i specyfikacją Model Context Protocol. Wtyczka wystawia endpointy MCP, obsługuje negocjację wersji protokołu, uwierzytelnianie i wywoływanie narzędzi, ale same narzędzia muszą przyjść z rdzenia WordPressa albo z innych wtyczek. Bez zarejestrowanych abilities adapter jest pustym serwerem.
Ten podział jest kluczowy dla zrozumienia, co faktycznie dostajemy. Abilities API to rejestr nazwanych akcji: publikacja wpisu, odczyt taksonomii, aktualizacja pola meta, cokolwiek, co wtyczka zdecyduje się zgłosić w maszynowo czytelnym formacie. Adapter tłumaczy ten rejestr na język, którym mówią klienci MCP, czyli asystenci i agenci po drugiej stronie połączenia.
Jason Adams, Director of Engineering, AI w Automattic, zapowiedział publikację wtyczki w repozytorium. Jednocześnie stare repozytorium Automattic/wordpress-mcp zostało oznaczone jako wygasające: dalszy rozwój i wsparcie przeniesiono do WordPress/mcp-adapter.
Kontekst: Abilities API, AI Client i rok pracy na GitHubie
Żeby zrozumieć, dlaczego publikacja wersji 0.7.0 jest wydarzeniem, trzeba cofnąć się do WordPressa 6.9. To wtedy do rdzenia weszło serwerowe Abilities API, czyli standard rejestrowania możliwości wtyczek, motywów i samego core w formacie zrozumiałym dla maszyn. WordPress 7.0 pod nazwą Armstrong, wydany 20 maja 2026 roku, dołożył do tego AI Client (dostawcowo neutralny sposób wysyłania promptów do modeli) oraz wersję Abilities API dostępną z JavaScriptu.
Adapter jest trzecim elementem tej układanki i jedynym, który nie trafił do rdzenia. Przez cały ten czas rozwijał się jako wtyczka instalowana z GitHuba lub dociągana Composerem, co wystarczało agencjom i deweloperom, ale skutecznie odcinało zwykłych administratorów witryn. Wersja 0.7.0, opublikowana 2 października 2026 roku, jest pierwszą dostępną z panelu WordPressa.
Ścieżka wersji pokazuje, jak szybko ten kod dojrzewał. W wydaniu 0.5.0 z kwietnia 2026 roku adapter przeszedł na bibliotekę wordpress/php-mcp-schema, czyli na typowane obiekty protokołu zamiast ręcznie budowanych tablic. Wersja 0.6.0 z 12 sierpnia podniosła wymaganie do WordPressa 6.9 i zakończyła wsparcie dla samodzielnej wtyczki Abilities API. Dzień później 0.6.1 naprawiła pakiet dystrybucyjny, w którym mapa klas autoloadera wskazywała na pliki wycięte z archiwum: wywołanie class_exists( 'WP_CLI' ) mogło w tej konfiguracji wywrócić całe żądanie.
Kluczowe fakty
| Parametr | Wartość |
|---|---|
| Nazwa i slug | MCP Adapter, mcp-adapter |
| Wersja w repozytorium | 0.7.0 |
| Data wydania | 2 października 2026 |
| Autor w karcie wtyczki | WordPress.org |
| Aktywne instalacje | ponad 40 000 |
| Wymagany WordPress | 6.9 lub nowszy |
| Testowana do | 7.1.3 |
| Wymagany PHP | 7.4 lub nowszy |
| Transporty | HTTP, STDIO, własne (rozszerzalne) |
| Rewizja protokołu | 2026-07-28, zgodność wstecz z 2025-06-18 i 2024-11-05 |
| Uwierzytelnianie | konta użytkowników WordPressa |
Jak to działa: transporty, uprawnienia i zasada opt-in
Adapter obsługuje transport HTTP oraz STDIO, a dodatkowo pozwala dopisać własny. Klient MCP łączy się, wskazując endpoint witryny i uwierzytelniając się danymi użytkownika WordPressa. To ważny szczegół architektoniczny: agent nie działa poza systemem uprawnień, lecz wewnątrz niego, z rolami i capabilities tego konta, na które się zalogował.
Druga warstwa zabezpieczeń to jawna zgoda na wystawienie każdej pojedynczej akcji. Ability jest widoczna przez MCP tylko wtedy, gdy ma ustawione meta.public: true, a meta.mcp.public pozwala ją z tego wyłączyć. Nawet po wystawieniu nic nie obchodzi normalnych callbacków uprawnień: przed wykonaniem narzędzia nadal sprawdzane są capabilities. Model jest więc odwrotny do tego, co znamy z klasycznych wtyczek integracyjnych, gdzie włączenie modułu zwykle oznaczało otwarcie wszystkiego naraz.
Wersja 0.7.0 dokłada obsługę rewizji protokołu oznaczonej datą 2026-07-28. Najciekawsze zmiany to bezsesyjne server/discover, metadane protokołu przekazywane per żądanie oraz nowe nagłówki HTTP: Mcp-Method, Mcp-Name i Mcp-Param-*. Starsze klienty nie zostają na lodzie: te proszące o rewizje 2025-06-18 albo 2024-11-05 nadal się połączą i będą obsłużone przez schemat 2025-11-25. Doszła też elicytacja, czyli możliwość dopytania użytkownika o brakujące dane w trakcie wywołania narzędzia, dostępna dla narzędzi bezpośrednio wywoływalnych przez McpInputRequired.
Warto doprecyzować, czym to się różni od zwykłego REST API, bo pytanie wraca w każdej rozmowie o MCP. WordPress od lat ma REST API i agent mógłby z niego korzystać bez żadnej wtyczki. Różnica leży w odkrywalności. Klient REST musi z góry wiedzieć, jakie endpointy istnieją, jakie przyjmują parametry i co znaczą pola odpowiedzi, czyli ktoś musi to opisać w kodzie klienta. Klient MCP pyta serwer, co ten potrafi, i dostaje listę narzędzi z opisami oraz schematami parametrów. Z perspektywy modelu to przepaść: w pierwszym przypadku integracja jest pisana ręcznie pod konkretną witrynę, w drugim ten sam asystent obsłuży każdą instalację WordPressa, która ma adapter i wystawione abilities.
Stąd bierze się wartość statusu kanonicznego. Dopóki istniało kilka wtyczek robiących to samo, odkrywalność była iluzoryczna, bo klient i tak musiał wiedzieć, z którą implementacją rozmawia. Jedna wtyczka utrzymywana w organizacji WordPress zamienia tę loterię w przewidywalny kontrakt.
Jeśli chcesz zobaczyć, jak ta mechanika wygląda od strony codziennej pracy marketera, opisywaliśmy już podłączanie Search Console, GA4 i WordPressa do asystenta AI przez MCP oraz pełny case budowy agenta AI publikującego na WordPressie.
Co to znaczy dla SEO i AIO
Pierwszy i najbardziej oczywisty skutek dotyczy operacyjnego SEO. Jeden standardowy serwer MCP na stronie oznacza, że asystent może odczytać strukturę treści, sprawdzić taksonomie, podmienić meta description albo zaktualizować wpis bez pisania dedykowanego klienta REST do każdej wtyczki. Praca, która wcześniej wymagała własnego kodu glue, staje się kwestią zarejestrowania ability.
Drugi skutek jest bardziej strategiczny i dotyczy widoczności w AIO. Model Context Protocol to otwarty standard opracowany przez Anthropic i opisuje on sposób, w jaki systemy AI łączą się z aplikacjami, danymi, wtyczkami i witrynami. Jeśli ten sam protokół staje się domyślną drogą dostępu agentów do WordPressa, to dane, które wystawisz przez abilities, są w praktyce tym, co agent o twojej witrynie wie z pierwszej ręki. Nie zastępuje to indeksu wyszukiwarki ani cytowań w odpowiedziach modeli, ale buduje drugi, równoległy kanał: taki, w którym nie czekasz na crawl, a odpowiadasz na zapytanie w czasie rzeczywistym.
W praktyce pierwsze zadania, które warto oddać agentowi po podłączeniu adaptera, są nudne i powtarzalne, czyli dokładnie takie, w jakich automatyzacja się zwraca:
- audyt pól SEO na całym archiwum, z wypisaniem wpisów bez meta description albo z opisem identycznym jak tytuł,
- przegląd linkowania wewnętrznego i wskazanie wpisów bez żadnego linku przychodzącego,
- uzupełnianie atrybutów alt w obrazach, gdzie model widzi kontekst wpisu, a nie tylko nazwę pliku,
- masowe porządkowanie kategorii i tagów po migracji albo po zmianie struktury serwisu,
- sprawdzanie, czy wpisy z danej kategorii mają spójne dane strukturalne.
Żadne z tych zadań nie jest nowe i każde da się zrobić skryptem. Nowe jest to, że nie trzeba pisać skryptu osobno dla każdej witryny i każdej wtyczki SEO, bo opis narzędzi przychodzi z serwera.
Trzeci skutek jest ostrzeżeniem. Standaryzacja dostępu to także standaryzacja powierzchni ataku. Zasada opt-in i capabilities zdejmują dużą część ryzyka, ale tylko wtedy, gdy ktoś faktycznie przejrzy, które abilities są publiczne na danej instalacji. Przy kilkudziesięciu wtyczkach lista bywa dłuższa, niż administrator przypuszcza. Historia tego rynku dostarczyła już zresztą przykładów nieuważnych wdrożeń: pisaliśmy o tym, jak Rank Math otwierał dane SEO dla agentów AI w ramach narzędzi MCP.
Reakcje branży
Ton komentarzy jest zgodny i spokojny, co przy tempie wydarzeń w AI zdarza się rzadko. Serwis Search Engine Journal podkreśla przede wszystkim zgodność wstecz jako warunek sensownego istnienia wtyczki w ekosystemie, w którym część witryn aktualizuje się z opóźnieniem liczonym w miesiącach. W materiałach towarzyszących publikacji pada argument, że adapter korzysta z Abilities API właśnie po to, by nie dublować funkcji rdzenia i nie budować drugiego, konkurencyjnego modelu autoryzacji.
Deweloperzy wtyczek czytają to inaczej, bardziej praktycznie: jeśli adapter jest kanoniczny, to inwestycja w rejestrowanie własnych abilities przestaje być zakładem o to, który standard wygra. WooCommerce poszedł tą drogą już wcześniej, udostępniając kanoniczne abilities dla produktów i zamówień. Dla agencji oznacza to prostszy rachunek: integracja z jednym protokołem zamiast utrzymywania kilku ścieżek.
Osobny wątek dotyczy hostingu i wydajności. Endpoint MCP to ruch uwierzytelniony, a więc z definicji pomijający cache strony. Wywołanie narzędzia, które przegląda kilkaset wpisów, jest serią zapytań do bazy wykonywaną w tempie, jakiego nie generuje żaden człowiek klikający w panelu. Na współdzielonym hostingu z niskim limitem połączeń to realne ryzyko, zwłaszcza gdy agent pracuje w pętli. Adapter dba o protokół, nie o to, żeby twoja baza przeżyła ambitny prompt.
Pozostaje krytyka, którą warto zapisać. Numer wersji nadal zaczyna się od zera, a wydanie 0.7.0 wprowadza zmiany łamiące zgodność dla kodu rozszerzającego adapter. Status kanonicznej wtyczki nie jest tym samym co obietnica stabilnego API.
Zmiany łamiące zgodność: na co uważać przy aktualizacji
Jeśli twój kod tylko rejestruje abilities i korzysta z create_server(), aktualizacja powinna przejść bez niespodzianek. Problem dotyczy integracji, które weszły głębiej.
- Usunięto generowane klasy DTO oraz walidatory
McpToolValidator,McpResourceValidatoriMcpPromptValidator, a razem z nimi filtrmcp_adapter_validation_enabled. - Własne transporty muszą teraz delegować do
HttpRequestHandleralboMcpWireOrchestrator. - Komponenty niepoprawne w każdej wspieranej rewizji protokołu są odrzucane, a nie, jak wcześniej, po cichu naprawiane. To zmiana, która ujawnia błędy istniejące od dawna.
- Używanie MCP Adaptera jako biblioteki dołączanej przez Composera jest uznane za przestarzałe. Zalecana droga to instalacja wtyczki.
Zespół opublikował osobny przewodnik migracji dla 0.7.0 i wyraźnie prosi o przeczytanie go przed aktualizacją. Jest jeszcze jeden drobiazg z poprzedniego wydania, który warto pamiętać na multisite: w 0.6.0 magazyn sesji Streamable HTTP przeniósł się z klucza sieciowego na osobne klucze per witryna, więc aktywne sesje musiały się raz przelogować. Instalacje jednowitrynowe tego nie odczuły.
Przyjemna zmiana w 0.7.0 jest mało widowiskowa, ale rozwiązuje realny ból: domyślne abilities rejestrują się teraz poprawnie także wtedy, gdy Abilities API zostało zainicjalizowane wcześniej przez inną wtyczkę. Kolejność wczytywania przestaje decydować o tym, czy serwer ma co wystawić.
Co dalej
Najbliższe tygodnie pokażą dwie rzeczy. Pierwsza to tempo adopcji po stronie wtyczek: liczba instalacji adaptera mówi o gotowości administratorów, ale wartość użytkowa zależy od tego, ile wtyczek zarejestruje sensowne abilities. Druga to zachowanie dostawców hostingu, bo endpoint MCP na uwierzytelnionym koncie to nowy rodzaj ruchu, który trafi do logów, limitów i reguł WAF.
Dla redakcji i zespołów SEO rozsądna kolejność działań na dziś wygląda prosto. Sprawdzić wersję WordPressa, bo poniżej 6.9 rozmowa jest bezprzedmiotowa. Zainstalować adapter na środowisku testowym, nie na produkcji. Przejrzeć listę abilities oznaczonych jako publiczne i świadomie zdecydować, co zostaje. Założyć osobne konto techniczne dla agenta z minimalnym zestawem uprawnień, zamiast podłączać go kontem administratora. I dopiero wtedy mierzyć, ile pracy realnie ubywa.
Jest też pytanie, na które dziś nikt nie ma danych: jak zmierzyć zwrot z takiego wdrożenia. Ruch agentowy przez MCP nie pojawi się w Search Console, bo to nie wyszukiwanie, ani w standardowych raportach GA4, bo nie jest wizytą w przeglądarce. Jeśli ktoś chce raportować efekt, musi go szukać w logach serwera i w czasie pracy zespołu, a nie w panelach analitycznych. To samo ograniczenie, które utrudnia pomiar widoczności w odpowiedziach modeli, dotyczy więc także tej warstwy.
Numer wersji 0.7.0 przypomina, że to wciąż wczesny etap. Różnica wobec sytuacji sprzed tygodnia jest jednak jakościowa: dyskusja przeniosła się z pytania, który standard wybrać, na pytanie, co i komu wystawić.
FAQ
Czy MCP Adapter dodaje do WordPressa funkcje AI?
Nie. To warstwa serwera i transportu, która tłumaczy Abilities API WordPressa na Model Context Protocol. Narzędzia, z których skorzysta agent, muszą pochodzić z rdzenia lub z innych wtyczek. Bez zarejestrowanych abilities adapter nie ma czego wystawić.
Jakie są wymagania techniczne?
WordPress 6.9 lub nowszy i PHP 7.4 lub nowszy. Wtyczka jest testowana do WordPressa 7.1.3. Na starszych instalacjach nie zadziała, bo Abilities API weszło do rdzenia dopiero w 6.9.
Czy agent AI zobaczy wszystkie dane witryny?
Nie z automatu. Wystawienie jest opt-in: ability musi mieć meta.public: true, a meta.mcp.public pozwala ją wyłączyć. Dodatkowo przed każdym wywołaniem sprawdzane są uprawnienia konta, którym agent się uwierzytelnił, więc zakres dostępu wyznacza rola tego użytkownika.
Czy aktualizacja do 0.7.0 coś zepsuje?
Jeśli tylko rejestrujesz abilities, raczej nie. Jeśli rozszerzasz adapter, tak: usunięto klasy DTO, walidatory i filtr mcp_adapter_validation_enabled, własne transporty muszą delegować do HttpRequestHandler lub McpWireOrchestrator, a niepoprawne komponenty są odrzucane zamiast naprawiane. Zespół udostępnił przewodnik migracji.
Co to oznacza dla widoczności w AI?
Buduje drugi kanał dostępu obok indeksu wyszukiwarki. Agent, który łączy się przez MCP, czyta dane bezpośrednio z witryny, bez czekania na crawl. Nie zastępuje to pracy nad cytowaniami w odpowiedziach modeli, ale daje kontrolę nad tym, co agent wie o twoich treściach z pierwszej ręki.