Bestehende WordPress-API auf MCP migrieren: ein Vier-Wochen-Plan

#Bestehende WordPress-API auf MCP migrieren: ein Vier-Wochen-Plan

Ein sauberer Neuprojekt-MCP-Build ist überschaubar. Eine Migration von einer bestehenden, funktionierenden WordPress-REST-API, während sie weiter Produktionsverkehr bedient, ist die schwerere Form. Dieses Playbook ist das, was ich nutze, um von “wir haben /wp-json/ und einen Partnerkonsumenten” zu “wir haben /wp-json/, diesen Partner und einen LLM-freundlichen MCP-Server davor” zu kommen, ohne etwas zu brechen.

Dieser Artikel verankert sich am Pillar MCP-Server-Entwicklungsservice.

#TL;DR

• Vier Wochen: Audit, Scaffold, Parallelbetrieb, Umstellung.
• REST bleibt für bestehende Konsumenten live; MCP ist ein Zusatz, kein Ersatz.
• Zod-Schemata kommen aus dem REST-Audit, nicht aus einer Wunschliste.
• Parallelbetrieb mit einem internen Agenten, bevor externer Verkehr MCP berührt.
• Logpush erfasst jeden Tool-Aufruf; Mismatches zwischen MCP- und REST-Antworten tauchen als Schema-Fehler auf.

#Wie auditiert man REST-API-Endpunkte in WordPress

Das Audit ist eine Tabelle. Eine Zeile pro Endpunkt, die Spalten:

Für einen typischen WooCommerce-Shop hat die Tabelle 20 bis 60 Zeilen. Die meisten mappen sauber auf MCP-Tools; eine Handvoll (Admin-Internas, plugin-spezifische Endpunkte, Webhook-Empfänger) bleibt REST-only.

Output von Woche 1 sind zwei Artefakte:

1. Das vorgeschlagene Tool-Inventar: catalogue.list, product.detail, order.intent, order.status, inventory.check, plus was für Ihren Build spezifisch ist.
2. Erste Zod-Schema-Entwürfe für jeden Tool-Input und -Output, abgeleitet aus den realen REST-Antworten, die Sie im Audit erfasst haben.

REST-Antworten erfasse ich mit curl plus jq für die Form-Inspektion oder einer Postman-Sammlung, die das Team teilt. Ziel ist empirische Wahrheit, nicht was die README sagt. WordPress-Plugins fügen berüchtigterweise Felder hinzu, die die Doku nie erwähnt; das Audit fängt sie.

#Wie setzt man einen MCP-Server auf Cloudflare Workers auf

Das Lieferergebnis von Woche 2 ist ein lauffähiger MCP-Server, deployed in eine Nicht-Produktions-Cloudflare-Workers-Umgebung, mit dem Tool-Inventar aus Woche 1 als dünne Adapter über den bestehenden REST-Endpunkten.

Das Server-Skelett:

import { createMcpHandler, hostHeaderValidationResponse, McpServer } from "@modelcontextprotocol/server";
import { catalogueListInput, catalogueListOutput, handleCatalogueList } from "./tools/catalogue-list.js";
import { productDetailInput, productDetailOutput, handleProductDetail } from "./tools/product-detail.js";
// ... ein Import pro Tool

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // Requests mit fremdem Host-Header abweisen (Schutz vor DNS-Rebinding)
    const rejected = hostHeaderValidationResponse(request, [env.MCP_HOSTNAME]);
    if (rejected) return rejected;

    const handler = createMcpHandler(() => {
      const server = new McpServer({ name: "wppoland-mcp", version: "0.1.0" });

      server.registerTool(
        "catalogue.list",
        {
          description: "List WooCommerce products with filters",
          inputSchema: catalogueListInput,
          outputSchema: catalogueListOutput,
          annotations: { readOnlyHint: true },
        },
        (input) => handleCatalogueList(input, env),
      );

      server.registerTool(
        "product.detail",
        {
          description: "Return one product by SKU",
          inputSchema: productDetailInput,
          outputSchema: productDetailOutput,
          annotations: { readOnlyHint: true },
        },
        (input) => handleProductDetail(input, env),
      );

      // ... ein registerTool()-Aufruf pro Tool

      return server;
    });

    return handler.fetch(request);
  },
};

