Ich erinnere mich an eine Diskussion vor einigen Jahren, in der jemand fragte, warum eine bestimmte Anwendung keine REST-API hatte. Die Antwort war sinngemäß: „Brauchen wir doch nicht, die Funktionalität ist vollständig.“
Das stimmte sogar – aus Sicht der Anwendung selbst. Sie konnte, was sie können sollte. Nur konnte kein anderes System sie sauber ansteuern. Für automatisierte Workflows war sie damit praktisch nicht vorhanden.
Für mich ist das keine abstrakte Architekturfrage. Ein großer Teil meiner Arbeit besteht genau darin, bestehende Systeme, Datenquellen und Prozesse miteinander zu verbinden. Ich baue nicht immer ein komplett neues System. Oft geht es darum, vorhandene Anwendungen so zu integrieren, dass daraus ein durchgängiger digitaler Prozess wird. Deshalb ist eine der ersten Fragen in solchen Projekten fast immer: „Gibt es eine API?“ Und neuerdings kommt eine zweite Frage dazu: „Gibt es eine Schnittstelle, mit der auch ein Agent sinnvoll arbeiten kann?“
Man kann sich das wie den Unterschied zwischen einer rein serverseitig gerenderten Anwendung und einer modernen Frontend-Backend-Anwendung vorstellen. Bei einer klassischen Server-Rendered-App hängt vieles direkt am HTML, an Formularen und Seitenwechseln. Das funktioniert für Menschen im Browser. Aber sobald ein eigenes Frontend, eine Mobile-App, ein Partner-System oder ein interner Workflow dieselbe Funktionalität nutzen soll, braucht es eine saubere Schnittstelle. In modernen Anwendungen ist eine API deshalb keine nette Zusatzoption mehr, sondern fast eine Grundvoraussetzung.
Nicht nur technisch, auch geschäftlich. Eine Anwendung mit guter API kann Teil größerer Abläufe werden. Sie lässt sich integrieren, automatisieren und in neue Nutzungskontexte einbauen. Das erlaubt einem Produktteam, sich stärker auf den eigentlichen Kernnutzen zu konzentrieren, statt jede mögliche Oberfläche selbst bauen zu müssen. Eine Anwendung ohne API ist dagegen nicht unbedingt schlechter. Sie ist nur schwerer anschlussfähig.
Irgendwann hatte dann jede ernstzunehmende Anwendung eine REST-API. Nicht weil alle Entwickler REST liebten, sondern weil Nicht-Integrierbarkeit keine Option mehr war.
Genau diese Verschiebung wiederholt sich gerade. Diesmal für Agenten.
Die Schicht, die dafür gerade am meisten Momentum hat, heißt MCP: Model Context Protocol. Vorgestellt wurde MCP Ende 2024 von Anthropic. Seitdem ist es nicht einfach ein weiteres Integrationsformat geblieben, sondern entwickelt sich zu einem ernsthaften Kandidaten für die Frage: Wie machen Anwendungen ihre Funktionen für KI-Agenten sichtbar und nutzbar?
Eine neue Schicht, kein Ersatz
Erste Präzision, weil sich sonst der Rest des Artikels sofort falsch liest: MCP ersetzt REST nicht. Es sitzt darüber.
Ein MCP-Server ist nicht zwingend eine neue Business-Logik. Oft ist er eher eine Agenten-freundliche Fassade vor vorhandenen APIs. Ein Beispiel: Ein Agent bekommt ein Werkzeug wie ticket/search oder customer/get angeboten. Intern kann der MCP-Server daraus weiterhin ganz normale REST- oder GraphQL-Aufrufe machen. Die bestehende Anwendung muss nicht neu erfunden werden. Aber sie bekommt eine zusätzliche Schicht, die für Agenten lesbar ist.
Was MCP hinzufügt, ist etwas, das klassische APIs nur begrenzt leisten: Discovery zur Laufzeit. Ein Agent kann fragen, welche Werkzeuge verfügbar sind, welche Parameter sie erwarten und welche Ergebnisse zurückkommen. Dazu kommen Konzepte wie Sessions und Kontext, damit längere Arbeitsvorgänge nicht bei jedem einzelnen Aufruf wieder bei null anfangen.1
Das ist der eigentliche Punkt. Nicht: „REST ist tot.“ Sondern: Über REST entsteht eine zweite Schnittstellenschicht, die nicht primär für Menschen und klassische Integrationen gedacht ist, sondern für Agenten.
Wer das als bloßes API-Update liest, unterschätzt es.
Warum Agenten andere Schnittstellen brauchen als Menschen
Menschen navigieren UIs. Sie lesen Dokumentation, klicken sich durch Menüs, probieren aus und bauen sich im Kopf ein Modell davon, was ein System kann.
Ein Agent hat diesen Luxus nicht. Er muss zur Laufzeit herausfinden, welche Funktionen ihm zur Verfügung stehen, in welcher Form er sie aufrufen darf und was als Rückgabe zu erwarten ist – ohne Klickpfade, ohne Screenshots und ohne Kontext, den ihm ein Mensch jedes Mal in den Prompt vorkaut.
Dazu kommt das N×M-Problem. Ohne Standard müsste jede Anwendung für jedes Agenten-Framework eigene Adapter bauen. Zehn Frameworks, hundert Anwendungen – tausend Integrationen, die niemand dauerhaft pflegen will.1
Genau hier entsteht die neue Schicht. MCP ist derzeit der sichtbarste und am breitesten adoptierte Versuch, diese Schicht zu standardisieren.
Ob genau dieses Protokoll am Ende alles gewinnt, ist eine andere Frage. Dass Anwendungen eine Agenten-Schnittstelle brauchen werden, ist die wichtigere Beobachtung. Man sieht das bereits daran, dass viele bekannte Produkte MCP-Server nachziehen oder zumindest experimentell bereitstellen. Nicht weil MCP modisch klingt, sondern weil sie in agentischen Workflows nicht unsichtbar sein wollen.
Die Adoption-Kurve ist kein Nischen-Experiment mehr
Wer bei „neuer Standard“ reflexartig winkt, sollte einmal auf die Zahlen schauen.
November 2024: rund 100 MCP-Server. Dezember 2025: über 5.800.2 SDK-Downloads im selben Zeitraum von 100.000 auf 97 Millionen monatlich.2 OpenAI hat MCP im März 2025 übernommen, Google DeepMind im April, Microsoft in Azure AI Agent Service integriert.2 Im Dezember 2025 hat Anthropic das Protokoll an die Linux Foundation übertragen – mit AWS, Google, Microsoft, OpenAI, Bloomberg und Cloudflare als Gründungsmitgliedern der Governance.2
Das ist nicht der Weg eines Nischen-Tools. Das ist die Standardisierungsbahn, die man aus anderen Infrastrukturwellen kennt: Ein Player startet, die wichtigen Anbieter ziehen nach, eine neutrale Foundation übernimmt. In kurzer Zeit.
Natürlich heißt das nicht, dass jedes Unternehmen morgen einen MCP-Server veröffentlichen muss. Aber es heißt: Die Richtung ist real genug, um sie in Produkt- und Architekturentscheidungen mitzudenken.
First-Mover und was „table stakes“ konkret bedeutet
Für Developer-Tools und B2B-SaaS ist die Dynamik besonders klar. Stripe, Cloudflare, GitHub, Shopify und Linear haben MCP-Server in Produktion.3 In diesem Umfeld wird ein MCP-Server schnell von einem Differenzierungsmerkmal zu einer Grundvoraussetzung.
Das ist ein wichtiger Unterschied. Ein früher MCP-Server kann Sichtbarkeit schaffen, weil Agenten und Agenten-Frameworks verfügbare Werkzeuge leichter entdecken und einbinden können. Wenn aber irgendwann alle relevanten Wettbewerber einen solchen Zugang haben, ist er kein Vorteil mehr. Dann ist sein Fehlen ein Nachteil.
An dieser Stelle liegt die Mobile-First-Analogie nahe, und sie hilft, solange man sie nicht überzieht.
Mobile First war ein Denkwechsel: erst mobil denken, dann Desktop. Agent First ist ebenfalls eine Reihenfolge-Frage – aber keine reine UI-Frage. Es geht nicht darum, ob eine Oberfläche auf einem kleinen Bildschirm funktioniert. Es geht darum, ob eine Anwendung von nicht-menschlichen Akteuren sinnvoll entdeckt, verstanden und angesteuert werden kann.
Desktop-Anwendungen wurden durch Mobile First nicht abgeschafft. MCP-lose Anwendungen verlieren ebenfalls nicht über Nacht ihre Funktion. Sie verlieren Anschlussfähigkeit. Das ist eine leisere Form des Verlierens – aber eine, die schwer aufzuholen ist, wenn sich die Workflows der Nutzer erst einmal an andere, besser integrierbare Werkzeuge gewöhnt haben.
Die offenen Flanken: Sicherheit und Protokoll-Fragmentierung
Wer jetzt nickt und „wir bauen sofort einen MCP-Server“ ruft, hat den Artikel falsch gelesen.
Thoughtworks hat naive API-zu-MCP-Konvertierung explizit auf „Hold“ gesetzt.4 Der Grund ist nicht Skepsis gegenüber MCP an sich, sondern eine konkrete Angriffsfläche: Tool Poisoning, Prompt Injection, Cross-Server-Tool-Shadowing und unautorisierter Datenzugriff.45 Red Hat hat eigene Analysen dazu veröffentlicht, Microsoft ebenfalls.5
Der halbironische Satz „das S in MCP steht für Security“ kursiert nicht ohne Grund. Wer eine bestehende REST-API stumpf durch einen MCP-Wrapper zugänglich macht, öffnet damit möglicherweise mehr, als er kontrolliert.
Ein MCP-Server ist deshalb kein „API exportieren“-Knopf. Er ist ein Sicherheits- und Produktdesign-Thema. Welche Werkzeuge dürfen Agenten sehen? Welche Aktionen sind nur lesend? Welche brauchen Freigabe? Welche Daten dürfen niemals in Tool-Ausgaben landen? Welche Aktionen müssen auditierbar sein?
Die zweite offene Flanke ist Protokoll-Fragmentierung. MCP ist nicht allein. Google hat im April 2025 A2A veröffentlicht, IBM hat ACP eingebracht, aus der Community kommt ANP.67 Diese Protokolle konkurrieren nicht alle direkt mit MCP. Sie adressieren unterschiedliche Ebenen desselben Stacks: MCP für Tool-Zugriff, A2A für Agent-zu-Agent-Kollaboration, ANP für dezentrale Szenarien.67
Wahrscheinlich wird die Zukunft deshalb nicht aus einem einzigen Protokoll bestehen. Eher aus Koexistenz – ähnlich wie heute HTTP, WebSocket und gRPC nebeneinander leben.
Die robuste These lautet also nicht: MCP gewinnt alles.
Die robustere These lautet: Für Agenten entsteht eine neue Integrationsschicht. MCP ist heute auf der Tool-Access-Ebene die sichtbarste Implementierung mit der breitesten Adoption. Das reicht, um es ernst zu nehmen.
Die produktstrategische Konsequenz
Die interessante Frage ist deshalb nicht: „Sollen wir jetzt MCP implementieren?“
Die interessantere Frage ist: Denken wir Agentenfähigkeit heute schon als strategische Anforderung mit – oder gar nicht?
Für Developer-Tools und B2B-SaaS ist der Spielraum eng. Wenn Nutzer bereits agentische Workflows bauen und die Konkurrenz bereits in diesen Workflows auftaucht, schließt sich das Fenster für First-Mover-Vorteile schnell.
Gartner erwartet, dass bis 2026 rund 75 Prozent der API-Gateway-Anbieter und 50 Prozent der iPaaS-Anbieter MCP-Features integriert haben werden.2 iPaaS steht für „Integration Platform as a Service“ – also Plattformen, die Anwendungen, Datenquellen und Prozesse miteinander verbinden. Wenn genau diese Integrationsschicht MCP aufnimmt, wird Agentenfähigkeit nicht mehr nur ein Thema einzelner AI-Teams. Sie wandert in die normale Unternehmensintegration.
Für andere Segmente – Consumer-Apps, vertikale Software, regulierte Industrien – ist der Zeithorizont länger, und die Sicherheitsbedenken wiegen schwerer. Aber der Denkwechsel gehört jetzt in die Produktdiskussion. Nicht als Panik. Nicht als Hype. Sondern als das, was Integrierbarkeit immer war: eine Produktentscheidung, die früh getroffen leichter fällt als spät nachgezogen.
Die Frage an die eigene Roadmap lautet damit anders als noch vor zwei Jahren.
Nicht mehr nur: Haben wir eine API?
Sondern: Können Agenten unsere Kernfunktionen zur Laufzeit entdecken und sicher ansteuern – und wollen wir das überhaupt?
Das „wollen wir“ ist wichtig. Nicht jede Funktion sollte agentisch ausführbar sein. Nicht jede Aktion gehört in einen MCP-Server. Nicht jedes Produkt braucht sofort externe Agenten-Schnittstellen. Aber jedes Produktteam, das Software für Arbeitsprozesse baut, sollte diese Entscheidung bewusst treffen.
Anwendungen, die keine Agentenschnittstelle mitdenken, verlieren nicht sofort ihre Funktion. Sie verlieren Anschlussfähigkeit. Und Anschlussfähigkeit war in Software schon oft der Unterschied zwischen einem nützlichen Produkt und einem Produkt, das in den Workflows der Nutzer langsam verschwindet.
Quellen
Footnotes
-
WorkOS: „MCP vs. REST: What’s the right way to connect AI agents to your API?“ — https://workos.com/blog/mcp-vs-rest ↩ ↩2
-
Deepak Gupta: „The Complete Guide to Model Context Protocol (MCP): Enterprise Adoption, Market Trends, and Implementation Strategies“ — https://guptadeepak.com/the-complete-guide-to-model-context-protocol-mcp-enterprise-adoption-market-trends-and-implementation-strategies ↩ ↩2 ↩3 ↩4 ↩5
-
Aakash Gupta: „The PM’s Playbook for AI Agent Distribution“ — https://www.news.aakashg.com/p/master-ai-agent-distribution-channel ↩
-
Thoughtworks: „The Model Context Protocol’s impact on 2025“ — https://www.thoughtworks.com/en-us/insights/blog/generative-ai/model-context-protocol-mcp-impact-2025 ↩ ↩2
-
Red Hat: „Model Context Protocol (MCP): Understanding Security Risks and Controls“ — https://www.redhat.com/en/blog/model-context-protocol-mcp-understanding-security-risks-and-controls ↩ ↩2
-
Zylos AI: „A2A, MCP, ACP, and ANP – Agent Communication Protocols“ — https://zylos.ai/research/2026-02-15-agent-to-agent-communication-protocols ↩ ↩2
-
arXiv: „A Survey of Agent Interoperability Protocols: MCP, ACP, A2A, ANP“ — https://arxiv.org/html/2505.02279v2 ↩ ↩2