MCP vs REST: wann was gewinnt für KI-Agenten-Integration

#MCP vs REST: wann was gewinnt für KI-Agenten-Integration

MCP und REST als Alternativen zu behandeln ist der falsche Rahmen. Sie sitzen auf unterschiedlichen Schichten: REST ist Transport plus Konventionen, MCP ist ein typisiertes Protokoll für einen LLM-Konsumenten. Die echte Entscheidung lautet, mit welcher Oberfläche jeder Konsument spricht und wie sich die zwei Oberflächen einen Backend teilen. Dieser Artikel liefert das Framework, mit dem ich KI-Integrationen für WordPress- und WooCommerce-Builds scope.

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

#TL;DR

• MCP und REST sind komplementär, keine Alternativen.
• REST gewinnt für deterministische Clients mit hartcodierten Aktions-Sets und OpenAPI-Docs.
• MCP gewinnt für LLM-Agenten, die Laufzeit-Tool-Entdeckung und typisierte mutierende Envelopes brauchen.
• Produktions-Default ist REST als System of Record, MCP als agentenseitige Oberfläche davor.
• Selber Backend, zwei Oberflächen, eine Wahrheit.

#Was beide Protokolle wirklich sind

REST. Ein architektonischer Stil aus Roy Fieldings Dissertation 2000 (Quelle der Dissertation), typischerweise über HTTP mit Verben und Ressourcen-URLs ausgedrückt. WordPress exponiert eine REST-API unter /wp-json/wp/v2/ (WordPress-REST-API-Handbuch); WooCommerce erweitert sie unter /wp-json/wc/v3/. Dokumentation ist üblicherweise OpenAPI (OpenAPI-Spezifikation) und SDKs werden zur Build-Zeit aus dem Schema generiert.

MCP. Ein auf JSON-RPC 2.0 basierendes Protokoll, das Anthropic am 25. November 2024 angekündigt hat (Ankündigung von Anthropic), zur Anbindung von LLM-Hosts (Claude Desktop, IDEs, eigene Agenten-Runtimes) an Daten und Tools. Drei Primitive: tools (aufrufbare Funktionen), resources (lesbare Dokumente), prompts (vom Server gelieferte Vorlagen). Discovery passiert zur Laufzeit via tools/list; der Agent lernt die verfügbaren Fähigkeiten in jeder Session.

Aus der Distanz wirken die Formen ähnlich. Unter Last laufen sie schnell auseinander.

#Die Entscheidungsmatrix

Sechs Faktoren, die ich bewerte, bevor ich eine Oberfläche für eine bestimmte Aktion wähle:

Die Matrix sagt mir, welches Protokoll für eine Aktion vorzuziehen ist, nicht für die ganze API. Die meisten Projekte landen geteilt.

#Wo REST klar gewinnt

Ein Storefront, das eine Kategorienseite holt. Hartcodiert gegen /wp-json/wp/v2/categories?slug=widgets. Die Form ist bekannt, die Cache-Header funktionieren, das CDN cached per URL.

Eine Partner-ERP-Integration, die Inventar täglich synchronisiert. Das Partner-Team liest OpenAPI, generiert ein typisiertes SDK, plant einen Cron auf 03:00 UTC. Sie wollen stabile URLs, vorhersehbare Antwortformen und HTTP-Statuscodes. MCP würde Komplexität ohne Mehrwert hinzufügen.

Öffentlicher, anonymer Lesetraffic. Ein SEO-Crawler auf Produktseiten, ein Preisvergleich-Aggregator, der Produkt-Feeds zieht. REST plus Rate-Limiting erledigt diesen Fall mit der reifsten Infrastruktur.

Webhook-Auslieferung. WooCommerce feuert woocommerce_order_status_completed an einen Partner-Endpunkt. Der Partner-Endpunkt ist ein REST-Empfänger. MCP ist die falsche Form, weil der Agent nicht in der Schleife ist; der Empfänger ist ein deterministisches System.

#Wo MCP klar gewinnt