Das Gerüst folgt Version 2 des offiziellen TypeScript-SDK (@modelcontextprotocol/server), die die Spezifikationsrevision 2026-07-28 umsetzt. createMcpHandler liefert ein Objekt mit einer fetch-Methode, genau die Form, die ein Cloudflare-Workers-Modul als Default-Export erwartet, und die Factory baut für jeden Request einen frischen McpServer (SDK-Leitfaden für Web-Standard-Runtimes). Derselbe Leitfaden weist darauf hin, dass der Handler selbst weder Host noch Origin prüft; deshalb steht der Wächter davor. Projekte auf @modelcontextprotocol/sdk 1.x bekommen laut SDK-README noch mindestens sechs Monate nach dem v2-Release vom 27. Juli 2026 Bugfixes und Sicherheitsupdates. Eine Migration, die jetzt startet, sollte also auf v2 zielen.

Jeder Handler ist ein dünner Adapter. Er nimmt den validierten Input, baut einen Querystring, fetcht aus /wp-json/, mappt die Antwort in die schema.org-konforme Output-Form, ruft den Output-parse, gibt zurück. Geschäftslogik bleibt in WordPress; der Handler ist mechanische Übersetzung.

Woche 2 enthält auch das Auth-Scaffolding aus dem Leitfaden zu MCP-Authentifizierungsmustern. Für den Parallelbetrieb in Woche 3 nutze ich ein einzelnes Test-Token mit allen Scopes; Produktions-Scopes werden in Woche 4 verschärft.

Die wrangler.toml der Preview-Umgebung zeigt auf eine Staging-WordPress-Installation oder eine Kopie der Produktion. Der MCP-Server ist auf einer *.mcp-staging.wppoland.workers.dev-URL erreichbar, nur fürs Team.

#Wie testet man einen MCP-Server parallel zur REST-API

In Woche 3 tauchen Bugs auf. Das Muster:

Vergleichs-Harness bauen. Ein kleines TypeScript-Skript, das einen Tool-Namen und einen Input nimmt, den MCP-Server aufruft, dann den äquivalenten REST-Endpunkt direkt aufruft und die zwei Antworten diff’t. Das Diff wird mit Tool-Name, Input und einem JSON-Pointer-Pfad zu jedem Mismatch geloggt.

async function compareToolToRest(toolName: string, input: unknown) {
  const mcpResponse = await callMcp(toolName, input);
  const restResponse = await callEquivalentRest(toolName, input);
  const diff = jsonDiff(restResponse, mcpResponse);
  if (diff.length > 0) {
    await logMismatch({ toolName, input, diff });
  }
}

Jedes Tool gegen ein repräsentatives Input-Set fahren. Für catalogue.list: leere Query, Query mit hunderten Produkten, Query mit Kategorienfilter, Query mit Preisrange, Query ohne Treffer. Für product.detail: bekannte SKU, unbekannte SKU, SKU mit Variationen, SKU mit Custom Fields. Edge Cases aus dem Audit abdecken.

Einen internen Agenten auf den MCP-Server richten. Claude Desktop mit dem MCP-Server als Remote-Tool-Quelle ist meine Konfiguration. Eine Person aus dem Team verbringt 30 Minuten pro Tag eine Woche lang mit Interaktion mit dem eigenen Shop via Agent und hält Überraschungen in einem geteilten Doc fest.

