Serwer MCP w pluginie WordPress: ruch AI, który ma sens po 2026

#Dlaczego serwer MCP w twoim pluginie WordPress to ruch AI, który przeżyje 2026

Dwa punkty danych z jednego tygodnia, maj 2026.

Założyciel Metorika Bryce Adams na WP Product Talk: nowa integracja MCP firmy przyciągnęła 500 użytkowników w ciągu dni od cichej premiery preview, najszybsze przyjęcie funkcji w jego dziesięcioletnim doświadczeniu. Ta sama rozmowa, ten sam Adams: klienci, którzy odchodzą z Metoriku, mają średni MRR o 40 procent niższy od klientów, którzy zostają. Przeczytał to jako AI biorące przypadki użytkowe commodity (podstawowe raporty, proste dashboards) i zostawiające rdzeniową pracę analityczną w spokoju.

GravityKit otworzył w tym tygodniu open-source Block MCP. To serwer MCP WordPressa, który działa na poziomie bloku, zamiast traktować treść postu jako pojedynczy string HTML. Zespół zbudował go, bo istniejące serwery MCP REST-API-based usuwają separatory bloków, którymi WordPress identyfikuje bloki, zwijając strukturalną treść w blok Classic. Trafili w buga dość razy na własnej stronie, żeby zobowiązać się do fixa.

To nie dwie historie. To jedna historia. W 2026 plugin WordPress, który dostarcza serwer MCP, to plugin, który się kompounduje. Plugin, który przykleja chat boxa do swojego admina, to plugin, który zostaje skanibalizowany.

Ten tekst to kontynuacja naszego pillara wdrożeń AI i łączy się bezpośrednio z naszą pracą nad budową serwerów MCP oraz historią integracji Abilities API z WordPressem 7.0. Argument tutaj jest komercyjny, nie tylko techniczny.

#Najważniejsze w jednym akapicie

• Dwa punkty danych z maja 2026 mówią to samo. Metorik MCP: 500 userów w dni, najszybsze przyjęcie w dziesięć lat. Adams: MRR odchodzących klientów o 40 procent niższy od retainowanych, co sugeruje że AI bierze przypadki commodity. GravityKit Block MCP: open-source, fixuje buga usuwającego separatory bloków przez REST API.
• Serwer MCP wystawia operacje domenowe pluginu jako tools wywoływalne przez agenta, które komponują się do wybranego agenta usera. Chat box uwięziony w adminie pluginu komponuje się tylko sam ze sobą.
• Commodity warstwa pluginu (raporty, dashboards, warianty wykresów) zostaje skanibalizowana przez generyczne narzędzia AI, które potrafią odpowiedzieć na te same pytania z surowych danych. Głęboka warstwa domenowa pluginu (custom atrybucja, matematyka kohort, plumbing integracyjny) przeżywa, bo AI nie ma kontekstu domenowego, chyba że plugin go da przez MCP.
• Kontrakt serwera MCP żyje w repo pluginu. Ten kontrakt jest stabilny przez wydania modeli. Chat box wytrenowany pod zachowanie konkretnego providera modelu zmienia się pod utrzymującym co sześć tygodni.
• Akcja: dostarcz serwer MCP, wystaw trzy do siedmiu operacji domenowych jako tools, udokumentuj kontrakt w repo, wersjonuj powierzchnię MCP odrębnie od wersji UI pluginu.

#Naturalny eksperyment Adamsa

Adams powiedział na WP Product Talk, że bał się AI z tego samego powodu, z którego każdy autor pluginu boi się AI w 2026: dół piramidy wartości (podstawowe raporty, proste agregacje) to dokładnie tam, gdzie AI jest najszybsze w kopiowaniu. Mógł sobie wyobrazić świat, gdzie Claude albo ChatGPT, wycelowany w te same surowe dane Shopify albo WooCommerce, produkuje te same wykresy, które produkuje Metorik, za darmo.

Co znalazł zamiast tego, po roku obserwacji, to że klienci opuszczający Metorik byli systematycznie tymi z niskim MRR. Średni MRR odchodzących o 40 procent poniżej retainowanych. Jego interpretacja: AI zrobiło dokładnie to, czego się bał na dole piramidy, i dokładnie nic na górze.

