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 den Umfang von KI-Integrationen für WordPress- und WooCommerce-Builds festlege.

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 Schemas mit Verhaltens-Annotationen für mutierende Aktionen brauchen.
• Produktions-Default ist REST als System of Record, MCP als agentenseitige Oberfläche davor.
• Selber Backend, zwei Oberflächen, eine Wahrheit.

#Was ist MCP und was ist eine REST-API

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). Die Entdeckung passiert zur Laufzeit via tools/list. Seit der Revision 2026-07-28 kennt das Protokoll keine Sessions mehr: Jeder Request trägt die Protokollversion und die Client-Fähigkeiten, und der Client fragt die Liste neu ab, wenn die gecachte Kopie abläuft oder eine Änderungsbenachrichtigung eintrifft.

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

#Entscheidungsmatrix für MCP oder REST-API

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.

#Wann eine REST-API besser passt als MCP

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. Ändert sich der Status einer Bestellung, schickt ein WooCommerce-Webhook das Ereignis an einen Partner-Endpunkt. Dieser Endpunkt ist ein HTTP-Empfänger. MCP ist die falsche Form, weil der Agent nicht in der Schleife ist; der Empfänger ist ein deterministisches System.

#Wann MCP besser passt als REST

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 Query-Parameter, verteilt über mehrere Endpunkte, und kein Signal, welcher passt.

Mutierende Aktionen, bei denen Idempotenz zählt. Eine Bestellung aus einem LLM zu erzeugen ist das lauteste Beispiel. Ein MCP-Tool order.intent mit typisiertem Input-Schema, einem Pflichtparameter idempotency_key und destructiveHint: false sagt Agent und Client, was der Aufruf tut, bevor er läuft. Das Protokoll garantiert keine Idempotenz: Der Handler muss eine zweite Bestellung mit demselben Schlüssel ablehnen. Der Unterschied zu einem freien POST /wp-json/wc/v3/orders liegt in einem Vertrag, den das Modell lesen kann.

Eine sich häufig ändernde Tool-Oberfläche. Ein neuer Suchfilter oder ein neuer Produkttyp bedeutet, ein neues MCP-Tool mit description und inputSchema zu veröffentlichen. Der Server sendet notifications/tools/list_changed an Clients, die subscriptions/listen geöffnet haben, und der Agent zieht das Tool beim nächsten tools/list ohne Codeänderung auf Agentenseite. 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.

#MCP und REST im WooCommerce-Shop

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.

#Authentifizierung bei MCP und REST-API

In WordPress hat die REST-API drei dokumentierte Wege (Authentifizierung in der REST-API). Cookie-Authentifizierung dient Code, der auf der Site selbst läuft, und verlangt eine Nonce der Aktion wp_rest, gesendet im Header X-WP-Nonce; ohne Nonce läuft der Request als anonymer Nutzer, auch bei aktiver Anmeldung. Application Passwords sind seit WordPress 5.6 Teil des Core und funktionieren mit HTTP Basic, nur über HTTPS. OAuth 1.0a und JSON Web Tokens kommen über Plugins. Die Feinsteuerung der Rechte passiert pro Route, über die Capabilities des Nutzers und den permission_callback jedes Endpunkts.

Die Autorisierung in MCP ist optional und gilt für HTTP-Transporte; bei stdio kommen die Zugangsdaten aus der Umgebung. Wird sie genutzt, ist der MCP-Server ein OAuth-2.1-Resource-Server, muss Protected Resource Metadata (RFC 9728) veröffentlichen und akzeptiert nur Tokens, die für ihn ausgestellt wurden: Der Client nennt den Server im Parameter resource (RFC 8707), und der Server lehnt Tokens mit fremder Audience ab. Andere Tokens darf der Server weder akzeptieren noch durchreichen, deshalb authentifiziert er sich bei WordPress mit eigenen Zugangsdaten, zum Beispiel einem Application Password eines Nutzers mit eingeschränkter Rolle.

Scopes funktionieren wie bei jeder OAuth-API, mit zwei Regeln, die für Agenten nützlich sind. Der Server kann in tools/list nur die Tools zurückgeben, die die Scopes des Tokens erlauben. Und braucht ein Aufruf mehr, antwortet er mit HTTP 403, error="insufficient_scope" und den nötigen Scopes im Header WWW-Authenticate, damit der Client eine neue Autorisierung mit dem erweiterten Satz anfordert. Der Nutzer gewährt dem Agenten orders:read; der Agent sieht order.cancel gar nicht und bekommt beim Versuch eines Aufrufs das 403, bevor der Handler läuft. OpenAPI beschreibt dasselbe mit securitySchemes und security pro Operation (OpenAPI-Spezifikation), aber in der Praxis dokumentieren viele REST-APIs einen einzigen globalen Scope und überlassen die feine Granularität der Anwendung.

