MCP-server i WordPress-plugin: KI-grepet som varer

#Hvorfor en MCP-server i WordPress-pluginet ditt er AI-trekket som overlever

To datapunkter fra en uke, mai 2026.

Metorik-grunnlegger Bryce Adams paa WP Product Talk: selskapets nye MCP-integrasjon trakk 500 brukere innen dager etter en stille preview-lansering, raskere enn noen funksjon han har levert paa ti aar. Samme samtale, samme Adams: kunder som forlater Metorik har en gjennomsnittlig MRR 40 prosent lavere enn kunder som blir. Han leste det som at AI tar commodity-bruksomraadene (grunnleggende rapporter, enkle dashboards) og lar kjerneanalysen vaere i fred.

GravityKit open-sourcet Block MCP denne uken. Det er en WordPress MCP-server som opererer paa blokknivaa, i stedet for aa behandle innholdet i et innlegg som en enkelt HTML-streng. Teamet bygde det fordi eksisterende REST-API-baserte MCP-servere fjerner blokk-skilletegnene WordPress bruker for aa identifisere blokker, og kollapser strukturert innhold til en Classic-blokk. De stoette paa feilen nok ganger paa egen side til aa forplikte seg til en rettelse.

Dette er ikke to historier. Det er en historie. I 2026 er WordPress-pluginet som leverer en MCP-server pluginet som komponerer. Pluginet som limer en chatboks paa admin-flaten er pluginet som blir kannibalisert.

Dette stykket er fortsettelsen av vaar AI-implementering-pillar og henger direkte sammen med vaart arbeid med MCP-server-utvikling og integrasjonen av Abilities API i WordPress 7.0. Argumentet her er kommersielt, ikke bare teknisk.

#TL;DR

• To datapunkter fra mai 2026 sier det samme. Metorik MCP: 500 brukere paa dager, raskeste adopsjon paa ti aar. Adams: MRR for de som forlater er 40 prosent lavere enn de som blir, noe som tyder paa at AI tar commodity-tilfeller. GravityKit Block MCP: open source, fikser feilen med fjerning av blokk-skilletegn via REST API.
• En MCP-server eksponerer pluginets domeneoperasjoner som agent-kallbare tools som komponerer inn i brukerens valgte agent. En chatboks fanget i plugin-admin komponerer bare med seg selv.
• Pluginets commodity-lag (rapporter, dashboards, diagramvarianter) blir kannibalisert av generiske AI-verktoey som kan svare paa de samme spoersmaalene fra raadata. Pluginets dype domenelag (egen attribusjon, kohortmatematikk, integrasjons-plumbing) overlever, fordi AI ikke har domenekonteksten med mindre pluginet gir den via MCP.
• MCP-serverens kontrakt lever i plugin-repoet. Den kontrakten er stabil paa tvers av modell-utgivelser. En chatboks trent mot oppfoerselen til en bestemt modelltilbyder skifter under vedlikeholderen hver sjette uke.
• Aksjon: lever en MCP-server, eksponer tre til sju domeneoperasjoner som tools, dokumenter kontrakten i repoet, versjoner MCP-flaten separat fra plugin-UI-versjonen.

#Det naturlige eksperimentet Adams kjoerte

Adams sa paa WP Product Talk at han var nervoes for AI av samme grunn som enhver pluginforfatter er nervoes for AI i 2026: bunnen av verdipyramiden (grunnleggende rapporter, enkle aggregeringer) er akkurat der AI er raskest til aa kopiere. Han kunne forestille seg en verden hvor Claude eller ChatGPT, rettet mot de samme Shopify- eller WooCommerce-raadataene, produserer de samme grafene Metorik produserer, gratis.

Det han fant i stedet, etter et aar med observasjon, var at kundene som forlot Metorik systematisk var de med lav MRR. Gjennomsnittlig MRR blant de som forlater 40 prosent under de som blir. Hans tolkning: AI gjorde akkurat det han fryktet i bunnen av pyramiden, og akkurat ingenting paa toppen.

Dette er et naturlig eksperiment fordi Adams ikke designet det. Det skjedde med ham mens markedet flyttet seg. Dataene forteller deg hvilke funksjoner Metorik leverer som er commodity (gaatt til AI) og hvilke som er holdbare (Metorik beholder kunden). Adams listet retainerte kunders bruksomraader som: attribusjon av annonseutgifter, kohortmatematikk, egen segmentering, integrasjon med lager- og fulfilment-APIer, multi-store-aggregering. Dette er ikke diagramfunksjoner. Dette er domeneoperasjoner som krever Metoriks spesifikke implementasjon, mot den spesifikke datafasongen produktet har tjent inn over et tiaar.

