Warum ein MCP-Server in Ihrem WordPress-Plugin der KI-Schritt ist, der ueberlebt

#Warum ein MCP-Server in Ihrem WordPress-Plugin der KI-Schritt ist, der ueberlebt

Zwei Datenpunkte aus einer Woche, Mai 2026.

Bryce Adams, Gruender von Metorik, bei WP Product Talk: die neue MCP-Integration des Unternehmens zog binnen Tagen nach einem leisen Preview-Start 500 Nutzer an, die schnellste Annahme eines Features in seiner zehnjaehrigen Erfahrung. Gleiches Gespraech, gleicher Adams: Kunden, die Metorik verlassen, haben einen durchschnittlichen MRR von 40 Prozent niedriger als jene, die bleiben. Er las das so, dass die KI die Commodity-Faelle (Basisreports, einfache Dashboards) uebernimmt und die analytische Kernarbeit unberuehrt laesst.

GravityKit hat diese Woche Block MCP als Open Source veroeffentlicht. Es ist ein WordPress-MCP-Server, der auf Block-Ebene arbeitet, statt Beitragsinhalt als einzelnen HTML-String zu behandeln. Das Team baute ihn, weil bestehende REST-API-basierte MCP-Server die Block-Trenner entfernen, die WordPress zur Identifikation von Bloecken verwendet, und strukturierten Inhalt in einen Classic-Block kollabieren. Sie sind auf dem eigenen Auftritt oft genug auf den Bug gestossen, um sich zu einem Fix zu verpflichten.

Das sind nicht zwei Geschichten. Das ist eine Geschichte. 2026 ist das WordPress-Plugin, das einen MCP-Server ausliefert, das Plugin, das zusammengesetzt wird. Das Plugin, das eine Chatbox an seine Administration klebt, ist das Plugin, das kannibalisiert wird.

Dieser Beitrag ist die Fortsetzung unseres Pillars zur KI-Implementierung und schliesst direkt an unsere Arbeit zur MCP-Server-Entwicklung und an die Integration der Abilities API in WordPress 7.0 an. Das Argument hier ist kommerziell, nicht nur technisch.

#TL;DR

• Zwei Datenpunkte vom Mai 2026 sagen dasselbe. Metorik MCP: 500 Nutzer in Tagen, schnellste Annahme in zehn Jahren. Adams: MRR der Abwanderer 40 Prozent unter den Gehaltenen, was nahelegt, dass die KI Commodity-Faelle uebernimmt. GravityKit Block MCP: Open Source, behebt den Bug der Block-Trenner-Entfernung ueber die REST API.
• Ein MCP-Server stellt die Domain-Operationen des Plugins als agentenrufbare Tools bereit, die in den Agenten der Wahl des Nutzers eingebunden werden. Eine im Plugin-Admin eingesperrte Chatbox komponiert nur mit sich selbst.
• Die Commodity-Schicht des Plugins (Reports, Dashboards, Diagrammvarianten) wird durch generische KI-Werkzeuge kannibalisiert, die dieselben Fragen aus Rohdaten beantworten koennen. Die tiefe Domain-Schicht des Plugins (eigene Attribution, Kohortenmathematik, Integrations-Plumbing) ueberlebt, weil die KI den Domain-Kontext nicht hat, solange das Plugin ihn nicht via MCP gibt.
• Der Vertrag des MCP-Servers lebt im Plugin-Repository. Dieser Vertrag ist stabil ueber Model-Releases hinweg. Eine auf das Verhalten eines bestimmten Modell-Anbieters trainierte Chatbox verschiebt sich unter dem Maintainer alle sechs Wochen.
• Aktion: Liefern Sie einen MCP-Server, stellen Sie drei bis sieben Domain-Operationen als Tools bereit, dokumentieren Sie den Vertrag im Repo, versionieren Sie die MCP-Flaeche separat von der Plugin-UI-Version.

#Das natuerliche Experiment, das Adams gefuehrt hat

Adams sagte bei WP Product Talk, er sei aus demselben Grund nervoes wegen KI, aus dem jeder Plugin-Autor 2026 nervoes ist: der Boden der Wertpyramide (Basisreports, einfache Aggregationen) ist genau dort, wo die KI am schnellsten beim Kopieren ist. Er konnte sich eine Welt vorstellen, in der Claude oder ChatGPT, auf dieselben Shopify- oder WooCommerce-Rohdaten gerichtet, dieselben Diagramme produziert, die Metorik produziert, gratis.