To naturalny eksperyment, bo Adams go nie zaprojektował. Stało się to z nim, podczas gdy rynek się przesuwał. Dane mówią, które funkcje, które Metorik dostarcza, są commodity (poszły do AI), a które są trwałe (Metorik retainuje klienta). Adams wymienił przypadki użytkowe klientów retainowanych: atrybucja wydatków reklamowych, matematyka kohort, custom segmentacja, integracja z API magazynu i fulfilmentu, agregacja multi-store. To nie są funkcje wykresowe. To operacje domenowe wymagające specyficznej implementacji Metoriku, wobec specyficznego kształtu danych, który zarobił przez dekadę.

Potem zszedł MCP integration, a 500 klientów retainowanych sięgnęło po niego w pierwszym tygodniu.

Integracja MCP to nie nowa funkcja produktu. To sposób, żeby agent klienta (Claude Desktop, Claude Code, ChatGPT Enterprise, własny stack wewnętrzny) wywołał te same operacje domenowe klientów retainowanych jako tools. Klient robi teraz w swoim agencie to, co kiedyś robił logując się do Metoriku. Metorik ich nie stracił, stał się niewidoczną instalacją hydrauliczną pod ich workflow agentowym.

To jest fosa.

#Dlaczego Block MCP ma większe znaczenie niż jego kształt pluginu sugeruje

Block MCP od GravityKit jest technicznie małym pluginem. Serwer MCP WordPressa, wystawiający edycję na poziomie bloku jako tools. Powód, dla którego ma znaczenie, to to, że identyfikuje tryb porażki każdej poprzedniej próby MCP WordPressa.

Istniejące serwery MCP WordPressa (a jest ich kilka) piszą przez REST API WordPressa. REST API traktuje content jako pojedynczy string HTML. WordPress wewnętrznie używa komentarzy HTML jako separatorów bloków (<!-- wp:paragraph -->, <!-- wp:image {...} -->). Kiedy agent edytuje string content i zapisuje go z powrotem, komentarze separatorów bloków przeżywają tylko, jeśli agent o nich wie. Większość agentów nie wie. Round-trip HTML usuwa separatory. Post, który był strukturalnym stackiem dwudziestu bloków, staje się pojedynczym blokiem Classic przy zapisie.

To nie hipotetyczne. Strategiczny ops manager GravityKit Casey Burridge powiedział, że zespół uderzał w buga wielokrotnie na własnej stronie. Każdy, kto próbował zbudować agenta edycji treści wobec REST API WordPressa, w niego uderzył.

Block MCP fixuje tryb porażki wystawiając operacje na poziomie bloku jako tools MCP. add_block, update_block, move_block, delete_block, zamiast get_content plus set_content. Agent widzi post jako drzewo, nie string. Kontrakt jest stabilny przez aktualizacje bloków WordPressa, bo kontrakt jest zdefiniowany w serwerze MCP, nie w jakimkolwiek serializerze HTML, który core WordPressa akurat dziś dostarcza.

Głębszy punkt: różnica między “MCP owijający REST” a “MCP zaprojektowany wokół domeny” to różnica między commodity tooling a trwałą powierzchnią. Block MCP jest pierwszym serwerem MCP WordPressa działającym na warstwie domenowej (bloki są domenowym prymitywem treści WordPressa), nie na warstwie transportowej API.

To jest wzorzec. Każdy autor pluginu powinien zapytać: jaki jest domenowy prymityw mojego pluginu i czy mój serwer MCP go wystawia, czy wystawia opakowany endpoint REST?

#Czym jest serwer MCP, w dwóch akapitach

Model Context Protocol to otwarty standard Anthropic dla tego, jak agenci AI odkrywają i wywołują tools. Serwer MCP wystawia listę tools (każdy z nazwą, opisem, JSON schemą inputów i implementacją), a każdy agent zdolny do MCP (Claude Desktop, Claude Code, ChatGPT Enterprise, custom stack) może się połączyć, odkryć tools i je wywołać. Serwer może być lokalny (stdio) albo zdalny (SSE / HTTP). Dla pluginu WordPress lokalny przypadek jest właściwym kształtem: serwer biegnie obok pluginu, agent łączy się z maszyny usera.

Autor pluginu definiuje tools. To cały sens. Tools to operacje domenowe pluginu, nazwane w słowniku pluginu, z input schemami odzwierciedlającymi model danych pluginu. Agent operuje teraz na poziomie wiedzy domenowej pluginu. Klient robi w czacie to, co kiedyś robił klikając przez pięć ekranów admina.