Ein LLM-Agent, der auf eine freie Nutzerintention reagiert. “Finde mir eine wasserdichte Jacke unter 200 Euro, die nach Berlin geliefert wird.” Der Agent weiß im Voraus nicht, welche Filterkombination greift; er muss die verfügbaren Tools introspektieren, die Beschreibungen lesen, entscheiden. REST gibt ihm 47 Query-Parameter über drei Endpunkte und kein Signal, welcher passt.

Mutierende Aktionen, bei denen Idempotenz zählt. Eine Bestellung aus einem LLM zu erzeugen ist das lauteste Beispiel. Das MCP-order.intent-Tool mit typisiertem Input-Schema und Idempotenz-Schlüssel ist ein engerer Vertrag als ein freier POST /wp-json/wc/v3/orders-Aufruf. Retries sind by design sicher, nicht per Konvention.

Eine sich häufig ändernde Tool-Oberfläche. Ein neuer Suchfilter oder ein neuer Produkttyp bedeutet, ein neues MCP-Tool mit describe-Block zu publishen; der Agent zieht es beim nächsten tools/list ohne Codeänderung agentenseitig. Bei REST ist jede Änderung ein koordinierter SDK-Release.

Mehrstufige Agenten-Workflows. “Prüfe, ob SKU AC-101 auf Lager ist; wenn nicht, schlage drei Alternativen vor; wenn vorhanden, schlage eine Bestellung vor.” Jeder Schritt ist ein Tool-Aufruf; der Agent komponiert sie. Bei REST muss der Agent die Workflow-Form in den Prompt hartcodieren.

#Wo die Grenze sitzt

Für einen typischen WooCommerce-Build ziehe ich die Grenze so:

Die Tool-Handler des MCP-Servers rufen dieselben /wp-json/wc/v3/-Endpunkte auf, die die REST-Konsumenten nutzen. Eine Wahrheit für die Datenebene, zwei Oberflächen für zwei Konsumententypen.

#Auth-Trade-offs

REST-Authentifizierung ist gut ausgetreten: Bearer-Tokens, OAuth 2.x, Basic-Auth fürs Development. Die Konvention lautet “der Token-Träger darf alles, was die Doku sagt.” Scope-Verfeinerung passiert pro Endpunkt auf Anwendungsebene.

MCP überlässt dieselben Transport-Entscheidungen, das SDK ermutigt aber, Scopes pro Tool zu taggen. Ein einzelnes OAuth-Token kann orders:read ohne orders:write tragen, und der MCP-Server erzwingt das bei jedem Tool-Aufruf. OpenAPI-Muster unterstützen dieselbe Idee via securityDefinitions und Per-Operation-Security, aber in der Praxis dokumentieren die meisten REST-APIs einen einzelnen globalen Scope und überlassen der Anwendung die feinere Granularität.

Speziell für Agenten-Integrationen ist das Per-Tool-Scope-Mapping in MCP ein echter ergonomischer Gewinn, der zudem zu DSGVO-Anforderungen an Datenminimierung passt. Der Nutzer gewährt dem Agenten orders:read; der Agent kann order.cancel schlicht nicht aufrufen, weil der MCP-Server ihn vor dem Handler-Lauf mit forbidden ablehnt. Die Auth-Oberfläche ist unter der Haube dieselbe wie bei REST, aber der Vertrag ist sowohl für Nutzer als auch für Agenten lesbarer.

#Caching

REST hat jahrzehntelange HTTP-Cache-Infrastruktur: Cache-Control-Header, ETag-Revalidierung, Vary-Regeln, CDN-Edge-Caching, Browser-Caching, Proxy-Caching. Eine GET /wp-json/wc/v3/products?stock_status=instock-Antwort mit Cache-Control: public, max-age=60 cached am Edge ohne extra Aufwand.

MCP hat davon nichts. Tool-Antworten reisen als JSON-RPC-Payloads in POST-Requests. HTTP-Cache-Header greifen nicht. Caching muss auf Anwendungsebene passieren, im Tool-Handler, gegen einen expliziten, aus dem Input abgeleiteten Schlüssel. Das ist in Ordnung, wenn die Handler des MCP-Servers selbst den vorgelagerten REST-Aufruf cachen (was ich in Produktion mache), bedeutet aber, dass die Cache-Schicht dein Problem ist.