Dieselben Testprompts auf drei Clients. Luca Rossi weist in seinem Essay How to design a good MCP server vom Oktober 2026, geschrieben zusammen mit dem Team von Manufact, darauf hin, dass derselbe Server in ChatGPT, Claude und der langen Reihe weiterer Clients zu sehr unterschiedlichen Ergebnissen führen kann. Ein kurzer fester Satz von Testprompts (golden prompts) auf einigen echten Clients gehört deshalb zur normalen Produktprüfung. Die Checkliste im Essay ergänzt eine verantwortliche Person für den Zustand des MCP-Servers, die ihn nach jedem größeren Release von MCP, Claude oder ChatGPT erneut prüft. Für dieses Playbook heißt das: Die Agenten-Sitzungen in Woche 3 laufen in Claude Desktop und in zwei weiteren Clients, die Ihre Nutzer tatsächlich verwenden, und Sie lassen das Vergleichsskript nach jeder Protokollrevision laufen, genauso wie nach einem WordPress-Update.

Schemata anhand der Rückläufe schärfen. Jeder Zod-Validierungsfehler im Log ist ein Schema-Bug oder ein Mapping-Bug. Fixen, Preview-Worker neu deployen, Harness erneut laufen lassen.

Output von Woche 3 ist eine bestandene Harness mit null Diffs und ein Tool-Inventar, das fünf Tage je 30 Minuten reale Agent-Interaktion überlebt hat. Fehlt eines davon, startet Woche 4 nicht.

#Wie bringt man einen MCP-Server in Produktion und überwacht ihn

Das Umstellung ist undramatisch, wenn Wochen 1 bis 3 sauber liefen.

Produktions-Workers deployen. wrangler deploy --env production. Der Produktions-MCP-Server zeigt auf den Produktions-WordPress-Origin, mit Produktions-Scopes auf Tokens, die über die WordPress-Admin-Oberfläche ausgegeben werden.

Tokens für die erste reale Agenten-Runtime ausgeben. Üblicherweise einer der folgenden: ein interner Agent fürs Personal, eine Partnerintegration, die eine MCP-Oberfläche angefragt hat, oder ein öffentlicher Assistent am Storefront. Mit dem kleinsten, risikoärmsten Konsumenten anfangen.

Cloudflare Logpush an einen Langzeit-Store hängen. Die Log-Felder aus dem Artikel MCP-Server für WooCommerce aufbauen sind die richtigen Defaults: Tool-Name, Input-Hash, Latenz, Validierungsergebnis, Token-Umfang. Der Store ist, was Ihr Team ohnehin nutzt (BigQuery, ClickHouse, S3 + Athena).

Watch-Dashboard einrichten. Drei Abfragen am Tag eins:

1. Tool-Aufrufe pro Minute, nach Tool-Name aufgeschlüsselt. Erkennt Burst-Last.
2. Validierungsfehler-Rate pro Tool, aufgeschlüsselt nach Code (input_invalid, output_invalid). Erkennt Regressionen.
3. Latenz p50/p95/p99 pro Tool. Erkennt vorgelagerte WordPress-Langsamkeit.

REST live lassen, unangetastet. Storefront, Partnerintegrationen, Webhook-Empfänger nutzen alle weiterhin /wp-json/ exakt wie vorher. MCP ist ein Zusatz, kein Ersatz. Die wichtigste Migrationsregel überhaupt.

#Typische Fehler bei der Migration von REST zu MCP

Sechs Dinge, die ich in echten Migrationen schiefgehen sah:

REST-Antwortfeld, das das Audit übersehen hat. Ein Plugin fügt meta_data: [...] zu Produktantworten hinzu. Das MCP-Output-Schema kennt es nicht. Der Zod-Parse scheitert auf realen Daten. Fix: Audit auf Produktionsverkehr wiederholen, Schema erweitern oder Feld mit .transform() explizit droppen.

Permalink-Mismatch zwischen Staging und Produktion. Das MCP-Tool product.detail gibt das WooCommerce-Feld permalink zurück. Staging-Permalinks sind https://staging.example.com/...; Produktions-Permalinks https://example.com/.... Testdaten gehen durch; Produktion scheitert am URL-Validator. Fix: Staging-Worker mit Permalink-Rewrite-Schritt konfigurieren, der Produktionsverhalten spiegelt.

WooCommerce-Variations-Handling. Das Audit hat die Form für einfache Produkte erfasst. Variations-Antworten sind anders (Variants-SKUs leben unter /wp-json/wc/v3/products/<id>/variations). Fix: Variations als separates Fetch in product.detail behandeln, auf schema.org hasVariant spiegeln.