Was er stattdessen fand, nach einem Jahr Beobachtung, war, dass die Kunden, die Metorik verliessen, systematisch die Kunden mit niedrigem MRR waren. Durchschnittlicher MRR der Abwanderer 40 Prozent unter dem der Gehaltenen. Seine Interpretation: die KI tat genau das, was er am Boden der Pyramide befuerchtete, und genau nichts an der Spitze.

Das ist ein natuerliches Experiment, weil Adams es nicht entworfen hat. Es geschah ihm, waehrend sich der Markt verschob. Die Daten sagen Ihnen, welche Funktionen, die Metorik bietet, Commodity sind (an die KI gegangen), und welche dauerhaft sind (Metorik behaelt den Kunden). Adams nannte als Anwendungsfaelle gehaltener Kunden: Attribution von Werbeausgaben, Kohortenmathematik, eigene Segmentierung, Integration mit Lager- und Fulfilment-APIs, Multi-Store-Aggregation. Das sind keine Diagrammfunktionen. Das sind Domain-Operationen, die die spezifische Implementierung von Metorik benoetigen, gegen die spezifische Datenform, die das Produkt sich ueber ein Jahrzehnt verdient hat.

Dann kam die MCP-Integration, und 500 gehaltene Kunden griffen in der ersten Woche danach.

Die MCP-Integration ist kein neues Produktfeature. Sie ist ein Weg fuer den Agenten des Kunden (Claude Desktop, Claude Code, ChatGPT Enterprise, einen eigenen internen Stack), dieselben Domain-Operationen der gehaltenen Kunden als Tools aufzurufen. Der Kunde macht jetzt in seinem Agenten das, was er frueher durch Anmelden bei Metorik getan hat. Metorik hat sie nicht verloren, es wurde unsichtbare Installation unter ihrem Agenten-Workflow.

Das ist der Burggraben.

#Warum Block MCP mehr bedeutet, als seine Plugin-Form vermuten laesst

Block MCP von GravityKit ist technisch ein kleines Plugin. Ein WordPress-MCP-Server, der die Bearbeitung auf Block-Ebene als Tools bereitstellt. Der Grund, warum es zaehlt, ist, dass es den Ausfallmodus jedes vorherigen WordPress-MCP-Versuchs identifiziert.

Bestehende WordPress-MCP-Server (und es gibt mehrere) schreiben ueber die WordPress-REST-API. Die REST-API behandelt content als einzelnen HTML-String. WordPress nutzt intern HTML-Kommentare als Block-Trenner (<!-- wp:paragraph -->, <!-- wp:image {...} -->). Wenn der Agent den Inhalts-String bearbeitet und zurueckschreibt, ueberleben die Block-Trenner-Kommentare nur, wenn der Agent von ihnen weiss. Die meisten Agenten wissen das nicht. Der HTML-Round-Trip entfernt die Trenner. Der Beitrag, der ein strukturierter Stack aus zwanzig Bloecken war, wird beim Speichern zu einem einzelnen Classic-Block.

Das ist nicht hypothetisch. Casey Burridge, strategischer Ops-Manager bei GravityKit, sagte, das Team sei wiederholt auf dem eigenen Auftritt auf den Bug gestossen. Jeder, der versucht hat, einen Agenten fuer die Inhaltsbearbeitung gegen die WordPress-REST-API zu bauen, ist auf ihn gestossen.

Block MCP behebt den Ausfallmodus, indem er Operationen auf Block-Ebene als MCP-Tools bereitstellt. add_block, update_block, move_block, delete_block statt get_content plus set_content. Der Agent sieht den Beitrag als Baum, nicht als String. Der Vertrag ist stabil ueber WordPress-Block-Updates hinweg, weil der Vertrag im MCP-Server definiert ist, nicht in welchem HTML-Serialisierer auch immer der WordPress-Core heute ausliefert.

Der tiefere Punkt: der Unterschied zwischen “MCP um REST gewickelt” und “MCP um die Domain herum entworfen” ist der Unterschied zwischen Commodity-Werkzeug und einer dauerhaften Flaeche. Block MCP ist der erste WordPress-MCP-Server, der auf der Domain-Schicht arbeitet (Bloecke sind das Domain-Primitiv von WordPress-Inhalt), nicht auf der API-Transportschicht.