Na naszym tech radarze Anthropic Model Context Protocol siedzi w pierścieniu Adopt, WordPress Abilities API w Trial (kanoniczna powierzchnia integracji w WordPress 7.0 i nowszych), a niedawno dodaliśmy wp-agentic-admin (CloudFest Hackathon 2026) w Assess jako referencyjną implementację wzorca.

#Macierz dwa na dwa

Plugin WordPress 2026 żyje w macierzy dwa na dwa:

Ćwiartka płytkiej domeny (górny rząd) to gdzie siedzi większość premier “pluginów AI WordPressa”. Owijają cienką warstwę podstawowej funkcjonalności (eksport CSV, proste wykresy, sugestie przepisywania treści) i albo dodają chat boxa, albo nie mają MCP w ogóle. Obie kolumny są ślepą uliczką. Chat box trenuje habits userów pod commodity powierzchnię pluginu, a serwer MCP nie ma nic zróżnicowanego do wystawienia.

Ćwiartka głębokiej domeny (dolny rząd) to gdzie żyją trwałe pluginy. Metorik, JetEngine od Crocoblock, GravityForms, GravityView od GravityKit, są każdy przykładem. Bez MCP te pluginy retainują klientów, ale stają się niewidoczne dla workflow agentowych. Z MCP komponują się do workflow agentowych i stają się niezbędną hydrauliką.

Ciekawe pytanie dla autora pluginu w tej ćwiartce to nie “czy dostarczyć MCP” (tak), ale “które trzy do siedmiu operacji są właściwymi do wystawienia”.

#Wybór operacji do wystawienia

Autorzy pluginów często chcą wystawić każdy endpoint CRUD jako tools MCP. To źle. Sens MCP to nie dostęp do API, to operacje na poziomie domenowym. Długa lista trywialnych tools confunduje agenta i produkuje wezwania niskiej jakości. Krótka lista znaczących operacji to to, co czyni agenta użytecznym.

Heurystyka, której używamy:

1. Wymień akcje, które klient podejmuje w twoim pluginie w typowym tygodniu. Posortuj po częstotliwości.
2. Zgrupuj je w klastry powiązanych akcji. Dla Metoriku jednym klastrem mogłaby być “zapytania atrybucji reklamowej”, innym “segmentacja kohortowa”.
3. Dla każdego klastra zdefiniuj pojedyncze tool MCP, które bierze parametry klastra i zwraca wynik klastra. Tool to operacja domenowa, nie endpoint API.
4. Zatrzymaj listę na siedmiu. Jeśli masz więcej niż siedem, nie skończyłeś klastrowania.
5. Każdy tool dostaje jednoparagrafowy opis w serwerze MCP. Opis to to, co agent czyta, żeby zdecydować, kiedy go użyć. Optymalizuj pod czytanie agenta, nie pod kompletność dokumentacji człowieka.

Autor pluginu, który tym pójdzie, dostaje powierzchnię MCP z pięcioma do siedmiu tools, każdy znaczący, każdy istotny dla klienta retainowanego. Agent czyta opisy i wybiera poprawnie. Codzienny workflow klienta zawiera teraz operacje domenowe pluginu jako requesty językiem naturalnym.

#Kontrakt żyje w repo

To część argumentu, którą większość autorów pluginów przeoczy, kiedy sięga po “dodajmy Claude do naszego admina” w pierwszej kolejności.

Chat box przyklejony do admina pluginu ma kontrakt, który żyje w prompcie, system message i warstwie wywołania tools chat boxa. Kiedy podstawowy provider modelu zmienia format wywoływania funkcji (zdarzyło się to trzy razy w ostatnich 18 miesiącach w Anthropic, OpenAI i Google), chat box pęka, dopóki utrzymujący nie zaktualizuje wrappera. Kontrakt chat boxa nie jest trwały. Jego cykl życia to API providera modelu.

Kontrakt serwera MCP żyje w repo pluginu jako JSON schema na tool. Kontrakt jest stabilny przez wydania modeli. Kiedy Anthropic aktualizuje tool-calling Claude’a, agent się aktualizuje, nie serwer MCP. Kiedy OpenAI dostarcza nowy kształt function-calling, ten sam serwer MCP wciąż działa, bo MCP to standard, do którego adaptuje się provider modelu. Autor pluginu pisze tools raz i je dostarcza.

