wp-mcp-gateway (Cloudflare Workers-Version)

Gleiche Idee wie die Node-Version: ein MCP-Endpunkt, jeder Tool-Aufruf nimmt eine site_id entgegen, sodass ein Claude-Connector Ihre gesamte WordPress-Flotte abdeckt. Diese Version läuft auf Cloudflare Workers statt auf einem VPS — kein Server, der gepatcht werden muss, das kostenlose Kontingent reicht dafür bequem aus, und sie ist innerhalb weniger Minuten nach wrangler deploy unter einer workers.dev-URL live.

Es basiert auf dem aktuell von Cloudflare empfohlenen Ansatz: ein zustandsloser createMcpHandler aus dem agents-SDK (der ältere zustandsbehaftete McpAgent-/Durable-Objects-Ansatz ist für neue Server veraltet — dieses Gateway braucht ohnehin keinen Sitzungszustand, da jeder Tool-Aufruf unabhängig ist).

Vor der Übergabe lokal Ende-zu-Ende verifiziert: Worker startet, /health antwortet, der MCP-initialize-Handshake funktioniert, die Bearer-Token-Authentifizierung lehnt fehlende/falsche Token korrekt ab und erlaubt das richtige, und list_sites liefert echte Daten aus einem Test-SITES_JSON.

1. Voraussetzungen

npm install -g wrangler   # or just use npx wrangler as shown below
wrangler login            # opens a browser to authenticate with your Cloudflare account

Wenn Sie noch kein Cloudflare-Konto haben, registrieren Sie sich kostenlos unter https://dash.cloudflare.com/sign-up — das kostenlose Kontingent (100.000 Anfragen/Tag) ist dafür mehr als ausreichend.

2. Abhängigkeiten installieren

cd wp-mcp-gateway-cf
npm install

3. Sites konfigurieren

Anders als bei der Node-Version haben Worker kein Dateisystem, daher lebt die Site-Registry in einem Secret (SITES_JSON) statt in einer Datei. Gleiche Form wie zuvor — ein Eintrag pro Site:

{
  "town-green": {
    "label": "Town Green",
    "baseUrl": "https://town-green.org",
    "username": "mcp-agent",
    "appPassword": "xxxx xxxx xxxx xxxx xxxx xxxx",
    "host": "wpengine"
  },
  "cra": {
    "label": "CRA",
    "baseUrl": "https://cra.com",
    "username": "mcp-agent",
    "appPassword": "xxxx xxxx xxxx xxxx xxxx xxxx",
    "host": "gridpane"
  }
}

Erstellen Sie dieses JSON für alle Ihre Sites (ein Tabellenkalkulation-zu-JSON-Skript ist schnell zusammengestellt, sobald Sie für jede Site Application Passwords generiert haben — fragen Sie, wenn Sie eines möchten), und setzen Sie es dann als Secret:

npx wrangler secret put SITES_JSON
# paste the whole JSON blob when prompted, then press Ctrl+D

Application Passwords: in wp-admin unter Users → your user → Application Passwords. Gleiche Empfehlung wie zuvor — verwenden Sie pro Site einen dedizierten WP-Benutzer mit niedrigen Rechten anstelle Ihres persönlichen Admin-Kontos, sodass ein geleaktes Token nicht mehr kann, als diese Rolle erlaubt.

4. Gateway-Auth-Token festlegen

npx wrangler secret put GATEWAY_TOKEN
# paste a long random value, e.g. output of: openssl rand -hex 32

Ohne diese Einstellung läuft der Endpunkt ohne Authentifizierung — für einen ersten lokalen Test in Ordnung, aber niemals für die bereitgestellte Version.

5. Lokal testen

npx wrangler dev

Dies startet einen lokalen Entwicklungsserver (Standard http://localhost:8787). Für lokale Tests legen Sie Ihre Secrets stattdessen in einer .dev.vars-Datei ab (committen Sie sie niemals):

GATEWAY_TOKEN=some-local-test-token
SITES_JSON={"town-green":{"label":"Town Green","baseUrl":"https://town-green.org","username":"mcp-agent","appPassword":"xxxx"}}

Prüfen Sie, ob er erreichbar ist:

curl http://localhost:8787/health

6. Bereitstellen

npx wrangler deploy

Wrangler gibt Ihre Live-URL aus, zum Beispiel:

https://wp-mcp-gateway.<your-subdomain>.workers.dev

Ihr MCP-Endpunkt ist https://wp-mcp-gateway.<your-subdomain>.workers.dev/mcp.

7. Als Connector in Claude hinzufügen

Fügen Sie einen benutzerdefinierten Connector hinzu, der auf diese /mcp-URL zeigt, mit Header Authorization: Bearer <GATEWAY_TOKEN> (derselbe Wert, den Sie in Schritt 4 festgelegt haben).

Ab dann muss Claude für „list draft posts on cra.com" nur noch list_sites aufrufen (oder die ID bereits kennen) und dann list_posts mit site_id: "cra" — gleiches Verhalten wie die Node-Version, nur Edge-gehostet.

Sites später aktualisieren

Fügen Sie eine neue Site hinzu oder ändern Sie Anmeldedaten, indem Sie Folgendes erneut ausführen:

npx wrangler secret put SITES_JSON

Kein erneutes Bereitstellen nötig — Secrets werden unabhängig vom Worker-Code aktualisiert.

Hinweise zu dieser Bereitstellung

• Kein Dateisystem, kein langlebiger Prozess — die gesamte Registry lebt im SITES_JSON-Secret und wird bei jeder Anfrage neu geparst. Auch bei ~80 Sites vernachlässigbare Kosten.

• Von Natur aus zustandslos — jede MCP-Anfrage erzeugt eine neue Serverinstanz (gemäß Cloudflares aktueller Empfehlung); es gibt keine Sitzung über mehrere Anfragen hinweg, die verloren gehen könnte.

• WAF-Flags auf verwalteten Hosts — gleicher Hinweis wie bei der Node-Version: Insbesondere WP Engine kann Datenverkehr aus einem unbekannten IP-Bereich, der die REST-API aufruft, markieren. Wenn eine Site nur dann 403 zurückgibt, wenn sie über dieses Gateway aufgerufen wird, ist das das Erste, was Sie mit dem WP-Engine-Support prüfen sollten — die Egress-IP-Bereiche von Cloudflare bei Bedarf in die Whitelist aufzunehmen, ist sinnvoll.

• Umfang der Tools — dies spricht nur mit der Kern-WP-REST-API (/wp/v2/...). Keine WP-CLI-, SSH- oder Datenbankoperationen — Worker können ohnehin kein ausgehendes SSH, also bräuchte es eine völlig andere Komponente, falls Sie es später benötigen.

Sicherheitscheckliste vor dem Verbinden von Claude mit der bereitgestellten URL

• GATEWAY_TOKEN über wrangler secret put gesetzt, lang und zufällig

• SITES_JSON verwendet pro Site einen dedizierten WP-Benutzer mit niedrigen Rechten

• .dev.vars (falls Sie lokal eines verwendet haben) befindet sich in .gitignore und wurde nie committet

• Sie haben gegen 2–3 Sites getestet, bevor Sie das Secret auf alle ~80 ausweiten