Speziell für Agenten-Integrationen ist dieses Scope-Mapping pro Tool ein echter ergonomischer Gewinn, der zudem zu den DSGVO-Anforderungen an Datenminimierung passt. Darunter liegt dasselbe OAuth, das REST schon kennt, aber der Vertrag ist für Nutzer und Agenten lesbarer.

#Wie sich MCP-Caching vom HTTP-Cache bei REST unterscheidet

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.

Bei MCP hat die Revision 2026-07-28 einen Teil davon nachgezogen (Caching in MCP). Die Ergebnisse von tools/list, prompts/list, resources/list, resources/templates/list und resources/read müssen ttlMs tragen, das wie max-age funktioniert, und cacheScope mit den Werten public und private, analog zu Cache-Control. Die Ergebnisse von tools/call, also der Großteil des Agenten-Traffics, stehen nicht auf dieser Liste. Sie reisen als JSON-RPC-Payloads in POST-Requests, und HTTP-Cache-Header greifen nicht. Caching für Aufrufe 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 Ihr 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.

#MCP-Tool-Annotationen im Vergleich zu idempotenten HTTP-Verben

Bei REST steckt die Sicherheit einer Operation im Verb selbst. RFC 9110 definiert GET, HEAD, OPTIONS und TRACE als sichere Methoden und PUT, DELETE sowie die sicheren Methoden als idempotent: Mehrere identische Requests haben dieselbe beabsichtigte Wirkung wie ein einzelner. POST ist nicht idempotent. Ein Proxy, ein Crawler oder eine Retry-Bibliothek entscheidet allein anhand der Methode, was wiederholt werden darf, ohne den Body zu lesen.

MCP schickt alles als tools/call in einem POST, das Verb sagt also nichts aus. Die Information wandert in die Tool-Definition. Das Schema der Spezifikation definiert vier boolesche Annotationen in ToolAnnotations:

Die Standardwerte sind pessimistisch: Ein Tool ohne Annotationen gilt als schreibend, destruktiv und nicht idempotent. Laut Spezifikation sind alle diese Eigenschaften Hinweise, die das Verhalten nicht zuverlässig beschreiben müssen, und ein Client soll keine Entscheidungen auf Annotationen nicht vertrauenswürdiger Server stützen. Die Seite zu Tools empfiehlt zudem einen Menschen in der Schleife, der einen Aufruf ablehnen kann, und Bestätigungsabfragen bei sensiblen Operationen.

In einem WooCommerce-Shop sieht das so aus: product.search bekommt readOnlyHint: true, order.cancel bekommt destructiveHint: true, und die Idempotenz von order.intent sichert der Handler über einen Schlüssel ab, den der Server prüft, nicht die Annotation. Die Annotation hilft dem Client zu entscheiden, wann er nachfragt. Sie ersetzt nicht die Pflichten des Servers, die die Spezifikation aufzählt: alle Eingaben validieren, Zugriffskontrolle umsetzen, Aufrufe rate-limitieren und Ausgaben bereinigen.

#Wie MCP Fehler meldet im Vergleich zu HTTP-Statuscodes

Eine REST-API meldet Fehler über den Statuscode: 400 für einen fehlerhaften Request, 401 ohne gültige Authentifizierung, 403 ohne Berechtigung, 404 für eine nicht existierende Route. Die Tools-Spezifikation trennt zwei Ebenen. Protokollfehler (unbekanntes Tool, ein Request, der das Schema von tools/call verletzt, Serverfehler) kommen als normale JSON-RPC-Fehler, zum Beispiel mit dem Code -32602. Ausführungsfehler (Fehler der vorgelagerten API, Datum im falschen Format, verletzte Geschäftsregel) kommen in einem regulären Ergebnis mit isError: true und einer Textnachricht.

Die Spezifikation empfiehlt Clients, Ausführungsfehler an das Modell weiterzugeben, weil sie Informationen enthalten, mit denen es die Argumente korrigieren und es erneut versuchen kann. In einem MCP-Server, der die WordPress-REST-API kapselt, sollte ein 400-Validierungsfehler von WordPress zu einem Ergebnis mit isError: true werden, das den fehlenden Parameter benennt, und nicht zu einem Protokollfehler, den das Modell nicht beheben kann.

#Discovery in der WordPress-REST-API im Vergleich zu tools/list in MCP

