MCP oder REST-API für deinen Agenten: was du ihm gibst, und wann

Gib deinem Agenten MCP, wenn er herausfinden muss, was er kann, und eine REST-API, wenn du es schon weißt. MCP bringt dir Discovery und einen einheitlichen Auth-Flow und kostet in jeder Session Kontext. Ein Skript, das jede Nacht auf dieselbe Weise postet, zahlt diesen Preis für nichts. Hier verläuft die Grenze, mit Zahlen.

MCP vs. API: die Tabelle

Beide sprechen mit demselben Server. Der Unterschied ist, wer die Dokumentation liest: das Modell oder du.

MCP-Server vs. REST-API: was sich zur Laufzeit wirklich unterscheidet

MCP ist ein JSON-RPC-2.0-Protokoll mit zwei Schichten: einer Datenschicht, die die Primitive definiert, und einer Transportschicht, die entweder stdio für einen lokalen Prozess oder Streamable HTTP für einen entfernten Prozess nutzt. Ein Server stellt drei Dinge bereit: Tools (Funktionen, die das Modell aufrufen kann), Ressourcen (Daten, die es lesen kann) und Prompts (Vorlagen). Der Client ruft tools/list auf, um herauszufinden, was es gibt, und dann tools/call, um ein Tool auszuführen. Am 9. Oktober 2026 auf der Spec-Seite geprüft.

Dieser tools/list-Schritt ist der springende Punkt. Eine REST-API hat dieselben Operationen, aber die Liste steckt in deinem Kopf und in deinem Code. Bei MCP landet die Liste vollständig im Kontextfenster des Modells, bevor es entschieden hat, ob es überhaupt etwas davon braucht.

Seit Protokollversion 2026-07-28 ist das Protokoll zustandslos: Jeder Request trägt Version und Capabilities in _meta, und server/discover ersetzt den alten Handshake. Die praktische Folge für dich: Ein Remote-MCP-Server kann ohne Sticky Sessions hinter einem Load Balancer laufen, und die Tool-Liste kommt mit dem Cache-Hinweis ttlMs zurück, sodass ein sauber implementierter Client sie nicht bei jedem Turn neu abruft.

Was ein Agent mit 103 Tools macht

Konkret sieht das so aus: Der MCP-Server von PlugKit stellt 103 Tools und 3 Workflows bereit, geprüft auf der Tools-Seite am 9. Oktober 2026. Die Tools sind nach Bereichen gruppiert: 18 für Kampagnen, 13 für Posts, 12 für Meta Ads, 10 für Accounts und Verbindungen, 9 für Messaging, 7 für Analytics, 7 für Engagement, bis hinunter zu 2 für die Suche.

Ein Agent, der „auf die Kommentare unter meinem letzten Reel antworten“ soll, braucht vielleicht vier dieser 103 Tools. Die anderen 99 sind trotzdem in seinem Kontext gelandet, mit Namen, Beschreibungen und Input-Schemas. Das ist der Preis dafür.

Drei Dinge senken die Rechnung, und alle drei gibt es heute schon:

1. Scopes. Eine Session, die nur mcp:read hat, bekommt die Write-Tools gar nicht erst registriert, die Liste schrumpft also, bevor sie beim Modell ankommt. Die Scopes sind mcp:read und mcp:write, dokumentiert in der MCP-Übersicht.
2. Workflows. PlugKit liefert drei davon mit (publish, inbox, report), die Clients als Slash-Commands anzeigen. Ein Command ersetzt eine Kette von Tool-Aufrufen, die das Modell sonst selbst planen müsste: weniger Runden und weniger Fehlgriffe.
3. Progressive Discovery. Die Spec hat dafür ein Pattern: Ein Client, der viele Server zusammenführt, lädt Tools bei Bedarf statt alle vorab. Ob du das bekommst, hängt von deinem Client ab, nicht vom Server.

Ein Server mit viermal so vielen Tools hat ein viermal so großes Problem. Auf dem MCP eines Konkurrenten habe ich 496 Tools gezählt (siehe Social-Media-MCP-Server im Vergleich), genug, um genau die Unterhaltung zu verdrängen, für die er eigentlich da ist.

Wann du MCP nutzen solltest

Gib dem Agenten MCP, wenn mindestens einer dieser Punkte zutrifft:

• Die nächste Aktion hängt davon ab, was der Agent liest. Eine Inbox triagieren, entscheiden, welcher Kommentar eine Antwort verdient, merken, dass ein Post fehlgeschlagen ist, und einen anderen Account wählen. Diese Verzweigungen kannst du nicht vorab aufzählen, und genau dafür ist ein Modell da.
• Ein Mensch ist im Loop. Jemand tippt „poste das um 9 Uhr auf Instagram und LinkedIn“. MCP macht aus diesem Satz Aufrufe, ohne dass du eine UI ausliefern musst.
• Du willst keine Zugangsdaten aufbewahren. OAuth 2.1 mit PKCE heißt, dass der Client nie ein langlebiges Secret speichert. Der User bestätigt auf einem Consent-Screen und widerruft den Zugriff auf demselben Weg.
• Der Funktionsumfang ändert sich. Ein Server, der Tools hinzufügt, wird genutzt, ohne dass du irgendetwas releasen musst.

Die Verbindung ist in Claude Code eine einzige Zeile: claude mcp add --transport http --scope user plugkit https://api.plugkit.co/mcp, danach /mcp zum Authentifizieren. Cursor, VS Code, die Claude-Apps und ChatGPT im Entwicklermodus nehmen alle dieselbe URL, laut der Client-Doku, heute geprüft.

