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 på WP Product Talk: selskapets nye MCP-integrasjon trakk 500 brukere innen dager etter en stille preview-lansering, raskere enn noen funksjon han har levert på ti år. 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-bruksområdene (grunnleggende rapporter, enkle dashboards) og lar kjerneanalysen være i fred.

GravityKit open-sourcet Block MCP denne uken. Det er en WordPress MCP-server som opererer på blokknivå, i stedet for å 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 å identifisere blokker, og kollapser strukturert innhold til en Classic-blokk. De støtte på feilen nok ganger på egen side til å 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 på admin-flaten er pluginet som blir kannibalisert.

Dette stykket er fortsettelsen av vår AI-implementering-pillar og henger direkte sammen med vårt 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 på dager, raskeste adopsjon på ti år. Adams: MRR for de som forlater er 40 prosent lavere enn de som blir, noe som tyder på 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-verktøy som kan svare på de samme spørsmålene fra rådata. 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 på tvers av modell-utgivelser. En chatboks trent mot oppførselen 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 kjørte

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

Det han fant i stedet, etter et år 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 på 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 (gått til AI) og hvilke som er holdbare (Metorik beholder kunden). Adams listet retainerte kunders bruksområder 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 tiår.

Så kom MCP-integrasjonen, og 500 retainerte kunder grep etter den i løpet av første uke.

For det nordiske leserbildet er dette uvanlig viktig. Norske B2B-team kjører typisk få, høyt tilliterte SaaS-verktøy: Visma for regnskap og lønn, Tripletex for prosjektøkonomi, og kanskje Tibber eller Otovo som forbruksflate. Når slike team nå adopterer Claude Enterprise eller ChatGPT Enterprise på tvers av selskapet, forgår integrasjonsvalget på samme akse: hvilke verktøy snakker MCP og kan kalles av agenten uten et ekstra mellomledd? Et WordPress- eller WooCommerce-plugin uten MCP-server faller utenfor det indre verktøysettet til den nordiske B2B-kjøperen. Den lokale eksporten av norsk B2B-programvare til Sverige, Danmark og Finland hviler på den samme komposisjonsmodellen, så pluginforfattere som retter seg mot dette markedet må tenke MCP før chat.

MCP-integrasjonen er ikke en ny produktfunksjon. Det er en måte for kundens agent (Claude Desktop, Claude Code, ChatGPT Enterprise, en egen intern stack) til å kalle de samme retainerte-kunde-domeneoperasjonene som tools. Kunden gjør nå i sin agent det hen pleide å gjøre ved å logge inn på Metorik. Metorik mistet dem ikke, det ble usynlig rørlegging 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 på blokknivå som tools. Grunnen til at det teller er at det identifiserer feilmønstret til hvert tidligere WordPress MCP-forsøk.

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 {...} -->). Når agenten redigerer innholds-strengen og skriver den tilbake, overlever blokk-skilletegnkommentarene bare hvis agenten kjenner til dem. De fleste agenter gjør 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 støtte gjentatte ganger på feilen på egen side. Alle som har prøvd å bygge en agent for innholdsredigering mot WordPress REST API har støtt på den.

Block MCP fikser feilmønstret ved å eksponere operasjoner på blokknivå 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 på 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-verktøy og en holdbar flate. Block MCP er den første WordPress MCP-serveren som opererer på domenelaget (blokker er domeneprimitivet i WordPress-innhold), ikke på API-transportlaget.

Dette er mønstret. Hver pluginforfatter bør spørre: 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 åpen 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 være lokal (stdio) eller ekstern (SSE / HTTP). For et WordPress-plugin er det lokale tilfellet riktig form: serveren kjører 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 nå på pluginets domenekunnskapsnivå. Kunden gjør i chat det hen pleide å gjøre ved å klikke gjennom fem admin-skjermbilder.

På vårt 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 mønstret.

#To-ganger-to-matrisen

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