Auch die WordPress-REST-API beschreibt sich selbst, nur anders. Die Seiten der Site senden einen Link-Header mit rel="https://api.w.org/", der auf die API-Wurzel zeigt, und die Wurzel unter /wp-json/ liefert ein Objekt mit den verfügbaren namespaces (wp/v2, wc/v3 und denen der Plugins), den Routen und einem Schlüssel authentication mit den unterstützten Verfahren (Discovery in der REST-API). Ein OPTIONS-Request auf eine Route liefert deren Schema, geschrieben in einer Teilmenge von JSON Schema Draft 4 (Schema in der REST-API).

Der Unterschied liegt beim Leser. Der WordPress-Index ist für Entwickler oder SDK-Generatoren gemacht: Er listet alle registrierten Routen, und jede akzeptiert globale Parameter wie _fields (Teilantworten, mit verschachtelten Eigenschaften seit WordPress 5.3), _embed (verlinkte Ressourcen in derselben Antwort) und _envelope (globale Parameter). Collections paginieren mit per_page bis 100 und liefern die Summen in den Headern X-WP-Total und X-WP-TotalPages (Paginierung). Das alles passt gut zu einem programmierten Client, aber ein Modell, das den ganzen Index bekommt, verbraucht Kontext für die Wahl zwischen Routen, die es nie nutzen wird.

tools/list in MCP liefert nur, was der Server freigeben will, jedes Tool mit description, inputSchema (standardmäßig JSON Schema 2020-12) und optional outputSchema. Die Spezifikation erlaubt, dass die Liste je nach Scopes des Tokens variiert, und verlangt eine deterministische Reihenfolge, damit der Client sie cachen kann und das Modell vom Prompt-Cache profitiert. Ein MCP-Server für WordPress ist in der Praxis eine kuratierte Auswahl aus dem Index /wp-json/, mit Beschreibungen für ein Modell statt für einen Entwickler.

WordPress 6.9 hat ein Zwischenstück ergänzt, die Abilities API. Ein Plugin registriert eine Ability mit input_schema, output_schema, einem optionalen permission_callback und show_in_rest in den Metadaten. Das ist ein nativer Weg, Funktionseinheiten mit Schema zu beschreiben, und genau der Vertrag, den ein MCP-Server für jedes Tool braucht.

#Was sich in MCP 2026-07-28 für HTTP-Proxys und Load Balancer geändert hat

Die Revisionen von 2025 hatten einen initialize-Handshake, Sessions mit dem Header Mcp-Session-Id und einen per GET geöffneten SSE-Stream. Mit mehreren Servern hinter einem Load Balancer zwingt eine Session pro Verbindung dazu, denselben Client immer an denselben Server zu leiten oder den Zustand zwischen Servern zu teilen, ein Problem, das zustandsloses REST nicht hat. Die Revision 2026-07-28 hat alle drei entfernt. Jeder Request trägt Protokollversion und Client-Fähigkeiten in _meta. Wer Zustand über mehrere Aufrufe braucht, etwa einen Warenkorb, gibt in einem Tool eine explizite Kennung zurück und nimmt sie in den folgenden Aufrufen als Argument entgegen.

Der Transport Streamable HTTP spiegelt außerdem Metadaten in Header. MCP-Protocol-Version und Mcp-Method sind bei jedem POST Pflicht, Mcp-Name zusätzlich bei tools/call, resources/read und prompts/get, und ein Tool kann Parameter mit x-mcp-header markieren, um sie als Mcp-Param-{Name} freizugeben. Eine WAF oder ein Gateway kann so pro Tool routen oder rate-limitieren, ohne den JSON-Body zu lesen. Stimmt ein Header nicht mit dem Body überein, antwortet der Server mit 400 und dem Fehler HeaderMismatch (-32020). Die Spezifikation rät davon ab, sensible Parameter so zu markieren, weil Header für Zwischenstationen sichtbar sind.

Wer bereits eine REST-API hinter einem CDN betreibt, für den rücken die beiden Oberflächen im Betrieb näher zusammen: Dieselben Routing- und Rate-Limiting-Regeln pro Header gelten für beide. HTTP-Caching greift für tools/call weiterhin nicht, weil jeder Aufruf ein POST ist.

#Wie man MCP und REST auf einem WordPress-Backend betreibt

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 bei MCP und REST

MCP RESTs Job machen lassen. Öffentliche Katalogseiten über MCP zu cachen ist falsch. Nutzen Sie 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-Analyse 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. Liefern Sie keinen aus, wenn Ihr einziger Konsument eine Partner-ERP-Integration ist; liefern Sie OpenAPI und nennen Sie das fertig.

#Verwandte Themen

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 Sie bedienen und welche Aktionen Agenten-Verträge brauchen.