MCP-Server für WooCommerce aufbauen: ein Praktiker-Leitfaden

#MCP-Server für WooCommerce aufbauen: ein Praktiker-Leitfaden

Model Context Protocol gibt einem KI-Agenten eine typisierte, introspektierbare Oberfläche, um auf einen Shop zu wirken. WooCommerce stellt unter /wp-json/wc/v3/ bereits eine REST-API bereit. MCP davorzusetzen verwandelt diese REST-Oberfläche in etwas, das ein LLM aufrufen kann, ohne Parameternamen zu raten. Genau diese Architektur liefere ich für Kunden aus dem deutschsprachigen Raum aus, die ihren Katalog und ihre Bestellabsicht aus Claude, ChatGPT oder einer eigenen Agenten-Runtime erreichbar machen möchten.

Dieser Artikel verankert sich am MCP-Server-Entwicklungsservice und am Universal-Commerce-Protocol-Pillar.

#TL;DR

• MCP sitzt vor der WooCommerce-REST als typisierte JSON-RPC-Oberfläche.
• Drei Tools decken die meisten Agenten-Anliegen: catalogue.list, product.detail, order.intent.
• Zod-Schemata definieren jeden Input und Output und laufen bei jedem Aufruf.
• Mappen Sie WooCommerce-Felder auf schema.org Product und Offer, damit Agenten-Antworten über Oberflächen hinweg konsistent bleiben.
• Cloudflare Workers ist mein Default-Deployment-Ziel für leselastige MCP-Server.

#Was ist das Model Context Protocol

Anthropic hat Model Context Protocol am 25. November 2024 angekündigt (anthropic.com/news/model-context-protocol). Es ist ein offenes Protokoll auf JSON-RPC-2.0-Basis, das einem Client (einem LLM-Host wie Claude Desktop, einer IDE oder einer eigenen Agenten-Runtime) erlaubt, mit einem Server (Ihrer MCP-Implementierung) über stdio oder Streamable HTTP zu sprechen. Streamable HTTP hat in der Spezifikationsversion 2025-03-26 das ältere HTTP mit Server-Sent Events abgelöst.

Die drei Primitive sind:

• Tools. Aufrufbare Funktionen mit typisierten Inputs und Outputs. Der Agent wählt eines aus und ruft es auf.
• Resources. Lesbare Referenzen auf Dokumente oder Datensätze, die der Agent in den Kontext ziehen kann.
• Prompts. Vom Server gelieferte Prompt-Vorlagen, die der Host invocieren kann.

Für einen WooCommerce-Shop tragen Tools die Hauptlast. Katalog durchsuchen ist ein Tool-Aufruf. Produktdetail ist ein Tool-Aufruf. Eine Bestellung vorschlagen ist ein Tool-Aufruf. Resources helfen, wenn der Agent den vollständigen Text einer Rückgabebedingung oder eine lange Produktbeschreibung braucht; Prompts helfen, wenn voreingestellte Interaktionen ausgeliefert werden sollen (“empfehle drei Produkte für dieses Kundenprofil”).

#Was die MCP-Spezifikation 2026-07-28 für einen WooCommerce-Server ändert

Die aktuelle Revision der Spezifikation trägt das Datum 28. Juli 2026 (Changelog). Für einen Server vor einem Shop zählen vier Änderungen.

Das Protokoll hat keine Sessions mehr. Der initialize-Handshake fällt weg, im Streamable-HTTP-Transport auch der Header Mcp-Session-Id. Jede Anfrage trägt ihre Protokollversion und die Client-Fähigkeiten in _meta. Ein Worker, der für jede Anfrage einen frischen Server baut, passt zu diesem Modell, weil zwischen zwei Aufrufen kein Verbindungszustand erhalten bleiben muss.

