MCP-Anbindung für WordPress: Drei Versuche, eine Erkenntnis, ein funktionierender Stack

Rund um das Model Context Protocol (MCP) hat sich in den letzten Monaten ein kleines Ökosystem zusammengefunden. MCP ist der offene Standard, über den KI-Assistenten wie Claude mit externen Werkzeugen sprechen – standardisiert, typisiert, mit sauberem Tool-Discovery. Aus einem aktuellen Kundenprojekt kam die Anforderung: Die KI soll direkt auf einem self-hosted WordPress Beiträge anlegen können. Recherche, Strukturierung und Formulierung im Chat – dann ein Klick, und der Draft liegt im Backend. Idealerweise auch aus Cowork heraus, nicht nur aus Claude Desktop.

Klingt simpel. War es nicht. Drei Plugin-Wege, eine wichtige Erkenntnis und am Ende ein Stack, mit dem es läuft. Hier die Recherche-Notizen.

Versuch 1: claudeus-wp-mcp

Erster Kandidat war claudeus-wp-mcp – ein npm-basierter MCP-Server, der per Application Password gegen die WordPress REST API spricht. 145 Tools, kein zusätzliches WP-Plugin nötig, alles über npx. Klingt ideal: schmal, sauber, gut dokumentiert.

Funktioniert auch – nur eben ausschließlich in Claude Desktop. Was an dieser Stelle noch nicht klar war: Das ist ein lokaler stdio-MCP-Server, eingetragen in claude_desktop_config.json. Cowork und claude.ai im Browser können damit nichts anfangen. Mehr dazu gleich.

Versuch 2: AI Engine

Zweite Spur: das AI Engine Plugin von Meow Apps. Anderer Ansatz – Plugin auf WordPress-Seite, das einen MCP-Endpunkt über Server-Sent Events bereitstellt. Ein kleines Bridge-Script mcp.js macht den Rest. Charmant, weil das Plugin auch Theme-Operationen kann, inklusive Forks.

Aber: Beta. Der Autor selbst schreibt offen, dass es eine ganze Reihe Stolperdrähte gibt – SSL, Caching, Cloudflare, SSE-Quirks. Jede SSE-Verbindung bindet einen PHP-Worker dauerhaft. Und selbe Limitation wie oben: lokaler Bridge, kein Cowork.

Die Erkenntnis: Cowork ist eine andere Welt

An dieser Stelle drängte sich die unangenehme Wahrheit auf: Cowork und claude.ai können lokale MCP-Server gar nicht erst nutzen. Die brauchen sogenannte Remote MCP Connectors, die Anthropic von ihrer Cloud aus kontaktiert. Authentifizierung: OAuth 2.1 mit Dynamic Client Registration.

Self-hosted WordPress hat (Stand Mai 2026) noch keine OAuth-2.1-Implementierung für MCP. WordPress.com hat sie, aber für Installationen auf eigenem Server fällt das raus. Heißt: Für den Cowork-Anteil des Wunschtraums heißt es warten, bis Automattic OAuth für den self-hosted Fall nachliefert. Ist roadmapped, kein Datum bekannt.

Pragmatischer Workaround für jetzt: Recherche und Schreiben in Cowork, das endgültige Anlegen auf der WordPress-Site dann in einer Claude-Desktop-Session. Ein Copy-Paste mehr. Verkraftbar.

Was funktioniert: der Automattic-Stack

Was am Ende läuft, sind drei Komponenten, die zusammen ein sauberes Bild ergeben:

• WordPress/mcp-adapter – das offizielle WordPress-Plugin, das die Abilities API auf das MCP-Protokoll abbildet. Selbst kein Tool-Pack, nur das Framework.
• Enable Abilities for MCP – ein zweites Plugin (im offiziellen Repo), das 42 fertige Abilities mitbringt: Posts, Pages, Categories, Tags, Media, Custom Post Types, SEO via Rank Math, optional WooCommerce. Mit Admin-UI zum granularen An- und Ausschalten.
• @automattic/mcp-wordpress-remote – ein lokaler Bridge-Proxy auf dem Mac, der Claudes stdio-MCP-Calls in HTTP-Requests gegen die Site übersetzt.

Authentifizierung läuft über WordPress Application Passwords. Kein zusätzliches Token-System, kein Custom-Auth-Code. Sauber.

Setup in vier Schritten

1. Dedizierter WordPress-User

Nicht der Admin. Ein neuer User namens claude-mcp, Rolle Autor (oder Redakteur, je nachdem wie viel Spielraum man geben will). Unter Profil → Anwendungspasswörter ein neues Passwort generieren, sicher ablegen.

Schöner Nebeneffekt: WordPress’ eigenes Capability-System wird damit zur Sicherheitsschicht. Wenn die KI versucht, etwas Admin-Spezifisches abzurufen (z. B. core/get-site-info), kommt sauber ein Permission denied zurück. Es muss kein Custom-Auth-Filter erfunden werden, das ist alles schon da.

2. Plugins installieren

Der MCP Adapter ist (noch) nicht im offiziellen Plugin-Repo. Per SSH auf den Server, dann:

cd /var/www/site/wp-content/plugins/
git clone https://github.com/WordPress/mcp-adapter.git
cd mcp-adapter
composer install --no-dev