Kvadranten med grunn domene (øverste 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 å 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 uunnværlig rørlegging.

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

#Å 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 på domenenivå. En lang liste trivielle tools forvirrer agenten og produserer kall av lav kvalitet. En kort liste meningsfulle operasjoner er det som gjør agenten nyttig.

Heuristikken vi bruker:

1. List opp handlingene en kunde foretar i pluginet ditt på en typisk uke. Sorter etter frekvens.
2. Grupper dem i klynger av relaterte handlinger. For Metorik kan en klynge være “annonseattribusjons-spørringer”, 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 fullført klyngingen.
5. Hver tool får en ett-avsnitts beskrivelse i MCP-serveren. Beskrivelsen er det agenten leser for å bestemme når den skal brukes. Optimaliser for agentens lesing, ikke for fullstendighet i menneskelig dokumentasjon.

En pluginforfatter som følger dette får en MCP-flate med fem til sju tools, hver meningsfull, hver retainert-kunde-relevant. Agenten leser beskrivelsene og velger riktig. Kundens daglige workflow inkluderer nå pluginets domeneoperasjoner som forespørsler i naturlig språk.

#Kontrakten lever i repoet

Dette er den delen av argumentet de fleste pluginforfattere overser når de griper etter “la oss legge til Claude i admin-flaten vår” først.

En chatboks limt på plugin-admin har en kontrakt som lever i chatboksens prompt, systemmelding og tool-kallende lag. Når den underliggende modelltilbyderen endrer function-calling-formatet (dette har skjedd tre ganger på de siste 18 månedene 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 på tvers av modell-utgivelser. Når Anthropic oppdaterer Claudes tool-calling, oppdateres agenten, ikke MCP-serveren. Når 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 flereårig horisont. Chatboksen som fungerte i 2025 brøt to ganger i 2026. MCP-serveren som ble levert i 2025 fungerer fortsatt i 2026 med kundens nåværende agentvalg. Kunden stoler på pluginet som leverer den holdbare flaten.

#Motposisjon: hva med wp-agentic-admin?

En leser som ser på prosjektet CloudFest Hackathon 2026 wp-agentic-admin vil se en annen modell: en in-browser WebLLM (Qwen 1.7B eller 7B via WebGPU) som kjører helt på 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 kjører Claude Enterprise, ChatGPT Enterprise eller self-hosted agent-stacks på 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 gjør pluginet tilgjengelig for den agenten. In-browser WebLLM er et parallelt univers uten komposisjonell rekkevidde.

Begge modeller er gyldige. MCP-server-mønstret 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. Gjør dette før du legger til en chatboks. Hvis du bare kan gjøre en ting, gjør MCP-serveren.

Hvis du driver et WordPress-område i skala (multi-site, byrå, enterprise): når du evaluerer plugins for adopsjon, spør “leverer det en MCP-server” slik du pleide å spørre “har det en REST API”. MCP-spørsmålet er ekvivalenten i 2026.

For den nordiske leseren: vurder konkret hvordan MCP komponerer mot Visma-, Tripletex- eller PowerOffice-stacken kunden din allerede kjører. Et WooCommerce-butikk som nå eksponerer ordre-, kunde- og lager-tools via MCP, lar agenten i ett kall sammenstille omsetning, bokført resultat i Tripletex og lagernivå 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 foreslår å investere. Vi bygger egne Claude Skills og MCP-servere for B2B-team som kjører agent-første workflows på 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 på ulike skalaer. Pluginet som eksponerer sine domeneoperasjoner som MCP-tools komponerer med hvilken agent kunden enn adopterer. Pluginet som ikke gjør det blir kannibalisert på commodity-laget og forblir usynlig på domenelaget.

Det er et lite operativt vindu i 2026 til å levere MCP før markedet forventer at hvert plugin har det. Pluginforfattere som griper etter MCP-flaten i år er de som vil stå på agent-integratorens allow-liste når 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