Zustand reist als Argument. Braucht ein Server Zustand über mehrere Aufrufe, empfiehlt die Spezifikation, ein explizites Handle aus einem Erzeugungs-Tool zurückzugeben und es bei späteren Aufrufen als Argument anzunehmen (Tools mit Zustand). Ihr eigenes Beispiel ist ein Warenkorb mit basket_id. Der Entwurf, den order.intent zurückgibt, folgt genau diesem Muster: Die Entwurfs-ID ist das Handle. Derselbe Abschnitt verlangt, die Berechtigung des Aufrufers bei jedem Aufruf gegen das Handle zu prüfen, die Lebensdauer in der Tool-Beschreibung zu nennen (hier 24 Stunden) und bei einem abgelaufenen oder unbekannten Handle einen Tool-Ausführungsfehler zu liefern, damit das Modell ein neues anlegt.

Der Server muss server/discover implementieren. Über diese Methode meldet er die unterstützten Protokollversionen, seine Fähigkeiten und seine Identität.

Listen lassen sich cachen. Ergebnisse von tools/list tragen jetzt ttlMs und cacheScope, und der Server soll die Tools in deterministischer Reihenfolge liefern. Fünf Tools, die sich nur mit einem Deploy ändern, vertragen ein langes ttlMs.

Der HTTP+SSE-Transport gilt seit Version 2025-03-26 als veraltet, neue Server nutzen Streamable HTTP. Version 2 des TypeScript-SDK bedient beide Protokollgenerationen über denselben Einstiegspunkt (Protokollversionen in der SDK-Doku). Ein Client, der noch mit initialize beginnt, funktioniert also weiter.

#Welche MCP-Tools ein WooCommerce-Shop braucht

Vor jeder Codezeile schreibe ich auf, welche Intents ein Agent gegenüber dem Shop ausdrücken können soll. Bei einem typischen WooCommerce-Build ist die Liste kurz:

1. Katalog mit Filtern durchsuchen (catalogue.list).
2. Vollständiges Produktdetail abrufen (product.detail).
3. Eine Bestellung im Auftrag eines Kunden vorschlagen, die als Entwurf zur menschlichen Bestätigung zurückkommt (order.intent).
4. Status einer bestehenden Bestellung über Bestellnummer und E-Mail abfragen (order.status).
5. Bestand für eine SKU prüfen (inventory.check).

Jedes Intent wird auf genau ein Tool abgebildet. Widerstehe der Versuchung, wc.products.get, wc.products.list, wc.orders.create als 1:1-Wrap der REST-Oberfläche zu exponieren. Dem Agenten helfen REST-Verben nicht; ihm helfen Intent-Verben.

#Wie man MCP-Tools mit Zod definiert

Das TypeScript-SDK (Paket @modelcontextprotocol/server in Version 2; Version 1 hieß @modelcontextprotocol/sdk) nutzt Zod (zod.dev) für Input- und Output-Schemata. So sieht der Vertrag für catalogue.list aus:

import { z } from "zod";

export const catalogueListInput = z.object({
  query: z.string().min(2).max(200).optional(),
  category: z.string().optional(),
  in_stock: z.boolean().optional(),
  price_min: z.number().nonnegative().optional(),
  price_max: z.number().nonnegative().optional(),
  page: z.number().int().min(1).max(100).default(1),
  per_page: z.number().int().min(1).max(50).default(12),
});

export const catalogueListOutput = z.object({
  results: z.array(
    z.object({
      sku: z.string(),
      name: z.string(),
      url: z.string().url(),
      price: z.object({
        amount: z.number().nonnegative(),
        currency: z.string().length(3),
      }),
      availability: z.enum(["InStock", "OutOfStock", "BackOrder", "PreOrder"]),
      image: z.string().url().optional(),
    })
  ),
  total: z.number().int().nonnegative(),
  page: z.number().int(),
});

Zwei Dinge sind hier entscheidend. Erstens nutzt der Output schema.org-Vokabular (InStock, OutOfStock, BackOrder, PreOrder sind direkte Werte aus ItemAvailability). Zweitens weist der Input Müll an der Protokollgrenze ab; der Handler sieht nie ein query: "" oder ein negatives price_min.