Wann du ihm stattdessen die REST-API gibst

Gib ihm HTTP, wenn die Arbeit feststeht, bevor der Agent läuft:

• Zeitgesteuertes Veröffentlichen. Payload und Ziele sind bekannt. Ein POST erledigt das in 200 ms, ohne Modell dazwischen und ohne Token-Kosten: POST /v1/posts mit accountIds und publishNow, dokumentiert im Publishing-Guide.
• Du brauchst Tests. Ein Unit-Test prüft einen Statuscode. Er kann nicht sicherstellen, dass ein Modell an einem schlechten Tag create_post statt publish_post wählt.
• Volumen. Tausende Aufrufe pro Stunde über ein Modell sind eine Rechnung, keine Architektur.
• Strikte Fehlerbehandlung. PlugKit gibt 402 zurück, wenn ein Plan-Kontingent oder ein Ausgabenlimit einen Aufruf blockiert, 429 bei einem Rate Limit und 404 statt 403 für Ressourcen, die dir nicht gehören. Dein Code kann bei 429 einen Backoff einlegen und bei 402 Alarm schlagen. Ein Modell liest manchmal 402 und versucht es einfach noch mal.

Das nützliche Detail: Bei PlugKit entspricht jedes MCP-Tool einem REST-Endpoint mit demselben Vokabular und denselben IDs. Die beiden sind also keine Weggabelung. Du baust den Prototyp im Agenten, liest die IDs, die er zurückgegeben hat, und verlagerst dann die repetitive Hälfte in Code, ohne etwas neu lernen zu müssen.

Gib ihm beides, getrennt nach Determinismus

Was ich tatsächlich laufen lasse und jedem empfehlen würde, der auf einer Social-Media-API aufbaut: Code übernimmt alles Geplante und Repetitive, der Agent alles Dialogische und Mehrdeutige.

Für die Agent-Hälfte ist das Setup gleich, egal welchen Client du nutzt: siehe Claude als Social-Media-Manager für das, was das Modell gut kann und was ich nicht aus der Hand gebe, und wie du einem KI-Agenten Social-Media-Zugriff gibst für die Mechanik dahinter.

Wo MCP wirklich schlechter ist: Du verlierst Determinismus, du zahlst mit Kontext, und du kannst zwei Läufe nicht einfach diffen. Wer dir erzählt, MCP ersetze deinen API-Client, verkauft dir ein Protokoll, keine Architektur.

Was es kostet

PlugKit kostet 49 $ im Monat für 5 verbundene Accounts, jederzeit kündbar, oder 97 $ im Monat für 30. Der MCP-Server und die REST-API sind dasselbe Produkt zum selben Preis, die Wahl oben ist also rein technisch. Sieben Tage kostenlos, ohne Karte, mit einem verbundenen Account während der Testphase. Das einzige nutzungsbasierte Extra ist X: Calls werden zum Tarif von X selbst weitergereicht, 0,005 $ fürs Lesen eines Posts und 0,015 $ fürs Veröffentlichen, mit einem standardmäßigen monatlichen Ausgabenlimit von 20 $ pro Account, bis du dein eigenes festlegst. Zahlen laut der Billing-Seite, geprüft am 9. Oktober 2026.

FAQ

Was ist der Unterschied zwischen MCP und einer API?

Eine API ist die Schnittstelle; MCP ist ein standardisierter Weg, diese Schnittstelle an ein Modell zu übergeben. Ein MCP-Server sitzt fast immer vor einer REST-API und stellt dieselben Operationen als Tools bereit, die das Modell zur Laufzeit über tools/list entdeckt, statt als Endpoints, gegen die du programmierst. MCP bringt Discovery und einen einheitlichen Auth-Flow und kostet dafür Kontext.

Ist MCP für Agenten besser als eine REST-API?

Nur wenn der Agent eine Wahl treffen muss. Steht die Abfolge der Calls schon vor dem Lauf fest, ist ein REST-Client schneller, günstiger, testbar und deterministisch. Hängt der nächste Call davon ab, was der letzte zurückgegeben hat, ist MCP seine Kontextkosten wert.

Wann sollte ich MCP nutzen?

Wenn ein Mensch mit dem Agenten spricht, wenn die nächste Aktion von Daten abhängt, die der Agent gerade gelesen hat, wenn du lieber keinen langlebigen API-Key speichern willst oder wenn sich die Tool-Liste ändert, ohne dass du ein Release auslieferst. Geplante, identische Calls in hohem Volumen sind der gegenteilige Fall.

Verbraucht MCP viele Tokens?

Jede Tool-Definition in der Liste landet im Kontext: Name, Beschreibung und JSON Schema. Auf einem Server mit 103 Tools ist das in jeder Session spürbarer Overhead. Senken kannst du ihn mit einem Read-only-Scope, der Write-Tools komplett ausblendet, mit serverseitigen Workflows, die mehrere Aufrufe zu einem Command zusammenfassen, und mit einem Client, der Progressive Discovery beherrscht.

Kann ich MCP und die REST-API gleichzeitig nutzen?

Ja, und das solltest du auch. Bei PlugKit entspricht jedes MCP-Tool einem REST-Endpoint mit denselben IDs, sodass ein Agent erkunden und dein Cronjob auf denselben Accounts veröffentlichen kann. Scopes und Keys sind getrennt, der Agent kann also nur lesen, während dein Code Schreibzugriff behält.

AB

Antoine BlancoGründer von PlugKit. Betreibt seine eigenen Instagram-, YouTube- und X-Accounts über die hier beschriebene API und den MCP-Server.