Auth-Token leakt in Logs. Ein Handler loggt den vollen Authorization-Header zum Debuggen. Das Token landet im Log-Store. Fix: Header in der Log-Schicht redaktieren; jedes vor der Redaktion ausgegebene Token rotieren. Im DACH-Kontext relevant für DSGVO-konforme Protokollierung.

Plugin-Update bricht eine REST-Antwort. WooCommerce 9.x benennt ein Feld um, der MCP-Handler erwartet noch den alten Namen, der Zod-Parse scheitert. Fix: WooCommerce-Versionen im Staging pinnen, Vergleichs-Harness bei jedem WordPress-Upgrade fahren, Harness als Teil des Upgrade-Gates behandeln.

Agent looped auf einem fehlerhaften Tool-Aufruf. Ein verbuggter Agent retry’d order.intent 100-mal pro Minute, wenn der Input die Validierung nicht besteht. Ohne Rate-Limit sieht der WordPress-Origin 100 Fan-out-Aufrufe. Fix: Rate-Limit pro Principal wie im Leitfaden zu MCP-Authentifizierungsmustern dokumentiert, plus retry_after_seconds-Hinweis im Fehler-Envelope zurückgeben.

#Wie lange dauert eine WordPress-MCP-Migration

Vier Wochen sind der Default. Zwei Anpassungen:

Kleinere Oberfläche, zwei Wochen. Drei Tools, ein Konsument, keine Auth-Komplexität. Audit und Scaffold in Woche 1 kompressieren, Parallelbetrieb und Umstellung in Woche 2. Selbes Muster, kürzerer Kalender.

Größere Oberfläche, sechs Wochen. Ein Dutzend Tools, mehrere Auth-Modi, sensible mutierende Aktionen. Eine Woche zwischen Scaffold und Parallelbetrieb für Security-Review hinzu. Eine Woche zwischen Parallelbetrieb und Umstellung für Soft-Launch mit einem einzelnen OAuth-autorisierten Nutzer vor breitem Rollout.

Die vier Phasen bleiben in derselben Reihenfolge unabhängig vom Zeitbudget.

#Ändert sich WordPress durch einen MCP-Server

Lohnt es, ausdrücklich zu sagen. Nach der Migration:

• Die WordPress-Admin-UI ist unverändert.
• Der Block Editor ist unverändert.
• Das Nutzer-Authentifizierungssystem ist unverändert.
• Die bestehenden REST-Endpunkte sind unverändert und bedienen weiterhin ihre bestehenden Konsumenten.
• Die Webhook-Auslöselogik ist unverändert.
• Die Datenebene (wp_posts, wp_postmeta, WooCommerce-Tabellen) ist unverändert.

Hinzugefügt wird: ein Cloudflare-Workers-MCP-Server, eine Token-Ausgabe-UI auf der WordPress-Admin-Seite (kleines Plugin oder Theme-Funktion), eine Cloudflare-Logpush-Konfiguration. Alles andere ist unverändert.

Genau das macht die Migration risikoarm. Hat der MCP-Server einen schlechten Tag, schalten Sie den Worker ab. Die Agenten-Oberfläche geht runter. Storefront läuft weiter, Partnerintegrationen laufen weiter, Bestellungen kommen weiter rein.

#Wie man REST-Verben auf MCP-Tool-Annotationen abbildet

Die Audit-Tabelle hat bereits eine Spalte dafür, ob ein Endpunkt Zustand verändert. In MCP wird aus dieser Spalte die Tool-Annotation. Das Schema der Spezifikation 2026-07-28 definiert in ToolAnnotations vier boolesche Hinweise: readOnlyHint (Standard false), destructiveHint (Standard true), idempotentHint (Standard false) und openWorldHint (Standard true). Die Hinweise zu destruktiv und idempotent haben nur Bedeutung, wenn readOnlyHint false ist (MCP-Schema).