Das ist das Muster. Jeder Plugin-Autor sollte fragen: was ist das Domain-Primitiv meines Plugins, und stellt mein MCP-Server es bereit, oder stellt er einen umwickelten REST-Endpunkt bereit?

#Was ein MCP-Server ist, in zwei Absaetzen

Das Model Context Protocol ist ein offener Standard von Anthropic dafuer, wie KI-Agenten Tools entdecken und aufrufen. Ein MCP-Server stellt eine Liste von Tools bereit (jedes mit einem Namen, einer Beschreibung, einer JSON schema fuer Eingaben und einer Implementierung), und jeder MCP-faehige Agent (Claude Desktop, Claude Code, ChatGPT Enterprise, eigene Stacks) kann sich verbinden, die Tools entdecken und sie aufrufen. Der Server kann lokal sein (stdio) oder remote (SSE / HTTP). Fuer ein WordPress-Plugin ist der lokale Fall die richtige Form: der Server laeuft neben dem Plugin, der Agent verbindet sich vom Rechner des Nutzers.

Der Plugin-Autor definiert die Tools. Das ist der ganze Punkt. Die Tools sind die Domain-Operationen des Plugins, benannt im Vokabular des Plugins, mit Input-Schemas, die das Datenmodell des Plugins widerspiegeln. Der Agent arbeitet jetzt auf der Domain-Wissensebene des Plugins. Der Kunde macht im Chat das, was er frueher durch Klicken durch fuenf Admin-Bildschirme getan hat.

Auf unserem Tech Radar sitzt das Anthropic Model Context Protocol im Adopt-Ring, WordPress Abilities API in Trial (die kanonische Integrationsflaeche in WordPress 7.0 und neuer), und wir haben kuerzlich wp-agentic-admin (CloudFest Hackathon 2026) in Assess als Referenzimplementierung des Musters hinzugefuegt.

#Die zwei-mal-zwei-Matrix

Das WordPress-Plugin 2026 lebt in einer zwei-mal-zwei-Matrix:

Das Quadranten der flachen Domain (obere Zeile) ist, wo die meisten “WordPress-KI-Plugin”-Launches sitzen. Sie wickeln eine duenne Schicht aus Grundfunktionen (CSV-Export, einfache Diagramme, Vorschlaege zur Inhalts-Umschreibung) ein und fuegen entweder eine Chatbox hinzu oder gar kein MCP. Beide Spalten sind Sackgassen. Die Chatbox trainiert Nutzergewohnheiten gegen die Commodity-Flaeche des Plugins, und der MCP-Server hat nichts Differenziertes bereitzustellen.

Der Quadranten der tiefen Domain (untere Zeile) ist, wo die dauerhaften Plugins leben. Metorik, JetEngine von Crocoblock, GravityForms, GravityView von GravityKit sind jeweils Beispiele. Ohne MCP halten diese Plugins Kunden, werden aber unsichtbar fuer Agent-Workflows. Mit MCP komponieren sie in Agent-Workflows und werden zur unverzichtbaren Installation.

Die interessante Frage fuer einen Plugin-Autor in diesem Quadranten lautet nicht “sollten wir MCP ausliefern” (ja), sondern “welche drei bis sieben Operationen sind die richtigen zur Bereitstellung”.

#Die Operationen auswaehlen, die bereitgestellt werden

Plugin-Autoren wollen oft jeden CRUD-Endpunkt als MCP-Tools bereitstellen. Das ist falsch. Der Punkt von MCP ist nicht API-Zugriff, sondern Operationen auf Domain-Ebene. Eine lange Liste trivialer Tools verwirrt den Agenten und produziert Aufrufe niedriger Qualitaet. Eine kurze Liste bedeutsamer Operationen macht den Agenten nuetzlich.

Die Heuristik, die wir verwenden:

1. Listen Sie die Aktionen auf, die ein Kunde in Ihrem Plugin in einer typischen Woche unternimmt. Sortieren Sie nach Haeufigkeit.
2. Gruppieren Sie sie in Cluster verwandter Aktionen. Fuer Metorik koennte ein Cluster “Abfragen zur Werbeattribution” sein, ein anderer “Kohortensegmentierung”.
3. Definieren Sie fuer jedes Cluster ein einzelnes MCP-Tool, das die Parameter des Clusters nimmt und das Ergebnis des Clusters zurueckgibt. Das Tool ist die Domain-Operation, nicht der API-Endpunkt.
4. Begrenzen Sie die Liste auf sieben. Wenn Sie mehr als sieben haben, haben Sie das Clustering nicht abgeschlossen.
5. Jedes Tool bekommt eine einabsaetzige Beschreibung im MCP-Server. Die Beschreibung ist, was der Agent liest, um zu entscheiden, wann er es benutzt. Optimieren Sie fuer das Lesen des Agenten, nicht fuer die Vollstaendigkeit der Dokumentation fuer Menschen.