Enable Abilities for MCP dagegen liegt direkt im WordPress-Repo – Standard-Installation über WP-Admin → Plugins → Hinzufügen. Beide Plugins aktivieren.

Wichtig: WordPress 6.9 oder neuer. Die Abilities API ist seit 6.9 in Core, das Plugin braucht sie. Auf 6.8 zusätzlich das abilities-api Polyfill-Plugin.

3. Bridge-Proxy in Claude Desktop einrichten

In ~/Library/Application Support/Claude/claude_desktop_config.json einen Eintrag ergänzen. Wenn der mcpServers-Block schon existiert, dort einhängen, nicht daneben:

{
  "mcpServers": {
    "kunden-wp": {
      "command": "npx",
      "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
      "env": {
        "WP_API_URL": "https://kundensite.de/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "claude-mcp",
        "WP_API_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx",
        "OAUTH_ENABLED": "false"
      }
    }
  }
}

Drei Stolperfallen, die Zeit gekostet haben:

• Die WP_API_URL muss die volle Server-URL sein, nicht nur die Domain. Die Bare-Domain-Variante ist eine Rückwärtskompatibilität für das alte (deprecated) wordpress-mcp Plugin.
• OAUTH_ENABLED: "false" spart beim Start ein paar Sekunden, weil der Proxy sonst zuerst OAuth-Discovery versucht und dann auf Application Password zurückfällt.
• Node mindestens Version 22. Wer nvm nutzt: nvm alias default 22, dann Claude Desktop neu starten. GUI-Apps lesen die Default-Version beim Launch.

4. Claude Desktop neu starten

Komplett beenden mit Cmd+Q, neu starten. Beim ersten Start zieht npx das Bridge-Paket einmalig (rund eine Megabyte). Dann erscheint im Werkzeug-Symbol unten der neue Server, und mit ihm die drei Adapter-Tools discover-abilities, get-ability-info und execute-ability.

Was geht damit

Die mitgelieferten Abilities decken den typischen Content-Workflow ab: Posts und Pages anlegen, lesen, aktualisieren, löschen; Kategorien und Tags verwalten; Bilder per URL in die Mediathek laden; Kommentare moderieren; Custom Post Types ansprechen; SEO-Metadaten setzen, falls Rank Math installiert ist.

In der Praxis sieht der Workflow so aus: Beitrag im Chat erarbeiten, am Ende „Leg das als Draft an, Titel …, Tags …“. Claude schickt das Gutenberg-Markup direkt durch, der Draft erscheint im Backend mit den richtigen Tags. Dann gegenlesen, korrigieren, manuell veröffentlichen. Sinnvolle Default-Policy: immer Draft, nie direkt publish. Das Vier-Augen-Prinzip soll bleiben.

Stolperfalle: Bilder hochladen

Eine Sache fällt im Praxisbetrieb sofort auf: Die upload-image-Ability erwartet eine URL, keinen direkten File-Upload. Wer also ein Bild aus dem Chat in die Mediathek bringen will (etwa eine selbst erstellte Schema-Grafik oder ein generiertes Cover), braucht einen kurzen Zwischenstop bei einem File-Hoster.

Klingt trivial, war es nicht. Die klassischen Anlaufstellen für anonyme File-Uploads – 0x0.st, transfer.sh, catbox.moe – haben in den letzten Monaten reihenweise dichtgemacht oder ihre Schreib-API für Non-Browser-Clients abgeschaltet. Begründung in fast allen Fällen: KI-Botnet-Spam. Was am Tag des Tests noch funktionierte: tmpfiles.org, mit 24-Stunden-TTL und ohne Account.

Für Kundenprojekte keine ideale Lösung – fremde Infrastruktur, keine Verfügbarkeitsgarantien, DSGVO-mäßig auf eigenes Risiko. Sauberer ist eine selbstgehostete Variante: ein kleines Tool wie Jirafeau auf einem eigenen Server (z. B. via Cloudron als One-Click-Install). Curl-API, einstellbare TTL, optional API-Key. Für Setups, in denen die KI regelmäßig Bilder oder Dateien zur Site hochladen soll, eine lohnenswerte Fünf-Minuten-Investition.

Was lernt man daraus

Drei Sachen.

Erstens: Die Trennung lokaler vs. remote MCP ist wichtiger als gedacht. Wer Cowork-Kompatibilität will, muss bei self-hosted WordPress aktuell warten. Wer in Claude Desktop arbeitet, hat freie Auswahl.

Zweitens: Der Automattic-Stack mit dem mcp-adapter wirkt zukunftssicherer als die Alternativen. Die Architektur (Abilities API als zentrale Registry, Adapter als Protokoll-Übersetzer, Plugins liefern die Abilities) ist sauber gedacht. Wenn OAuth 2.1 nachkommt, ändert sich am Setup nichts – nur der Connector wandert in die claude.ai-Settings.

Drittens: WordPress’ eigenes Rollen-System ist die richtige Sicherheitsschicht. Ein dedizierter Autor-User reicht, um den Aktionsradius sinnvoll zu begrenzen, ohne dass eigene Auth-Logik nötig wird. Bei Bedarf das Application Password jederzeit revoken – fertig.