Ich deklariere jedes Tool nach demselben Muster: Input-Schema, Output-Schema, Handler. Der Handler ist ein dünner Adapter über /wp-json/wc/v3/. Zod läuft pro Aufruf zweimal: einmal auf Input, einmal auf Output. Der Output-Check fängt Handler-Bugs ab, die sonst fehlerhafte Daten an den Agenten durchreichen würden.

#Wie man MCP-Tools mit Annotationen und strukturiertem Output registriert

In Version 2 des SDK heißt das serverseitige Paket @modelcontextprotocol/server. Jedes Tool wird mit registerTool registriert, das einen Namen, eine Konfiguration und einen Handler erwartet (Tools in der SDK-Doku). Mit den Schemata von oben sieht catalogue.list so aus:

import { McpServer } from "@modelcontextprotocol/server";

export function createWooCommerceMcpServer(env: Env): McpServer {
  const server = new McpServer({ name: "woocommerce", version: "1.0.0" });

  server.registerTool(
    "catalogue.list",
    {
      title: "Browse the catalogue",
      description: "List store products with filters and pagination",
      inputSchema: catalogueListInput,
      outputSchema: catalogueListOutput,
      annotations: { readOnlyHint: true },
    },
    async (input) => {
      const output = await handleCatalogueList(input);
      return {
        content: [{ type: "text", text: JSON.stringify(output) }],
        structuredContent: output,
      };
    }
  );

  // product.detail, inventory.check, order.status, order.intent
  return server;
}

Deklariert ein Tool ein outputSchema, verpflichtet die Spezifikation den Server, structuredContent passend zu diesem Schema zu liefern, und der Client soll es validieren (Tools in der Spezifikation). Das SDK prüft das, bevor das Ergebnis den Server verlässt. Für ältere Clients empfiehlt die Spezifikation, das serialisierte JSON zusätzlich als Textblock mitzuschicken. Das ist das content im Beispiel.

Annotationen beschreiben das Verhalten des Tools. readOnlyHint sagt, dass es seine Umgebung nicht verändert. destructiveHint (Standard true) und idempotentHint (Standard false) zählen nur, wenn readOnlyHint auf false steht. openWorldHint (Standard true) gibt an, ob das Tool mit einer offenen Welt externer Entitäten interagiert. Die vier lesenden Tools tragen readOnlyHint: true. order.intent trägt readOnlyHint: false und destructiveHint: false, weil es einen Entwurf anlegt und nichts löscht. idempotentHint lasse ich auf false, weil der idempotency_key optional ist und zwei gleiche Aufrufe ohne ihn zwei Entwürfe erzeugen. Laut SDK-Doku kann ein Host ein Read-only-Tool automatisch freigeben und vor einem destruktiven nachfragen. Die Spezifikation verlangt allerdings, dass Clients Annotationen als nicht vertrauenswürdig behandeln, solange sie nicht von einem vertrauenswürdigen Server stammen. Die Prüfung des Token-Umfangs bleibt deshalb auf dem Server.

Namen mit Punkt wie catalogue.list folgen der Empfehlung der Spezifikation: 1 bis 128 Zeichen, nur ASCII-Buchstaben, Ziffern, Unterstrich, Bindestrich und Punkt. Für Fehler gibt es zwei Kanäle. Ein unbekanntes Tool oder eine fehlerhafte Anfrage ist ein Protokollfehler und läuft als JSON-RPC-Fehler. Ein Fehler der WooCommerce-API oder ein Argument außerhalb des erlaubten Bereichs ist ein Tool-Ausführungsfehler und steckt im Ergebnis, mit isError: true und einem Text, mit dem sich das Modell selbst korrigieren kann. Ein product.detail mit einer SKU, die es nicht gibt, sollte die zweite Art liefern, mit der Meldung, dass die SKU nicht existiert. Dann ändert das Modell das Argument und versucht es erneut.

