MCP Verschlingt die API-Wirtschaft

Model Context Protocol macht mit API-Integration, was REST mit SOAP gemacht hat: die handgeschriebene Integrationsschicht wird ersetzt durch etwas, das ein Agent selbst entdecken und nutzen kann.

Wenn erfahrene Ingenieure zum ersten Mal einen MCP-Server sehen, tun sie ihn als Wrapper um JSON-RPC ab. Ist er auch. Das traf 2005 auch auf REST über HTTP zu.

Die eigentliche Frage, die MCP beantwortet, ist dieselbe, die REST zwanzig Jahre lang schlecht beantwortet hat: Wie macht ein Stück Software seine Fähigkeiten einem anderen zugänglich, das es noch nie gesehen hat? Die Antwort von REST war „lies die Docs und schreib einen Client." Diese Antwort funktioniert nur, wenn der Leser ein menschlicher Entwickler ist.

REST-APIs wurden für Menschen gebaut, die Client-Code schreiben. Endpoints, Docs, handgeschriebene Fetch-Aufrufe in der richtigen Reihenfolge mit den richtigen Parametern. Jede Integration ist maßgeschneidert.

Das funktioniert, wenn der Konsument ein menschlicher Entwickler ist. Es bricht, wenn der Konsument ein LLM ist. Ein LLM liest nicht deine Swagger-Datei und entscheidet, welche drei von zwölf Endpoints zu verketten sind. Es braucht die Fähigkeit beschrieben in seinem Input: Tool-Name, was es tut, Eingabeschema, Ausgabeschema, Seiteneffekte.

MCP liefert genau diese Form. Ein `tools/list`-Aufruf gibt jede Fähigkeit mit einem JSON-Schema zurück, über das das Modell zur Inferenzzeit reasonen kann. Kein SDK, keine Code-Generierung, kein Onboarding-Ticket.

Was MCP transformativ macht, ist keine einzelne Funktion. Es ist die Komposition zur Laufzeit.

Wenn jeder Dienst sich als MCP-Tools exponiert, kann ein Agent sie zur Inferenzzeit entdecken und verketten. Ein Support-Agent liest aus dem CRM, fragt den Billing-Dienst ab, verfasst eine Slack-Nachricht und eröffnet ein Ticket — mit Tools, von denen er dreißig Sekunden vorher nichts wusste. Keine hardcodierten Integrationen. Keine anbieterspezifische Middleware.

Das ist die Unix-Philosophie angewendet auf Agents. Kleine, fokussierte Tools, die sich komponieren. Der Komponist ist kein Shell-Skript mehr; er ist ein Modell, das über die Kombination und Reihenfolge der Tools reasonen kann.

Wenn du es trivial einfach machst, Agents mit beliebigen Tools zu verbinden, machst du es auch trivial einfach, Agents mit bösartigen Tools zu verbinden. Tool-Poisoning — wenn die Beschreibung ein Verhalten verspricht und die Implementierung ein anderes tut — ist die SQL-Injection der MCP-Ära.

Die meisten Teams, die heute MCP-Server ausliefern, denken nicht darüber nach. Sie konzentrieren sich darauf, dass es läuft. Jede große Sicherheitskrise in der Geschichte des Web hat genau so angefangen.

Die Teams, die in der MCP-Wirtschaft gewinnen, sind nicht die schnellsten beim Ausliefern. Es sind die, die Tool-Provenance, Output-Sanitization und Sandboxing gelöst haben, bevor sie es auf die harte Tour lernen mussten.

Wenn du Software baust, die andere Software konsumiert, solltest du bereits ein MCP-Interface ausliefern. Die Ökonomie zwingt dich dazu.

Eine REST-Integration kostet einen Entwickler Tage. Ein MCP-Tool kostet Minuten. Wenn Integration 100-mal billiger wird, bekommst du nicht 100-mal mehr von denselben Integrationen — du bekommst ganze Kategorien von Integrationen, die sich vorher nicht gelohnt haben. Stripe liefert bereits einen MCP-Server aus. Linear auch. Supabase auch.

Jedes SaaS wird irgendwann MCP-Tools exponieren. Jeder interne Dienst wird ein MCP-Interface haben. Die einzige echte Frage ist, ob du eins ausliefers, bevor dein Wettbewerber es tut.