Saa kom MCP-integrasjonen, og 500 retainerte kunder grep etter den i loepet av foerste uke.

For det nordiske leserbildet er dette uvanlig viktig. Norske B2B-team kjoerer typisk faa, hoeyt tilliterte SaaS-verktoey: Visma for regnskap og loenn, Tripletex for prosjektoekonomi, og kanskje Tibber eller Otovo som forbruksflate. Naar slike team naa adopterer Claude Enterprise eller ChatGPT Enterprise paa tvers av selskapet, foergaar integrasjonsvalget paa samme akse: hvilke verktoey snakker MCP og kan kalles av agenten uten et ekstra mellomledd? Et WordPress- eller WooCommerce-plugin uten MCP-server faller utenfor det indre verktoeysettet til den nordiske B2B-kjoeperen. Den lokale eksporten av norsk B2B-programvare til Sverige, Danmark og Finland hviler paa den samme komposisjonsmodellen, saa pluginforfattere som retter seg mot dette markedet maa tenke MCP foer chat.

MCP-integrasjonen er ikke en ny produktfunksjon. Det er en maate for kundens agent (Claude Desktop, Claude Code, ChatGPT Enterprise, en egen intern stack) til aa kalle de samme retainerte-kunde-domeneoperasjonene som tools. Kunden gjoer naa i sin agent det hen pleide aa gjoere ved aa logge inn paa Metorik. Metorik mistet dem ikke, det ble usynlig roerlegging under deres agent-workflow.

Det er vollgraven.

#Hvorfor Block MCP betyr mer enn pluginformen tilsier

GravityKits Block MCP er teknisk et lite plugin. En WordPress MCP-server som eksponerer redigering paa blokknivaa som tools. Grunnen til at det teller er at det identifiserer feilmoenstret til hvert tidligere WordPress MCP-forsoek.

Eksisterende WordPress MCP-servere (og det er flere) skriver via WordPress REST API. REST API behandler content som en enkelt HTML-streng. WordPress bruker internt HTML-kommentarer som blokk-skilletegn (<!-- wp:paragraph -->, <!-- wp:image {...} -->). Naar agenten redigerer innholds-strengen og skriver den tilbake, overlever blokk-skilletegnkommentarene bare hvis agenten kjenner til dem. De fleste agenter gjoer ikke det. HTML-rundturen fjerner skilletegnene. Innlegget som var en strukturert stack av tjue blokker blir en enkelt Classic-blokk ved lagring.

Dette er ikke hypotetisk. GravityKits strategiske ops-leder Casey Burridge sa at teamet stoette gjentatte ganger paa feilen paa egen side. Alle som har proevd aa bygge en agent for innholdsredigering mot WordPress REST API har stoett paa den.

Block MCP fikser feilmoenstret ved aa eksponere operasjoner paa blokknivaa som MCP-tools. add_block, update_block, move_block, delete_block, i stedet for get_content pluss set_content. Agenten ser innlegget som et tre, ikke en streng. Kontrakten er stabil paa tvers av WordPress-blokk-oppdateringer, fordi kontrakten er definert i MCP-serveren, ikke i hvilken HTML-serialiserer WordPress-kjernen tilfeldigvis leverer i dag.

Det dypere poenget: forskjellen mellom “MCP pakket rundt REST” og “MCP designet rundt domenet” er forskjellen mellom commodity-verktoey og en holdbar flate. Block MCP er den foerste WordPress MCP-serveren som opererer paa domenelaget (blokker er domeneprimitivet i WordPress-innhold), ikke paa API-transportlaget.

Dette er moenstret. Hver pluginforfatter boer spoerre: hva er domeneprimitivet i pluginet mitt, og eksponerer MCP-serveren min det, eller eksponerer den en pakket REST-endepunkt?

#Hva en MCP-server er, i to avsnitt

Model Context Protocol er en aapen standard fra Anthropic for hvordan AI-agenter oppdager og kaller tools. En MCP-server eksponerer en liste over tools (hver med et navn, en beskrivelse, en JSON schema for input og en implementasjon), og enhver MCP-kapabel agent (Claude Desktop, Claude Code, ChatGPT Enterprise, egne stacks) kan koble seg til, oppdage tools og kalle dem. Serveren kan vaere lokal (stdio) eller ekstern (SSE / HTTP). For et WordPress-plugin er det lokale tilfellet riktig form: serveren kjoerer ved siden av pluginet, agenten kobler seg fra brukerens maskin.