To trwały kształt inżynierski. Chat box to ten jednorazowy.

Klient zauważa to na wieloletnim horyzoncie. Chat box, który działał w 2025, pękł dwa razy w 2026. Serwer MCP, który zszedł w 2025, wciąż działa w 2026 z obecnym wyborem agenta klienta. Klient ufa pluginowi, który dostarcza trwałą powierzchnię.

#Counter-position: a co z wp-agentic-admin?

Czytelnik patrzący na projekt CloudFest Hackathon 2026 wp-agentic-admin zobaczy inny model: in-browser WebLLM (Qwen 1.7B albo 7B przez WebGPU) biegnący w pełni na urządzeniu usera, wywołujący WordPress Abilities API przez pętlę ReAct. Local-first, bez kosztu API, bez zdalnego modelu.

Ten model ma miejsce. To świetne dopasowanie dla single-tenant, hobbysty albo paranoidalnego prywatnościowo admina WordPressa, który chce triażować swoją własną stronę bez zewnętrznej zależności. To nie jest trwała odpowiedź dla pluginów obsługujących zespoły B2B, które już prowadzą Claude Enterprise, ChatGPT Enterprise albo self-hosted stacki agentowe przez wszystkie swoje wewnętrzne workflow.

Dla tych zespołów, agent, z którym chcą rozmawiać z pluginu WordPressa, to ten sam agent, którego używają do CRM, hurtowni danych, trackera issue i docsów. Serwer MCP to to, co czyni plugin dostępnym dla tego agenta. In-browser WebLLM to równoległy wszechświat bez kompozycyjnego zasięgu.

Obydwa modele są ważne. Wzorzec serwera MCP to ten, który się dopasowuje do tego, jak zespoły klientów B2B już pracują.

#Co to oznacza dla czytelnika wppoland

Jeśli dostarczasz plugin WordPress albo WooCommerce: zbuduj serwer MCP. Trzy do siedmiu operacji domenowych, wystawionych jako tools, kontrakt w repo, wersjonowane odrębnie od wersji UI pluginu. Zrób to przed dodaniem chat boxa. Jeśli możesz zrobić tylko jedno, zrób serwer MCP.

Jeśli operujesz stroną WordPress na skalę (multi-site, agencja, enterprise): przy ocenie pluginów do adopcji zadawaj pytanie “czy dostarcza serwer MCP” tak, jak kiedyś zadawałeś “czy ma REST API”. Pytanie MCP to ekwiwalent 2026.

Jeśli jesteś klientem wppoland oceniającym gdzie zainwestować wysiłek inżynierski w 2026: tu sugerujemy inwestować. Budujemy custom Claude skills i serwery MCP dla zespołów B2B prowadzących workflow agent-first na WordPressie. Deliverable to serwer MCP, tools domenowe, kontrakt i onboarding zespołu. Deliverable to nie chat box.

#Argument zamykający

Punkt danych Metoriku z maja 2026 i open-source release Block MCP to ten sam sygnał na różnych skalach. Plugin wystawiający operacje domenowe jako tools MCP kompounduje się z jakimkolwiek agentem, który klient zaadoptuje. Plugin, który nie, zostaje skanibalizowany na warstwie commodity i niewidoczny na warstwie domenowej.

Jest małe operacyjne okno w 2026, żeby dostarczyć MCP zanim rynek oczekuje, że każdy plugin go ma. Autorzy pluginów, którzy sięgają po powierzchnię MCP w tym roku, to ci, którzy będą na allow-liście integratora agentowego, kiedy rynek dogoni.

#Źródła

• Bryce Adams na WP Product Talk (transkrypt via WP Product Talk)
• Dokumentacja integracji MCP Metoriku
• Open-source release Block MCP GravityKit
• Anthropic Model Context Protocol
• Crocoblock JetEngine 8-letni retrospektywa i MCP Command Center

#Powiązane teksty u nas

• Pillar: Konsultacje wdrożeń AI
• Budowa serwerów MCP
• WordPress 7.0 features: infrastruktura AI i Abilities API podsumowanie
• Tech Radar: Anthropic MCP (Adopt)
• Tech Radar: WordPress Abilities API (Trial)
• Tech Radar: wp-agentic-admin (Assess)

Ostatnio sprawdzone: 2026-05-23