Eine Zuordnung, die direkt aus den Audit-Spalten folgt:

Die Standardwerte sind der Grund, die Annotationen zu setzen. Ein Tool ohne Annotationen gilt als möglicherweise destruktiv und nicht idempotent, also wirkt ein reines Katalog-Lese-Tool ohne readOnlyHint für den Client riskanter, als es ist. Der SDK-Leitfaden beschreibt die praktische Folge: Ein Host kann ein Lese-Tool automatisch freigeben und vor einem destruktiven Tool eine Bestätigung verlangen (SDK-Leitfaden zu Tools). Die Spezifikation ergänzt, dass Clients Annotationen als nicht vertrauenswürdig behandeln müssen, solange der Server nicht vertrauenswürdig ist. Annotationen ersetzen also nie die Rechteprüfung auf der WordPress-Seite.

Die Benennung kommt von derselben Spezifikationsseite: Tool-Namen sollen 1 bis 128 Zeichen lang sein, Groß- und Kleinschreibung unterscheiden und nur ASCII-Buchstaben, Ziffern, Unterstrich, Bindestrich und Punkt enthalten (MCP-Tools). catalogue.list und product.detail passen; ein Name, der samt Schrägstrichen aus einer REST-Route kopiert wurde, passt nicht.

#Wie man WordPress-REST-Fehler an einen Agenten zurückgibt

Ein Fehler der WordPress-REST-API kommt als JSON mit code, message und data.status. Die MCP-Spezifikation trennt zwei Arten von Fehlschlägen. Protokollfehler (unbekanntes Tool, fehlerhafter Request, Serverfehler) gehen als normale JSON-RPC-Fehler zurück. Fehler bei der Tool-Ausführung (API-Ausfälle, Validierungsfehler beim Input, Fehler in der Geschäftslogik) gehen im Tool-Ergebnis mit isError: true zurück, und Clients sollen sie an das Modell weitergeben, damit es den Aufruf korrigieren und erneut versuchen kann (MCP-Tools, Fehlerbehandlung).

Für einen Handler über REST heißt das: Ein 404 für eine unbekannte Produkt-ID oder ein 400 für einen ungültigen Parameter ist ein Ausführungsfehler. Geben Sie isError: true mit einem Textblock zurück, der dem Modell sagt, was es ändern soll, etwa dass kein Produkt diese SKU hat und catalogue.list gültige SKUs liefert. Nur ein Ausfall der MCP-Schicht selbst wird zum JSON-RPC-Fehler. Wer jeden 4xx von WordPress in einen JSON-RPC-Fehler verwandelt, versteckt den Grund vor dem Modell, und der Agent wiederholt blind, genau die Schleife aus der Fehlerliste weiter oben.

Dieselbe Seite legt zwei Regeln für erfolgreiche Ergebnisse fest. Deklariert ein Tool ein outputSchema, muss der Server strukturierte Ergebnisse liefern, die diesem Schema entsprechen. Ein Tool, das structuredContent liefert, soll zur Abwärtskompatibilität zusätzlich das serialisierte JSON in einem Textblock zurückgeben. Version 2 des TypeScript-SDK validiert structuredContent gegen outputSchema, bevor das Ergebnis den Server verlässt (SDK-Leitfaden zu Tools), also dieselbe Prüfung, auf die sich das Harness aus Woche 3 stützt.

#Welche Zugangsdaten der MCP-Server an WordPress schickt

In dieser Architektur treffen zwei Zugangsdaten aufeinander, und die Spezifikation hält sie getrennt. Autorisierung ist in MCP optional. Unterstützt ein Server auf einem HTTP-Transport sie, arbeitet er als OAuth-2.1-Ressourcenserver: Er muss prüfen, dass jedes Access-Token genau für ihn als Empfänger ausgestellt wurde (RFC 8707), muss ungültige oder abgelaufene Tokens mit HTTP 401 beantworten und darf keine anderen Tokens annehmen oder weiterreichen (MCP-Autorisierung). Server auf dem stdio-Transport sollen diesen Ablauf auslassen und Zugangsdaten aus der Umgebung lesen.