#Wie man den MCP-Server mit der WooCommerce-REST-API verbindet

Der Handler für catalogue.list liest aus /wp-json/wc/v3/products:

async function handleCatalogueList(input: z.infer<typeof catalogueListInput>) {
  const params = new URLSearchParams();
  if (input.query) params.set("search", input.query);
  if (input.category) params.set("category", input.category);
  if (input.in_stock) params.set("stock_status", "instock");
  if (input.price_min !== undefined) params.set("min_price", String(input.price_min));
  if (input.price_max !== undefined) params.set("max_price", String(input.price_max));
  params.set("page", String(input.page));
  params.set("per_page", String(input.per_page));

  const response = await fetch(
    `${WC_BASE}/wp-json/wc/v3/products?${params.toString()}`,
    { headers: { Authorization: `Basic ${WC_AUTH}` } }
  );

  const products = await response.json();
  const total = Number(response.headers.get("X-WP-Total") ?? 0);

  return catalogueListOutput.parse({
    results: products.map(mapWooProductToSchemaOrg),
    total,
    page: input.page,
  });
}

Der Helper mapWooProductToSchemaOrg übersetzt WooCommerce-Feldnamen (stock_status, regular_price, permalink) in die schema.org-konforme Form aus dem Output-Schema. Field-Mapping an einer Stelle, aufgerufen aus einem Tool, aufgerufen aus einem Handler. Drift zwischen WooCommerce-Upgrades und Agenten-Vertrag fängt der Output-parse-Aufruf ab, nicht die Produktion.

Bei order.intent rufe ich aus dem Handler nie WooCommerce-Schreibendpunkte auf. Das Tool gibt einen Bestellentwurf zurück, den der Host der Nutzerin anzeigt, die Nutzerin bestätigt, und erst dann ruft ein separater authentifizierter Pfad POST /wp-json/wc/v3/orders auf. Auf Verdacht vom LLM aus zu schreiben ist der falsche Default. Ein DACH-Shop hat zudem mit der Drei-Klick-Lösung nach BGB §312j eine zusätzliche Pflicht zur Bestätigung; der Draft-Pfad spielt da sauber rein.

#Wie man WooCommerce-REST-API-Schlüssel für den MCP-Server anlegt

Der MCP-Server spricht mit WooCommerce über ein Paar REST-API-Schlüssel, den Consumer Key und das Consumer Secret. Laut offizieller Dokumentation (REST-API-Authentifizierung) legen Sie sie in den erweiterten WooCommerce-Einstellungen im Bereich REST API an (wp-admin/admin.php?page=wc-settings&tab=advanced&section=keys). Drei Eigenschaften dieser Schlüssel prägen das Serverdesign.

Jeder Schlüssel gehört zu einem WordPress-Benutzer, und Anfragen damit folgen dessen Rollen und Berechtigungen. Wird der Benutzer gelöscht, funktioniert der Schlüssel nicht mehr und geht auch nicht auf einen anderen Benutzer über. Deshalb lege ich für den MCP-Server einen eigenen technischen Benutzer an, statt den Schlüssel an das Konto einer Person zu hängen, die irgendwann das Unternehmen verlässt.

Die Zugriffsstufe ist Lesen, Schreiben oder Lesen und Schreiben. Die lesenden Tools nutzen einen Nur-Lese-Schlüssel. Den Schlüssel mit Schreibrecht kennt nur die separate Route, die die Bestellung mit POST /wp-json/wc/v3/orders bestätigt.

Über HTTPS läuft die Authentifizierung per HTTP Basic, mit dem Consumer Key als Benutzername und dem Consumer Secret als Passwort. Das ist der Header Authorization: Basic im Handler von catalogue.list.