Pluginforfatteren definerer tools. Det er hele poenget. Tools er pluginets domeneoperasjoner, navngitt i pluginets vokabular, med input-schemas som speiler pluginets datamodell. Agenten opererer naa paa pluginets domenekunnskapsnivaa. Kunden gjoer i chat det hen pleide aa gjoere ved aa klikke gjennom fem admin-skjermbilder.

Paa vaart tech radar sitter Anthropic Model Context Protocol i Adopt-ringen, WordPress Abilities API i Trial (den kanoniske integrasjonsflaten i WordPress 7.0 og senere), og vi la nylig til wp-agentic-admin (CloudFest Hackathon 2026) i Assess som en referanseimplementasjon av moenstret.

#To-ganger-to-matrisen

WordPress-pluginet i 2026 lever i en to-ganger-to-matrise:

Kvadranten med grunn domene (oeverste rad) er hvor de fleste “WordPress AI-plugin”-lanseringer sitter. De pakker et tynt lag av grunnleggende funksjonalitet (CSV-eksport, enkle grafer, forslag til omskriving av innhold) og legger enten til en chatboks eller har ingen MCP i det hele tatt. Begge kolonner er blindspor. Chatboksen trener brukervaner mot pluginets commodity-flate, og MCP-serveren har ingenting differensiert aa eksponere.

Kvadranten med dypt domene (nederste rad) er hvor de holdbare pluginene lever. Metorik, Crocoblocks JetEngine, GravityForms, GravityKits GravityView, er hvert eksempler. Uten MCP beholder disse pluginene kunder, men blir usynlige for agent-workflows. Med MCP komponerer de inn i agent-workflows og blir uunnvaerlig roerlegging.

Det interessante spoersmaalet for en pluginforfatter i denne kvadranten er ikke “skal vi levere MCP” (ja), det er “hvilke tre til sju operasjoner er de rette aa eksponere”.

#Aa velge operasjonene som skal eksponeres

Pluginforfattere vil ofte eksponere hvert CRUD-endepunkt som MCP-tools. Dette er feil. Poenget med MCP er ikke API-tilgang, det er operasjoner paa domenenivaa. En lang liste trivielle tools forvirrer agenten og produserer kall av lav kvalitet. En kort liste meningsfulle operasjoner er det som gjoer agenten nyttig.

Heuristikken vi bruker:

1. List opp handlingene en kunde foretar i pluginet ditt paa en typisk uke. Sorter etter frekvens.
2. Grupper dem i klynger av relaterte handlinger. For Metorik kan en klynge vaere “annonseattribusjons-spoerringer”, en annen “kohort-segmentering”.
3. For hver klynge, definer et enkelt MCP-tool som tar klyngens parametere og returnerer klyngens resultat. Toolen er domeneoperasjonen, ikke API-endepunktet.
4. Begrens listen til sju. Hvis du har mer enn sju, har du ikke fullfoert klyngingen.
5. Hver tool faar en ett-avsnitts beskrivelse i MCP-serveren. Beskrivelsen er det agenten leser for aa bestemme naar den skal brukes. Optimaliser for agentens lesing, ikke for fullstendighet i menneskelig dokumentasjon.

En pluginforfatter som foelger dette faar en MCP-flate med fem til sju tools, hver meningsfull, hver retainert-kunde-relevant. Agenten leser beskrivelsene og velger riktig. Kundens daglige workflow inkluderer naa pluginets domeneoperasjoner som forespoersler i naturlig spraak.

#Kontrakten lever i repoet

Dette er den delen av argumentet de fleste pluginforfattere overser naar de griper etter “la oss legge til Claude i admin-flaten vaar” foerst.

En chatboks limt paa plugin-admin har en kontrakt som lever i chatboksens prompt, systemmelding og tool-kallende lag. Naar den underliggende modelltilbyderen endrer function-calling-formatet (dette har skjedd tre ganger paa de siste 18 maanedene hos Anthropic, OpenAI og Google), brytes chatboksen til vedlikeholderen oppdaterer wrapperen. Chatboksens kontrakt er ikke holdbar. Livssyklusen er modelltilbyderens API.

En MCP-servers kontrakt lever i plugin-repoet som en JSON schema per tool. Kontrakten er stabil paa tvers av modell-utgivelser. Naar Anthropic oppdaterer Claudes tool-calling, oppdateres agenten, ikke MCP-serveren. Naar OpenAI leverer en ny function-calling-form, fungerer den samme MCP-serveren fortsatt, fordi MCP er standarden modelltilbyderen tilpasser seg. Pluginforfatteren skriver tools en gang og leverer dem.

Dette er den holdbare engineering-formen. Chatboksen er den engangsbruk-formen.