Für einen Worker vor /wp-json/ schließt das aus, das Token des Agenten an WordPress weiterzureichen. Das Agenten-Token endet am Worker. Der Worker ruft WordPress mit eigenen Zugangsdaten auf, meist einem Anwendungspasswort (Application Password) für einen eigenen WordPress-Benutzer, der nur die Rechte hat, die das Tool-Inventar braucht. Anwendungspasswörter gibt es in WordPress seit Version 5.6; sie werden per HTTP Basic über HTTPS gesendet (REST-API-Handbuch, Authentifizierung). Legen Sie das Passwort als Worker-Secret mit wrangler secret put ab, nicht als normale Variable in wrangler.toml (Secrets in Cloudflare Workers).

Die Trennung zahlt sich in Woche 4 aus. Eine Rotation des WordPress-Passworts berührt keine Agenten-Tokens, und der Widerruf eines Agenten-Tokens berührt WordPress nicht. Welche Rechte der eigene Benutzer bekommt, entscheidet die Spalte zur Datensensibilität aus dem Audit: Ein reines Katalog-Inventar braucht keine Rechte an Bestellungen.

#Wann der WordPress MCP Adapter der bessere Weg ist

Dieser Plan setzt MCP an den Rand des Netzes, in einen Worker. WordPress hat auch einen offiziellen Weg, der MCP in WordPress selbst unterbringt. Der MCP Adapter, Teil der Initiative AI Building Blocks for WordPress, stellt über die WordPress Abilities API registrierte Fähigkeiten (Abilities) als MCP-Tools, -Ressourcen und -Prompts bereit. Auf wordpress.org steht das Plugin bei Version 0.7.1, verlangt WordPress 6.9 und PHP 7.4 und wurde zuletzt am 16. Oktober 2026 aktualisiert (Plugin-Seite).

Was die Adapter-Dokumentation zu den Punkten sagt, die die Wahl bestimmen:

• Abilities sind standardmäßig privat. Zu MCP gelangt nur eine Ability, bei der meta.public (oder meta.mcp.public) auf true steht. In WordPress 6.9 und 7.0 steuert dieses Flag nur MCP, für REST braucht es weiterhin meta.show_in_rest; der Core wendet meta.public ab 7.1 auch auf REST an.
• Der Standardserver stellt drei Meta-Tools bereit (mcp-adapter/discover-abilities, mcp-adapter/get-ability-info, mcp-adapter/execute-ability) und antwortet per HTTP unter /wp-json/mcp/mcp-adapter-default-server.
• wp mcp-adapter serve --user=<id> stellt einen Server per stdio über WP-CLI bereit.
• Ohne eigenen Permission-Callback für den Transport lässt ein Server angemeldete Benutzer zu (is_user_logged_in()).
• Annotationen im Format der Abilities API (readonly, destructive, idempotent) werden in readOnlyHint, destructiveHint und idempotentHint umgewandelt.

Der Adapter passt, wenn die Tools WordPress-Logik sind, die schon in PHP lebt, und die Agenten-Clients die Website direkt erreichen. Der Weg über den Worker passt, wenn die MCP-Oberfläche eigene Token-Ausgabe, Limits am Rand und Logpush braucht oder auch dann antworten soll, wenn der WordPress-Origin langsam ist. Das Audit aus Woche 1 dient beiden Wegen: Jede Zeile, die auf ein Tool abgebildet wird, wird entweder ein Worker-Handler oder eine registrierte Ability.