Das ist das stärkste Argument, öffentlichen Lesetraffic auf REST zu lassen und nur Agenten-Traffic über MCP zu führen. Die HTTP-Cache-Infrastruktur ist zu wertvoll, um sie für die öffentliche Oberfläche aufzugeben.

#Das Hybrid-Muster

Die Default-Architektur, die ich für WordPress- und WooCommerce-Sites mit KI-Agenten-Ambition ausliefere:

                            ┌──────────────────┐
                            │  WordPress Core  │
                            │   + WooCommerce  │
                            │   (REST-Origin)  │
                            └────────┬─────────┘
                                     │
                    ┌────────────────┼────────────────┐
                    │                │                │
            ┌───────▼────────┐  ┌────▼─────┐  ┌──────▼──────┐
            │ Öffentliche    │  │ Webhook- │  │ MCP-Server  │
            │ REST (CDN)     │  │ Liefer.  │  │ (Workers)   │
            └───────┬────────┘  └────┬─────┘  └──────┬──────┘
                    │                │                │
            ┌───────▼────────┐  ┌────▼─────┐  ┌──────▼──────┐
            │ Storefront,    │  │ Partner- │  │  LLM-Agent  │
            │ Preis-Feeds,   │  │ Endpunkte│  │  (Claude,   │
            │ öffentl. APIs  │  │          │  │  ChatGPT,   │
            │                │  │          │  │  eigen)     │
            └────────────────┘  └──────────┘  └─────────────┘

Selber WordPress-Origin. Drei Oberflächen, drei Konsumentenprofile. Die Handler des MCP-Servers rufen dieselben REST-Endpunkte auf, die die öffentliche Oberfläche cached; die Webhook-Auslieferung teilt sich die WordPress-Event-Hooks, auf die die Invalidierungslogik des MCP-Servers hört.

Die Grenze zwischen MCP und REST ist eine Deployment-Entscheidung, keine Coding-Entscheidung. Die Datenebene (WooCommerce-Datenbank, REST-Endpunkte) wird geteilt. Die Präsentationsebene (typisierte Tools vs JSON-Ressourcen) wird gespalten.

#Häufige Fehler

MCP RESTs Job machen lassen. Öffentliche Katalogseiten über MCP zu cachen ist falsch. Nutze REST plus CDN.

REST MCPs Job machen lassen. Eine LLM-freundliche Aktionsoberfläche in OpenAPI zu dokumentieren plus zu erwarten, der Agent “kommt schon klar”, liefert brüchige Ergebnisse. Agenten kommen mit MCPs Tool-Discovery besser zurecht.

Zwei parallele Datenebenen. Wenn die MCP-Handler Geschäftslogik nachimplementieren, statt den REST-Origin zu rufen, bricht jedes WordPress-Upgrade beide Oberflächen. Datenebene in WordPress halten; Protokoll-Oberflächen dünn halten.

Den Aufwand vergessen. Ein MCP-Server ist eine weitere Deployment-Einheit, eine weitere Auth-Strategie, eine weitere zu überwachende Sache. Liefere keinen aus, wenn dein einziger Konsument eine Partner-ERP-Integration ist; liefere OpenAPI und nenn das fertig.

#Wo das im Cluster sitzt

Dieser Artikel deckt die Protokoll-Entscheidung ab. Für den Implementierungs-Durchstich siehe MCP-Server für WooCommerce aufbauen. Für die Auth-Strategie siehe MCP-Authentifizierungsmuster. Für das typisierte Tool-Design siehe typisierte Katalog-Tools mit Zod für MCP. Für den Migrationspfad aus einer bestehenden API siehe bestehende WordPress-API auf MCP migrieren. Der Pillar ist MCP-Server-Entwicklung.

Preisgestaltung individuell, weil die richtige Form davon abhängt, welche Konsumenten du bedienst und welche Aktionen Agenten-Verträge brauchen.