Kunden legger merke til dette over en flereaarig horisont. Chatboksen som fungerte i 2025 broet to ganger i 2026. MCP-serveren som ble levert i 2025 fungerer fortsatt i 2026 med kundens naavaerende agentvalg. Kunden stoler paa pluginet som leverer den holdbare flaten.

#Motposisjon: hva med wp-agentic-admin?

En leser som ser paa prosjektet CloudFest Hackathon 2026 wp-agentic-admin vil se en annen modell: en in-browser WebLLM (Qwen 1.7B eller 7B via WebGPU) som kjoerer helt paa brukerens enhet og kaller WordPress Abilities API gjennom en ReAct-loop. Local-first, uten API-kostnad, uten ekstern modell.

Den modellen har sin plass. Den passer godt for single-tenant, hobbyist eller personvern-paranoide WordPress-admin som vil triasjere sin egen side uten ekstern avhengighet. Den er ikke det holdbare svaret for plugins som betjener B2B-team som allerede kjoerer Claude Enterprise, ChatGPT Enterprise eller self-hosted agent-stacks paa tvers av alle sine interne workflows.

For disse teamene er agenten de vil snakke med WordPress-pluginet fra den samme agenten de bruker for CRM, datavarehus, issue tracker og dokumentasjon. MCP-serveren er det som gjoer pluginet tilgjengelig for den agenten. In-browser WebLLM er et parallelt univers uten komposisjonell rekkevidde.

Begge modeller er gyldige. MCP-server-moenstret er det som passer med hvordan B2B-kundeteamene allerede jobber.

#Hva dette betyr for wppoland-leseren

Hvis du leverer et WordPress- eller WooCommerce-plugin: bygg MCP-serveren. Tre til sju domeneoperasjoner, eksponert som tools, kontrakt i repoet, versjonert separat fra plugin-UI-versjonen. Gjoer dette foer du legger til en chatboks. Hvis du bare kan gjoere en ting, gjoer MCP-serveren.

Hvis du driver et WordPress-omraade i skala (multi-site, byraa, enterprise): naar du evaluerer plugins for adopsjon, spoer “leverer det en MCP-server” slik du pleide aa spoerre “har det en REST API”. MCP-spoersmaalet er ekvivalenten i 2026.

For den nordiske leseren: vurder konkret hvordan MCP komponerer mot Visma-, Tripletex- eller PowerOffice-stacken kunden din allerede kjoerer. Et WooCommerce-butikk som naa eksponerer ordre-, kunde- og lager-tools via MCP, lar agenten i ett kall sammenstille omsetning, bokfoert resultat i Tripletex og lagernivaa i Pacsoft, uten at noen mellomvare-jobb noensinne ble bygget. Det er den nordiske komposisjonsfordelen. Den finnes ikke hvis pluginet bare har en chatboks.

Hvis du er en wppoland-kunde som vurderer hvor du skal investere engineering-innsats i 2026: dette er hvor vi foreslaar aa investere. Vi bygger egne Claude Skills og MCP-servere for B2B-team som kjoerer agent-foerste workflows paa WordPress. Leveransen er MCP-serveren, domene-tools, kontrakten og teamets onboarding. Leveransen er ikke en chatboks.

#Sluttargument

Metorik-datapunktet fra mai 2026 og open-source-utgivelsen av Block MCP er det samme signalet paa ulike skalaer. Pluginet som eksponerer sine domeneoperasjoner som MCP-tools komponerer med hvilken agent kunden enn adopterer. Pluginet som ikke gjoer det blir kannibalisert paa commodity-laget og forblir usynlig paa domenelaget.

Det er et lite operativt vindu i 2026 til aa levere MCP foer markedet forventer at hvert plugin har det. Pluginforfattere som griper etter MCP-flaten i aar er de som vil staa paa agent-integratorens allow-liste naar markedet tar igjen.

#Kilder

• Bryce Adams paa WP Product Talk (transkript via WP Product Talk)
• Dokumentasjon for Metorik MCP-integrasjon
• GravityKit Block MCP open-source-utgivelse
• Anthropic Model Context Protocol
• Crocoblock JetEngine 8-aars retrospektiv og MCP Command Center

#Relatert hos oss

• Pillar: Konsulent for AI-implementering
• MCP-server-utvikling
• WordPress 7.0 funksjoner: AI-infrastruktur og Abilities API-oppsummering
• Tech Radar: Anthropic MCP (Adopt)
• Tech Radar: WordPress Abilities API (Trial)
• Tech Radar: wp-agentic-admin (Assess)

Sist verifisert: 2026-05-23