Aktualisierung, 24. Oktober 2026: In Andy Peatlings Benchmark Building with WordPress für Oktober schlossen Opus 5.5 in Claude Code und GPT-6.1-Sol in Codex 0 von 42 Aufgaben von Website-Betreibern ab, wenn der Adapter der einzige Zugang war, und 33 von 42 mit einem Anwendungspasswort für die REST-API. Die drei Abilities von WordPress selbst lesen nur Informationen zu Website, Benutzer und Server, die einzigen Schreibzugriffe kamen über die Produkt-Abilities von WooCommerce. In Issue #402 plant Peatling experimentelle Core-Abilities in vier Etappen, um diese Lücke zu schließen. Am 21. Oktober hielt das KI-Team von WordPress die Zustimmung fest, MCP zum Teil der Standard-Erfahrung von WordPress zu machen, mit 7.3 als möglichem Ziel und ohne Zusage für ein Release (Wochenzusammenfassung). Solange die Schreib-Abilities fehlen, heißt der Weg über den Adapter, sie selbst zu schreiben, während die REST-Endpunkte aus dem Audit in Woche 1 schon funktionieren.

Aktualisierung, 24. Oktober 2026: Jedes Plugin, das MCP in WordPress bringt, schafft eigene Angriffsfläche. Wordfence veröffentlichte am 15. und 16. Oktober 2026 drei solche Einträge. AI Engine bis 3.8.3 fehlte eine Berechtigungsprüfung, sodass ein angemeldeter Mitarbeiter (Contributor) eine unerlaubte Aktion ausführen konnte (CVE-2026-110888). Das MCP-Tool wsp_get_posts in WSP MCP bis 2.9.5 ließ jeden angemeldeten Abonnenten Titel, Autoren und Auszüge von Entwürfen sowie ausstehenden und geplanten Beiträgen lesen (CVE-2026-109382). Und xSpeed Cache bis 1.4.2, ein Caching-Plugin mit MCP-Funktionen, erlaubte Mitarbeitern gespeichertes Cross-Site-Scripting (CVE-2026-109985). Keine der drei Lücken setzt ein Administratorkonto voraus. Wer Abilities in WordPress registriert, steht mit dem eigenen Code vor derselben Frage: Jede Ability braucht einen Permission-Callback, der eine konkrete Capability prüft und nicht nur, ob jemand angemeldet ist.

#Welche Version der MCP-Spezifikation man anpeilt

Die aktuelle Revision der Spezifikation ist 2026-07-28, und zwei ihrer Regeln betreffen diesen Plan. Erstens hat MCP keine Sitzung auf Protokollebene, ein Server kann sich also nicht auf Verbindungszustand stützen, um einen Tool-Aufruf mit dem nächsten zu verknüpfen. Für Zustand wie einen Warenkorb empfiehlt die Spezifikation, aus einem anlegenden Tool ein explizites Handle zurückzugeben, dieses Handle in späteren Aufrufen anzunehmen, bei jedem Aufruf die Berechtigung des Aufrufers gegen das Handle zu prüfen und die Lebensdauer des Handles in der Tool-Beschreibung zu nennen (MCP-Tools, zustandsbehaftete Tools). Bei order.intent ist die ID der Bestellabsicht dieses Handle.

Zweitens trägt jeder Request Protokollversion und Client-Fähigkeiten in _meta-Feldern im Nachrichtenrumpf, und der Streamable-HTTP-Transport spiegelt sie in HTTP-Header, damit Zwischenstationen Requests leiten können, ohne den Rumpf zu parsen (MCP-Transporte). Auf Adapter-Seite zählt wp mcp-adapter list --protocol=2026-07-28 die Komponenten, die unter dieser Revision verfügbar sind; der Adapter akzeptiert dort 2025-11-25 und 2026-07-28.

#Weitere Artikel zu MCP-Servern

Dieser Artikel deckt die Migrationsform ab. Für den Implementierungs-Durchstich siehe MCP-Server für WooCommerce aufbauen. Für die Auth-Strategie siehe MCP-Authentifizierungsmuster. Für typisiertes Tool-Design siehe typisierte Katalog-Tools mit Zod für MCP. Für die Protokoll-Entscheidung siehe MCP vs REST. Der Pillar ist MCP-Server-Entwicklung.

Preisgestaltung individuell, weil der Migrationsumfang von der Anzahl Endpunkte im Audit, der Auth-Komplexität und der Konsumentenzahl abhängt.

Auf der Delivery-Seite halten wir dieses Thema unter Next.js- oder Astro-Migration.