Auch die Paginierung steht in der Dokumentation (Paginierung). Standardmäßig liefert die API 10 Einträge pro Seite, per_page und page ändern das, und die Header X-WP-Total und X-WP-TotalPages enthalten die Gesamtzahl der Ressourcen und Seiten. Der Handler liest X-WP-Total, um total zu füllen.

Zwei Details des Produkt-Endpunkts (alle Produkte auflisten) wirken sich auf das Schema aus. Der Parameter category filtert nach der Kategorie-ID, nicht nach dem Slug. Der Agent braucht also IDs, oder der Server übersetzt den Slug vor dem Aufruf. Und stock_status akzeptiert instock, outofstock und onbackorder. Für den dritten Wert hat schema.org BackOrder, deshalb enthält das Output-Enum von catalogue.list diesen Wert. Ohne ihn würde ein Produkt im Rückstand an der Output-Validierung scheitern.

Aktualisierung, 23. Oktober 2026: WooCommerce hat am 21. Oktober angekündigt, dass Version 11.3 den eigenen MCP-Endpunkt /wp-json/woocommerce/mcp entfernt, zusammen mit dem Header X-MCP-API-Key, über den er sich mit einem REST-API-Schlüssel authentifizierte. Der Server aus dieser Anleitung nutzt diesen Endpunkt nicht. Er ruft /wp-json/wc/v3/ mit Consumer-Schlüsseln auf, und dieser Pfad bleibt. Haben Sie zusätzlich einen MCP-Client mit dem eingebauten Endpunkt verbunden, stellen Sie ihn vor dem Update um: Installieren Sie das Plugin MCP Adapter, legen Sie ein Anwendungspasswort für einen Benutzer an, der nur die Rechte hat, die der Client braucht, und richten Sie den Client auf /wp-json/mcp/mcp-adapter-default-server aus. Das Muster mit externem Server lässt sich auf einen Shopify-Shop oder ein Headless-Backend übertragen, weil sich nur die Handler ändern, die den Shop abfragen.

Aktualisierung, 24. Oktober 2026: WooCommerce 11.3 bringt außerdem eine experimentelle API für erweiterbare Abilities (WooCommerce-Entwicklerblog, 22. Oktober 2026). Erweiterungen können eigene Felder, Abfragefilter und Validatoren an die Abilities für Produkte, Bestellungen und Bestellpositionen hängen, sodass ein Agent die Daten der Erweiterung über die Abilities liest und ändert, die er ohnehin aufruft. Die Funktion ist standardmäßig aus, wird unter WooCommerce > Settings > Advanced > Features im experimentellen Bereich eingeschaltet, und WooCommerce bittet darum, sie noch nicht in Produktion zu nutzen. Für einen externen Server wie diesen ändert sich nichts. Relevant wird es, wenn Daten von Erweiterungen, etwa eigene Produktfelder, über den Adapter bei Agenten ankommen sollen.

#WooCommerce-Felder auf schema.org mappen

Zwei Gründe, Tool-Outputs am schema.org-Vokabular auszurichten:

Agenten benutzen dieselben Wörter über Quellen hinweg. Wenn ein Agent “ist dieses Produkt verfügbar?” beantwortet, näht er eine Product-Entität aus Ihrem MCP-Server, ein Offer mit availability und gegebenenfalls eine Review zusammen. Liefert Ihr MCP-Server { "stock": "ja" } und die andere Quelle availability: "https://schema.org/InStock", muss der Agent zwei Vokabulare versöhnen. Mit schema.org-Ausrichtung auf Ihrer Seite muss er das nicht.

Die strukturierten Daten Ihres Shops sprechen ohnehin schema.org. Ihr /wp-content/themes/<theme>/single-product.php (oder das Headless-Pendant) gibt Product-JSON-LD aus. Wenn der MCP-Output dieselbe Form behält, liefert dieselbe Produktseite dieselben Daten an einen Google-Crawler, einen OpenAI-Crawler über die URL und einen Agenten, der Ihr MCP-Tool direkt aufruft.