Ein Plugin-Autor, der dem folgt, bekommt eine MCP-Flaeche mit fuenf bis sieben Tools, jedes bedeutsam, jedes fuer gehaltene Kunden relevant. Der Agent liest die Beschreibungen und waehlt korrekt. Der taegliche Workflow des Kunden enthaelt jetzt die Domain-Operationen des Plugins als Anfragen in natuerlicher Sprache.

#Der Vertrag lebt im Repository

Das ist der Teil des Arguments, den die meisten Plugin-Autoren uebersehen, wenn sie zuerst nach “fuegen wir Claude zu unserer Administration hinzu” greifen.

Eine in den Plugin-Admin geklebte Chatbox hat einen Vertrag, der im Prompt, der Systemmeldung und der Tool-Calling-Schicht der Chatbox lebt. Wenn der zugrundeliegende Modell-Anbieter das Function-Calling-Format aendert (das ist in den letzten 18 Monaten dreimal bei Anthropic, OpenAI und Google passiert), bricht die Chatbox, bis der Maintainer den Wrapper aktualisiert. Der Vertrag der Chatbox ist nicht dauerhaft. Sein Lebenszyklus ist die API des Modell-Anbieters.

Der Vertrag eines MCP-Servers lebt im Plugin-Repository als JSON schema pro Tool. Der Vertrag ist stabil ueber Model-Releases hinweg. Wenn Anthropic das Tool-Calling von Claude aktualisiert, aktualisiert sich der Agent, nicht der MCP-Server. Wenn OpenAI eine neue Function-Calling-Form ausliefert, funktioniert derselbe MCP-Server weiter, weil MCP der Standard ist, an den sich der Modell-Anbieter anpasst. Der Plugin-Autor schreibt die Tools einmal und liefert sie aus.

Das ist die dauerhafte technische Form. Die Chatbox ist die wegwerfbare.

Der Kunde bemerkt das ueber einen mehrjaehrigen Zeitraum. Die Chatbox, die 2025 funktionierte, brach 2026 zweimal. Der MCP-Server, der 2025 ausgeliefert wurde, funktioniert 2026 noch mit dem aktuellen Agenten der Wahl des Kunden. Der Kunde vertraut dem Plugin, das die dauerhafte Flaeche ausliefert.

#Gegenposition: was ist mit wp-agentic-admin?

Ein Leser, der sich das Projekt CloudFest Hackathon 2026 wp-agentic-admin ansieht, wird ein anderes Modell sehen: ein In-Browser-WebLLM (Qwen 1.7B oder 7B via WebGPU), das vollstaendig auf dem Geraet des Nutzers laeuft und die WordPress Abilities API durch eine ReAct-Schleife aufruft. Local-first, ohne API-Kosten, ohne entferntes Modell.

Dieses Modell hat einen Platz. Es ist eine gute Passung fuer den Single-Tenant-, Hobbyisten- oder datenschutzparanoiden WordPress-Admin, der seinen eigenen Auftritt ohne externe Abhaengigkeit triagieren will. Es ist nicht die dauerhafte Antwort fuer Plugins, die B2B-Teams bedienen, die bereits Claude Enterprise, ChatGPT Enterprise oder self-hosted Agent-Stacks ueber alle ihre internen Workflows hinweg betreiben.

Fuer diese Teams ist der Agent, mit dem sie mit dem WordPress-Plugin reden wollen, derselbe Agent, den sie fuer ihr CRM, ihr Data Warehouse, ihren Issue Tracker und ihre Docs nutzen. Der MCP-Server ist das, was das Plugin fuer diesen Agenten verfuegbar macht. Das In-Browser-WebLLM ist ein paralleles Universum ohne kompositionelle Reichweite.

Beide Modelle sind gueltig. Das MCP-Server-Muster ist das, das sich daran ausrichtet, wie B2B-Kundenteams bereits arbeiten.

#Was das fuer die wppoland-Leserschaft bedeutet

