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

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

Zwei Datenpunkte aus einer Woche, Mai 2026.

Bryce Adams, Gründer 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 zehnjährigen Erfahrung. Gleiches Gespräch, 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-Fälle (Basisreports, einfache Dashboards) übernimmt und die analytische Kernarbeit unberührt lässt.

GravityKit hat diese Woche Block MCP als Open Source veröffentlicht. 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 Blöcken verwendet, und strukturierten Inhalt in einen Classic-Block kollabieren. Sie sind auf dem eigenen Auftritt oft genug auf den Bug gestoßen, 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 schließt 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-Fälle übernimmt. GravityKit Block MCP: Open Source, behebt den Bug der Block-Trenner-Entfernung über 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 können. Die tiefe Domain-Schicht des Plugins (eigene Attribution, Kohortenmathematik, Integrations-Plumbing) überlebt, 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 über 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-Fläche separat von der Plugin-UI-Version.

#Das natürliche Experiment, das Adams geführt hat

Adams sagte bei WP Product Talk, er sei aus demselben Grund nervös wegen KI, aus dem jeder Plugin-Autor 2026 nervös 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 verließen, 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 befürchtete, und genau nichts an der Spitze.

Das ist ein natürliches Experiment, weil Adams es nicht entworfen hat. Es geschah ihm, während sich der Markt verschob. Die Daten sagen Ihnen, welche Funktionen, die Metorik bietet, Commodity sind (an die KI gegangen), und welche dauerhaft sind (Metorik behält den Kunden). Adams nannte als Anwendungsfälle 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 benötigen, gegen die spezifische Datenform, die das Produkt sich über 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 für 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 früher 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 lässt

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 zählt, ist, dass es den Ausfallmodus jedes vorherigen WordPress-MCP-Versuchs identifiziert.

Bestehende WordPress-MCP-Server (und es gibt mehrere) schreiben über 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 zurückschreibt, überleben die Block-Trenner-Kommentare nur, wenn der Agent von ihnen weiß. Die meisten Agenten wissen das nicht. Der HTML-Round-Trip entfernt die Trenner. Der Beitrag, der ein strukturierter Stack aus zwanzig Blöcken 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 gestoßen. Jeder, der versucht hat, einen Agenten für die Inhaltsbearbeitung gegen die WordPress-REST-API zu bauen, ist auf ihn gestoßen.

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 über 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 Fläche. Block MCP ist der erste WordPress-MCP-Server, der auf der Domain-Schicht arbeitet (Blöcke 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 Absätzen

Das Model Context Protocol ist ein offener Standard von Anthropic dafür, 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 für Eingaben und einer Implementierung), und jeder MCP-fähige 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). Für ein WordPress-Plugin ist der lokale Fall die richtige Form: der Server läuft 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 früher durch Klicken durch fünf Admin-Bildschirme getan hat.

Auf unserem Tech Radar sitzt das Anthropic Model Context Protocol im Adopt-Ring, WordPress Abilities API in Trial (die kanonische Integrationsfläche in WordPress 7.0 und neuer), und wir haben kürzlich wp-agentic-admin (CloudFest Hackathon 2026) in Assess als Referenzimplementierung des Musters hinzugefügt.

#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 dünne Schicht aus Grundfunktionen (CSV-Export, einfache Diagramme, Vorschläge zur Inhalts-Umschreibung) ein und fügen entweder eine Chatbox hinzu oder gar kein MCP. Beide Spalten sind Sackgassen. Die Chatbox trainiert Nutzergewohnheiten gegen die Commodity-Fläche 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 für Agent-Workflows. Mit MCP komponieren sie in Agent-Workflows und werden zur unverzichtbaren Installation.

Die interessante Frage für 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 auswählen, 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 Qualität. Eine kurze Liste bedeutsamer Operationen macht den Agenten nützlich.

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 Häufigkeit.
2. Gruppieren Sie sie in Cluster verwandter Aktionen. Für Metorik könnte ein Cluster “Abfragen zur Werbeattribution” sein, ein anderer “Kohortensegmentierung”.
3. Definieren Sie für jedes Cluster ein einzelnes MCP-Tool, das die Parameter des Clusters nimmt und das Ergebnis des Clusters zurückgibt. 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 einabsätzige Beschreibung im MCP-Server. Die Beschreibung ist, was der Agent liest, um zu entscheiden, wann er es benutzt. Optimieren Sie für das Lesen des Agenten, nicht für die Vollständigkeit der Dokumentation für Menschen.

Ein Plugin-Autor, der dem folgt, bekommt eine MCP-Fläche mit fünf bis sieben Tools, jedes bedeutsam, jedes für gehaltene Kunden relevant. Der Agent liest die Beschreibungen und wählt korrekt. Der tägliche Workflow des Kunden enthält jetzt die Domain-Operationen des Plugins als Anfragen in natürlicher Sprache.

#Der Vertrag lebt im Repository

Das ist der Teil des Arguments, den die meisten Plugin-Autoren übersehen, wenn sie zuerst nach “fügen 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 ändert (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 über 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 über einen mehrjährigen 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 Fläche 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 vollständig auf dem Gerät des Nutzers läuft 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 für den Single-Tenant-, Hobbyisten- oder datenschutzparanoiden WordPress-Admin, der seinen eigenen Auftritt ohne externe Abhängigkeit triagieren will. Es ist nicht die dauerhafte Antwort für Plugins, die B2B-Teams bedienen, die bereits Claude Enterprise, ChatGPT Enterprise oder self-hosted Agent-Stacks über alle ihre internen Workflows hinweg betreiben.

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

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

#Was das für 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 hinzufügen. Wenn Sie nur eines tun können, tun Sie den MCP-Server.

Wenn Sie einen WordPress-Auftritt im Maßstab betreiben (Multi-Site, Agentur, Enterprise): wenn Sie Plugins zur Adoption evaluieren, fragen Sie “liefert es einen MCP-Server” so, wie Sie früher gefragt haben “hat es eine REST API”. Die MCP-Frage ist das 2026-Äquivalent.

Konkretes Bild für 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 überhaupt auf das Feature-Sheet schaut. Die Berliner und Münchner WordPress-Meetups haben das Thema seit dem Frühjahr 2026 in jeder Sitzung. Die DACH-MCP-Welle ist nicht hypothetisch, sie hängt am Einkauf, nicht an der Engineering-Abteilung. Ergänzend lohnt der Blick auf Yoast SEO und WP-Rocket: beide Plugin-Hersteller mit überproportionalem Anteil am deutschen Markt sind im Frühjahr 2026 öffentlich dabei, MCP-Flächen zu evaluieren, weil ihre DACH-Agentur-Kunden danach gefragt haben. Wer als Plugin-Autor jetzt drei bis sieben Domain-Operationen sauber bereitstellt, sitzt in zwölf Monaten in den Empfehlungslisten der dortigen Beschaffungsteams, weil der DACH-Einkauf weniger experimentell ist als der amerikanische und Listen einmal etabliert lange hält.

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 für 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.

#Schließendes 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-Fläche 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