Das Mapping für ein typisches WooCommerce-Produkt sieht so aus:

Variationen brauchen eine zusätzliche Schicht (hasVariant-Array von Product), die Grundform bleibt aber gleich.

#Wie man Bestellungen im MCP-Server idempotent macht

Lese-Tools (catalogue.list, product.detail, inventory.check, order.status) sind natürlich idempotent. Drei Aufrufe liefern dieselbe Antwort.

order.intent ist die Falle. Der Agent kann zweimal aufrufen, wenn das Netz zwischen Antwort und Host kurz wackelt. Der Vertrag, den ich ausliefere:

• order.intent akzeptiert einen optionalen idempotency_key (eine vom Host gelieferte UUID).
• Der Handler speichert den Schlüssel in Workers KV mit 24-Stunden-TTL zusammen mit der ID des erzeugten Bestellentwurfs.
• Ein Wiederholungsaufruf mit demselben Schlüssel liefert denselben Entwurf zurück, statt einen neuen zu erzeugen.

Dieses Muster entspricht der Idempotenz-Behandlung von Stripe bei POST /v1/charges. Es ist gut verstanden; Agenten und Menschen profitieren gleichermaßen.

#Wie man den MCP-Server auf Cloudflare Workers deployt

Version 2 des TypeScript-SDK exportiert createMcpHandler. Die Funktion liefert ein { fetch }-Objekt in genau der Form, die Cloudflare Workers als Default-Export erwartet, und bedient den Streamable-HTTP-Transport (Web-Standard-Runtimes in der SDK-Doku). Der Worker-Einstieg sieht so aus:

import {
  createMcpHandler,
  hostHeaderValidationResponse,
  originValidationResponse,
} from "@modelcontextprotocol/server";

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const rejected =
      hostHeaderValidationResponse(request, [env.MCP_HOSTNAME]) ??
      originValidationResponse(request, [env.SHOP_HOSTNAME]);
    if (rejected) return rejected;

    const authInfo = await verifyAgentToken(request, env);
    if (!authInfo) {
      return new Response("Unauthorized", { status: 401 });
    }

    const handler = createMcpHandler(() => createWooCommerceMcpServer(env));
    return handler.fetch(request, { authInfo });
  },
};

verifyAgentToken prüft gegen scoped Tokens in Workers KV und gibt die Token-Daten zurück, die Handler als ctx.http.authInfo lesen. Read-only-Tools laufen mit einem weniger privilegierten Token; order.intent verlangt ein Token mit Umfang orders:write. Die Auth-Strategie ist eines der beiden Muster aus dem Leitfaden zu MCP-Authentifizierungsmustern.

wrangler.toml deklariert die WordPress-Origin-URL, den WooCommerce-Consumer-Key und das Secret (als Worker-Secrets, niemals im Code) und den KV-Namespace für Idempotenz. Deployen via wrangler deploy. Der Worker bleibt klein, weil er nur JSON-RPC-Routing plus REST-Adapter ist.

#Wie man den MCP-Endpunkt mit OAuth und Origin-Prüfung absichert

Autorisierung ist in MCP optional. Unterstützt eine HTTP-basierte Implementierung sie, soll sie der Autorisierungsspezifikation folgen (Autorisierung). Ein stdio-Server soll ihr dagegen nicht folgen und bezieht seine Zugangsdaten aus der Umgebung. Diese Regeln betreffen den Worker.

Der MCP-Server agiert als OAuth-2.1-Resource-Server und muss Protected Resource Metadata nach RFC 9728 veröffentlichen, damit der Client herausfindet, welcher Autorisierungsserver seine Tokens ausstellt.

Er muss prüfen, dass das Token für ihn als Zielgruppe (Audience) ausgestellt wurde, wie in RFC 8707 definiert. Ein ungültiges oder abgelaufenes Token bekommt HTTP 401.