Wenn Sie ein WordPress- oder WooCommerce-Plugin ausliefern: bauen Sie den MCP-Server. Drei bis sieben Domain-Operationen, als Tools bereitgestellt, Vertrag im Repository, separat von der Plugin-UI-Version versioniert. Tun Sie das, bevor Sie eine Chatbox hinzufuegen. Wenn Sie nur eines tun koennen, tun Sie den MCP-Server.

Wenn Sie einen WordPress-Auftritt im Massstab betreiben (Multi-Site, Agentur, Enterprise): wenn Sie Plugins zur Adoption evaluieren, fragen Sie “liefert es einen MCP-Server” so, wie Sie frueher gefragt haben “hat es eine REST API”. Die MCP-Frage ist das 2026-Aequivalent.

Konkretes Bild fuer den DACH-Markt: der B2B-WordPress-Plugin-Markt im deutschsprachigen Raum ist materiell dichter als der globale Durchschnitt. Mittwald, Raidboxes und Kinsta-DACH bedienen Kunden, die Anthropic Enterprise oder Microsoft 365 Copilot bereits unternehmensweit einsetzen. Wenn das Plugin-Repository keinen MCP-Server hat, taucht das Plugin im internen Self-Service-Katalog des Kunden gar nicht auf, weil der KI-Verantwortliche im Einkauf nach “spricht es MCP” filtert, bevor er ueberhaupt auf das Feature-Sheet schaut. Die Berliner und Muenchner WordPress-Meetups haben das Thema seit dem Fruehjahr 2026 in jeder Sitzung. Die DACH-MCP-Welle ist nicht hypothetisch, sie haengt am Einkauf, nicht an der Engineering-Abteilung. Ergaenzend lohnt der Blick auf Yoast SEO und WP-Rocket: beide Plugin-Hersteller mit ueberproportionalem Anteil am deutschen Markt sind im Fruehjahr 2026 oeffentlich dabei, MCP-Flaechen zu evaluieren, weil ihre DACH-Agentur-Kunden danach gefragt haben. Wer als Plugin-Autor jetzt drei bis sieben Domain-Operationen sauber bereitstellt, sitzt in zwoelf Monaten in den Empfehlungslisten der dortigen Beschaffungsteams, weil der DACH-Einkauf weniger experimentell ist als der amerikanische und Listen einmal etabliert lange haelt.

Wenn Sie ein wppoland-Kunde sind und 2026 evaluieren, wo Sie Engineering-Aufwand investieren: hier schlagen wir vor zu investieren. Wir bauen eigene Claude Skills und MCP-Server fuer B2B-Teams, die Agent-first-Workflows auf WordPress betreiben. Das Deliverable ist der MCP-Server, die Domain-Tools, der Vertrag und das Onboarding des Teams. Das Deliverable ist keine Chatbox.

#Schliessendes Argument

Der Metorik-Datenpunkt vom Mai 2026 und das Open-Source-Release von Block MCP sind dasselbe Signal auf unterschiedlichen Skalen. Das Plugin, das seine Domain-Operationen als MCP-Tools bereitstellt, komponiert mit dem Agenten, den sein Kunde adoptiert. Das Plugin, das das nicht tut, wird auf der Commodity-Schicht kannibalisiert und bleibt auf der Domain-Schicht unsichtbar.

Es gibt 2026 ein kleines operatives Fenster, MCP auszuliefern, bevor der Markt erwartet, dass jedes Plugin es hat. Plugin-Autoren, die dieses Jahr nach der MCP-Flaeche greifen, sind die, die auf der Allow-Liste des Agent-Integrators sein werden, wenn der Markt aufholt.

#Quellen

• Bryce Adams bei WP Product Talk (Transkript via WP Product Talk)
• Dokumentation der Metorik-MCP-Integration
• Open-Source-Release von GravityKit Block MCP
• Anthropic Model Context Protocol
• Crocoblock JetEngine 8-Jahre-Retrospektive und MCP Command Center

#Verwandte Texte bei uns

• Pillar: Beratung zur KI-Implementierung
• MCP-Server-Entwicklung
• WordPress 7.0 Features: KI-Infrastruktur und Abilities API Zusammenfassung
• Tech Radar: Anthropic MCP (Adopt)
• Tech Radar: WordPress Abilities API (Trial)
• Tech Radar: wp-agentic-admin (Assess)

Zuletzt geprueft: 2026-05-23