Er darf kein anderes Token annehmen oder weiterreichen. Für einen Shop heißt das: Das Token des Agenten erreicht /wp-json/wc/v3/ nie. Zu WooCommerce gehen nur die REST-API-Schlüssel, die als Worker-Secrets hinterlegt sind.

Der Transport bringt eine weitere Pflicht mit (Streamable HTTP). Der Server muss den Header Origin bei allen eingehenden Verbindungen prüfen, um DNS-Rebinding-Angriffe zu verhindern, und mit 403 antworten, wenn der Header vorhanden und ungültig ist. createMcpHandler macht diese Prüfung nicht selbst. Die SDK-Doku empfiehlt, hostHeaderValidationResponse und originValidationResponse davorzuschalten, und genau das tut der Worker oben. Eine Anfrage ohne Origin-Header besteht diese Prüfung, das Token bleibt also die wichtigste Schranke.

Eine weitere Transportänderung hilft beim Logging im nächsten Abschnitt. Jeder POST trägt die Header Mcp-Method und Mcp-Name, und bei tools/call steht in Mcp-Name der Tool-Name. Ein Proxy oder der Worker selbst kann also festhalten, welches Tool aufgerufen wurde, ohne den JSON-Body zu parsen.

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. Der Worker aus dieser Anleitung läuft außerhalb von WordPress und erreicht den Shop nur mit seinen REST-API-Schlüsseln, eine WordPress-Rolle öffnet also keines seiner Tools. Geschützt wird er durch die oben beschriebenen Prüfungen von Token und Origin-Header.

#Wie man MCP-Tool-Aufrufe loggt und überwacht

Jeder Tool-Aufruf wird geloggt mit:

• Tool-Name.
• Einem SHA-256-Hash des Inputs (nicht der Input selbst; PII-Risiko nach DSGVO Art. 32).
• Latenz.
• Ob die Output-Validierung bestanden oder gescheitert ist.
• Umfang des Agenten-Tokens.

Die Logs gehen via Cloudflare Logpush in einen Langzeit-Store. Zwei operative Gewohnheiten, die das ermöglicht:

Schema-Verschärfung. Sechs Wochen nach Launch sehe ich die Validierungsfehler durch. Jeder Output-Fehler ist ein Handler-Bug oder ein nicht gemapptes WooCommerce-Feld. Jeder Input-Fehler ist entweder ein fehlerhafter Agent oder ein zu strenges Schema. Beides wandert in den nächsten Release.

Kostenzuordnung. Tool-Aufrufe sind abrechenbare Last auf dem WooCommerce-Origin. Das Log zeigt, welches Agenten-Token welche Last und welches Tool erzeugt. Ein einzelner fehlverhaltender Agent, der auf catalogue.list looped, ist eine Log-Abfrage von der Identifizierung entfernt.

#Weitere Leitfäden zu MCP und WooCommerce

Dieser Artikel ist der Implementierungs-Durchstich. Für ausfallsichere ERP-Synchronisation, Redis-Warteschlangen und Datenbank-Locking-Muster hinter WooCommerce siehe unseren WooCommerce ERP Integration Architecture Guide 2026. Für die Tiefe zu typisierten Tools siehe typisierte Katalog-Tools mit Zod für MCP. Für die Auth-Muster siehe MCP-Authentifizierungsmuster: OAuth, Tokens und wann was. Für die Protokoll-Entscheidung zwischen MCP und REST siehe MCP vs REST: wann was gewinnt für KI-Agenten-Integration. Für den Migrationspfad von einer bestehenden API siehe bestehende WordPress-API auf MCP migrieren: 4-Wochen-Playbook. Der Pillar ist MCP-Server-Entwicklung, die übergeordnete Strategie liegt unter Universal Commerce Protocol.

Preisgestaltung individuell, weil der Umfang davon abhängt, wie viele Tools Sie brauchen, wie komplex die WooCommerce-Erweiterungen sind und welche Agenten-Runtimes Sie unterstützen wollen.