Der Moment, der die KI-Engineering-Community aufhorchen ließ
Im März 2026 lässt Denis Yarats, CTO (Chief Technology Officer) von Perplexity, auf der firmeneigenen Ask-2026-Konferenz eine Aussage fallen, die seither durch die KI-Engineering-Community hallt: Perplexity bewegt sich intern weg von MCP, dem Model Context Protocol, und setzt stattdessen auf klassische REST-APIs (Representational State Transfer) und Command-Line-Interfaces (CLI).
Die Begründung ist nüchtern. 72 Prozent des verfügbaren Kontextfensters werden durch MCP-Schemata verbraucht, bevor ein Agent überhaupt die erste Nutzerfrage verarbeitet hat. Dazu kommt eine holprige Authentifizierung, die in Produktivsystemen mehr Probleme schafft, als sie löst.
Was folgte, war keine stille Notiz am Rande. Der Präsident von Y Combinator äußerte sich ähnlich, Hacker News diskutierte tagelang. Und plötzlich stand eine Frage im Raum, die niemand so direkt stellen wollte: War MCP von Anfang an überbewertet, oder ist es einfach ein Werkzeug, das für die falsche Aufgabe eingesetzt wird?
Dieser Artikel analysiert beide Seiten. Er erklärt das Token-Effizienz-Problem an konkreten Zahlen, zeigt, warum CLI auf einmal wieder in aller Munde ist, und beschreibt einen dritten Weg, der in der Praxis zunehmend an Bedeutung gewinnt: selbstheilende Pipelines, die regulär ohne Agent laufen und erst im Fehlerfall einen KI-Agenten hinzuziehen, der das Problem diagnostiziert, die Schnittstelle repariert und den Prozess neu startet. Am Ende steht die Frage, die sich jedes Unternehmen stellen muss: Welches Integrationsmuster ist für welchen Use Case das kosteneffizienteste, und wo lohnt sich ein Blick auf das Try-Heal-Retry-Pattern?
Was ist MCP, und warum war die Aufregung berechtigt?
MCP (Model Context Protocol) wurde im November 2024 von Anthropic eingeführt. Die Idee dahinter ist bestechend einfach: ein offener Standard, der es KI-Agenten erlaubt, sich mit beliebigen externen Tools, Datenbanken und APIs (Application Programming Interfaces) zu verbinden, ohne dass jeder Anbieter eine eigene Integrationslogik schreiben muss.
Die Analogie, die damals kursierte, war die USB-C-Metapher. USB-C hat das Chaos proprietärer Ladekabel beendet, MCP sollte das Gleiche für KI-Tool-Integrationen leisten. Und die Adoption folgte schnell: OpenAI übernahm den Standard, Google und Microsoft schlossen sich an. Bis Anfang 2026 wird MCP von Millionen aktiver Entwickler-Tool-Nutzer täglich eingesetzt.
Das Versprechen war real: Wer einen MCP-Server baut, kann ihn in jedem kompatiblen KI-Client nutzen, ob Claude Desktop, Cursor, Windsurf oder VS Code Copilot. Kein proprietäres Chaos, kein doppelter Entwicklungsaufwand. Für die Entwicklungsphase und für Explorer-Use-Cases ist das ein echter Vorteil.
Was sich aber herausgestellt hat: Das Versprechen gilt für die Prototyp-Phase. Für den produktiven Betrieb bei Scale gibt es ein fundamentales Problem, und das hat mit der Architektur des Protokolls selbst zu tun.
Der MCP-Tax: Das Token-Problem in Zahlen
Das Kernproblem von MCP ist kein Bug, sondern eine Designentscheidung. Beim Start lädt ein MCP-Server seine gesamte Tool-Bibliothek als JSON-Schema in den Kontext des Sprachmodells, jedes Tool mit Name, Beschreibung, Parametern, Typen und Nutzungshinweisen, ob der Agent es im jeweiligen Turn benötigt oder nicht.
Ein typisches Setup verdeutlicht das: Drei gängige Business-Tools wie GitHub, Slack und Sentry summieren sich auf über 55.000 Tokens an Schema-Definitionen. Bei einem 200K-Kontextfenster ist damit rund ein Viertel belegt, bevor die erste Nutzerfrage gestellt wurde, dauerhaft und unabhängig davon, ob der Agent diese Tools überhaupt nutzt. Ein Benchmark für Browser-Automation zeigt denselben Effekt: Playwright MCP verbrauchte für eine Standard-Aufgabe rund 114.000 Tokens, die CLI-Variante nur 27.000, bei zugleich höherer Task-Completion-Rate (Score 77 gegenüber 60).
Für diesen Overhead hat sich in der Community der Begriff „MCP-Tax" etabliert. Die Diskussion ist mittlerweile so präsent, dass der offizielle MCP-Backlog eine Spec-Erweiterung für das On-Demand-Tool Discovery enthält, ein indirektes Eingeständnis des Designproblems.
CLI, Command-Line Interface: Die unterschätzte Alternative
CLI steht für Command-Line Interface, die textbasierte Kommandozeile, über die Entwickler seit Jahrzehnten mit Systemen interagieren. Statt grafischer Oberflächen gibt der Nutzer, in diesem Fall der KI-Agent, Befehle als Text ein und erhält strukturierte Antworten zurück. Tools wie git, docker oder kubectl sind klassische CLI-Werkzeuge, die in der Softwareentwicklung allgegenwärtig sind.
Die Gegenbewegung zu MCP klingt auf den ersten Blick wie ein Rückschritt: einfach die Kommandozeile nehmen. Aber der Grund, warum CLI in diesem Kontext funktioniert, liegt nicht an der CLI selbst, sondern an den Sprachmodellen, die sie nutzen.
Große Sprachmodelle (Large Language Models, kurz LLMs) wurden auf riesigen Mengen Code, Dokumentation und Entwickler-Tutorials trainiert. In diesem Training haben sie intensive Berührungspunkte mit git, bash, python, docker, kubectl, jq und hunderten weiteren CLI-Tools. Das Ergebnis: Diese Modelle wissen bereits, wie diese Tools funktionieren, ohne dass die Beschreibung jedes Parameters ins Kontextfenster geladen werden muss.
Der Effizienz-Vorteil von CLI gegenüber MCP für solche bekannten Tools liegt laut mehreren unabhängigen Benchmarks zwischen Faktor 10 und 32. Nicht Prozentpunkte, ein Faktor.
Ein verwandter Ansatz, der das CLI-Prinzip weiterdenkt, sind sogenannte Agent Skills. Das sind vordefinierte Fähigkeiten, die einem Agenten als kompakte Anweisungen mitgegeben werden, statt als vollständige Tool-Schemata. Während MCP die gesamte Tool-Bibliothek ins Kontextfenster lädt, funktionieren Skills eher wie Checklisten: Der Agent weiß, was er tun kann, und ruft die Details erst ab, wenn er sie braucht. Das Prinzip ähnelt der On-Demand-Logik von mcp2cli, nur auf einer höheren Abstraktionsebene.
Der dritte Weg: Selbstheilende Pipelines, kosteneffizient, weil der Agent nur im Fehlerfall eingreift
Was in der MCP-vs-CLI-Debatte oft untergeht, ist ein drittes Muster, das sich in der Praxis gerade etabliert und das für Produktions- und Massenprozesse eine besonders kosteneffiziente Alternative darstellt.
Die Idee: Pipelines und Schnittstellen, ob Python-Skripte, Shell-Skripte, API-Wrapper oder ETL-Jobs (Extract, Transform, Load), laufen regulär ohne Agent. Sie sind so gebaut, dass sie im Normalfall autonom funktionieren. Wichtig dabei ist die Unterscheidung zwischen Erstellung und Betrieb: Bei der Entwicklung dieser Pipelines können KI-Agenten durchaus eine zentrale Rolle spielen, etwa beim Generieren der Skripte, beim Aufsetzen der ETL-Logik oder beim Schreiben der Schnittstellen-Wrapper. Im laufenden Betrieb dagegen arbeiten die Pipelines bewusst ohne Agent. Erst wenn ein Fehler auftritt, wird wieder ein KI-Agent hinzugezogen, der den Fehler analysiert, die Schnittstelle repariert und den Prozess neu anstößt. Der entscheidende Kostenvorteil: Statt dauerhaft Tokens für einen aktiven Agenten im Normalbetrieb zu verbrauchen, fallen KI-Kosten gezielt dort an, wo sie Mehrwert schaffen, bei der Erstellung und im Ausnahmefall.
Das Muster nennt sich Try-Heal-Retry und funktioniert folgendermaßen: Eine Pipeline oder ein automatisierter Job läuft regulär, ohne Agent, ohne Token-Kosten. Der Job schlägt fehl, weil sich ein API-Schema geändert hat, weil eine Bibliothek fehlt, weil ein Endpunkt einen anderen Response-Typ zurückgibt als erwartet. Erst jetzt wird ein spezialisierter Repair Agent aktiviert: Er liest den vollständigen Fehler-Stack, analysiert die Ursache, passt die Schnittstelle an und startet den Prozess erneut.
Ein konkretes Beispiel aus der Datenpipeline: Ein nightly Ingestion-Job in Airflow schlägt fehl, weil ein Upstream-System eine neue Spalte hinzugefügt hat, ein klassisches Schema-Mismatch-Problem. Mit dem Try-Heal-Retry-Pattern erkennt ein spezialisierter Repair Agent das Schema-Delta, aktualisiert das ETL-Mapping direkt im Code und re-triggert den Job, ohne menschliches Eingreifen.
Das ist kein Prototyp-Konzept mehr. Unternehmen wie 3M berichten, dass selbstheilende Pipelines in ihren Datenumgebungen dieses Muster produktiv einsetzen. CI/CD-Systeme (Continuous Integration / Continuous Deployment) nutzen Repair Agents und Monitoring Agents, die bei Build-Failures eigenständig Requirements-Dateien anpassen, Abhängigkeiten korrigieren und die Pipeline-Gesundheit kontinuierlich überwachen.
Was dieses Muster fundamental von MCP und CLI unterscheidet: Der Agent ist nicht mehr nur Konsument einer Schnittstelle. Er ist Überwacher, Reparateur und Optimierer, aber eben nur dann, wenn es nötig ist. Im Normalbetrieb entstehen keine Token-Kosten. Das macht selbstheilende Pipelines zum kosteneffizientesten Muster für wiederkehrende Produktionsprozesse.
Das hat Konsequenzen für Architekturfragen, die noch nicht ausreichend diskutiert werden. Wenn ein Agent eine Schnittstelle korrigiert und dieser Fix persistiert wird, entsteht eine neue Form von Code-Governance: Wer reviewed das? Wer dokumentiert es? Wer merkt, wenn ein Agent iterativ einen sub-optimalen Fix eingecheckt hat, der technisch funktioniert, aber Performance-Probleme einführt? Das Try-Heal-Retry-Pattern ist mächtig, es verlangt aber einen klaren Rahmen, innerhalb dessen Agenten autonom handeln dürfen.
Warum „MCP vs. CLI?" die falsche Frage ist, und was die Benchmarks wirklich zeigen
Die Zahlen aus den Benchmarks sind beeindruckend. Aber sie erzählen nur einen Teil der Geschichte. CLI schlägt MCP bei Token-Effizienz um einen Faktor von 10 bis 32, und zwar für Tools, die LLMs aus dem Training kennen. Das ist der entscheidende Zusatz. Für Slack gibt es kein Standard-CLI-Interface, das Claude oder GPT-4 aus dem Training kennt. Für Notion, für proprietäre ERP-Systeme (Enterprise Resource Planning), für Industrie-APIs in der Energiebranche auch nicht. In diesen Szenarien müsste ein CLI-Wrapper gebaut, dokumentiert und dem Agenten bekannt gemacht werden, womit ein Großteil des Effizienzvorteils wieder verschwindet.
Außerdem ist CLI gut für lineare Aufgaben. Für komplexe Multi-Step-Prozesse, in denen ein Agent auf vorherige Ergebnisse zugreifen muss und Kontext über mehrere Tools hinweg aufrechterhält, kann die Serialisierung über CLI-Aufrufe mehr Roundtrips erzeugen als ein gut designtes MCP-Interface.
Anthropics eigener Code-Mode-Ansatz zeigt einen interessanten Mittelweg: Statt raw MCP-Aufrufe werden Tools als ausführbare Code-Blöcke übergeben. In einem Benchmark für Invoice-Erstellung reduziert dieser Ansatz die LLM-Roundtrips von 19 (bei CLI) und 12 (bei raw MCP) auf 4, bei 58 Prozent weniger Token-Verbrauch als raw MCP.
Die Lesson: Die Debatte „MCP vs. CLI" ist die falsche Fragestellung. Die richtige Frage ist: Für welche Integration ist welches Muster das effizienteste, und wo braucht man den Agenten überhaupt dauerhaft im Loop?
Wann MCP trotzdem die bessere Wahl ist
MCP hat in bestimmten Szenarien klare Stärken, die CLI nicht replizieren kann.
Dynamic Tool Discovery: In Enterprise-Umgebungen, in denen sich die verfügbaren Tools häufig ändern, also neue APIs, neue Dienste, neue Datenbankschemas, ermöglicht MCP dem Agenten, die aktuelle Tool-Bibliothek ohne manuelle Konfiguration zu entdecken. Das ist besonders relevant für Multi-Agenten-Systeme, in denen Agenten untereinander Capabilities aushandeln.
Governance und Compliance: MCP-Gateways wie Lunar.dev MCPX oder TrueFoundry ermöglichen granulares RBAC (Role-Based Access Control) auf Tool-Ebene, OAuth-2.1-Authentifizierung und vollständige Audit Trails. Das ist in regulierten Branchen keine Kür, es ist Pflicht. CLI-basierte Architekturen haben hier erheblich mehr Implementierungsaufwand.
Nicht-Shell-Umgebungen: Claude Desktop, Browser-basierte Assistenten und ähnliche Clients haben keinen Shell-Zugriff. In diesen Umgebungen ist MCP der einzige Weg, Agenten mit externen Tools zu verbinden.
Wird der Token-Overhead beherrschbar?
Erste Ansätze deuten darauf hin. Tool-Search-Features, wie sie Claude Sonnet 4+ und Opus 4+ bereits standardmäßig unterstützen, senken den Kontext-Overhead für MCP-Tools von 50.000 bis 100.000 Tokens auf etwa 8.700, unabhängig davon, wie viele Server verbunden sind. Wenn die offizielle MCP-Spezifikation diesen Weg weitergeht und On-Demand Tool Discovery zum Standard wird, könnte sich das Kosten-Nutzen-Verhältnis für moderate Tool-Sets grundlegend ändern. MCP ist ein lebendes Protokoll, und die Frage ist nicht, ob es sich weiterentwickelt, sondern ob es schnell genug passiert.
Die Hybridstrategie: Das pragmatische Fazit
Was sich in der Praxis als effektivstes Muster herausschält, ist keine Entweder-oder-Entscheidung. Die produktivsten Agenten-Architekturen 2026 kombinieren alle drei Muster und entscheiden situativ.
CLI für bekannte Tools, also git, bash, python, kubectl, docker, jq, sed. Alles, was LLMs aus dem Training kennen. Hier ist CLI 10- bis 32-mal effizienter als MCP, und der Schema-Overhead entfällt vollständig. Das ist das Standardmuster für Coding-Agenten und Developer-Automation.
MCP für dynamische und Enterprise-Integrationen, also Systeme mit häufig wechselnden Schnittstellen-Spezifikationen, bei denen Dynamic Tool Discovery den entscheidenden Vorteil bringt. Ebenso für Umgebungen mit Governance-Anforderungen: OAuth-Authentifizierung, granulares RBAC und Audit Trails. Wenn sich APIs schnell ändern und der Agent die aktuelle Tool-Landschaft selbst entdecken muss, spielt MCP seine Stärke aus.
Selbstheilende Pipelines für Produktionsprozesse, überall dort, wo Prozesse im Normalbetrieb ohne Agent laufen sollen und KI-Kosten nur im Fehlerfall anfallen dürfen. Legacy-Systeme, Industrie-APIs, Datenpipelines mit regelmäßigen Schema-Änderungen. Das Try-Heal-Retry-Pattern mit Repair Agents und Monitoring Agents ist hier das Mittel der Wahl.
Was das für Unternehmen bedeutet, besonders für die Energiebranche
Das Problem dahinter: Die Token-Effizienz-Debatte klingt nach einem Infrastrukturthema für KI-Startups, trifft aber Unternehmen in klassischen Branchen wie Energie, Utilities, Öl und Gas oder Fertigungsindustrie besonders hart.
Wenn ein Agent in einer modernen SaaS-Umgebung arbeitet, hat er bekannte Tools wie GitHub, Slack oder Jira und kann zwischen CLI und MCP wählen. Wenn ein Agent in einem Energieunternehmen arbeitet, sieht die Welt anders aus: SCADA-Systeme, Access-Datenbanken aus den 90ern, Alt-Systeme mit proprietären Kommunikationsprotokollen. Es gibt keine Standard-CLI-Tools, die ein Sprachmodell aus dem Training kennt, und es gibt keine vorgefertigten MCP-Server.
Für diese Umgebungen sind selbstheilende Pipelines mit Repair Agents oft die einzige praktikable Option. Die regulären Prozesse laufen ohne Agent, also Datenimporte, Transformationen, Schnittstellen-Aufrufe. Erst wenn etwas bricht, greift ein spezialisierter Agent ein, diagnostiziert das Problem und repariert die Schnittstelle. Das verlangt von Unternehmen eine klare Antwort auf die Governance-Frage: Welche Änderungen darf ein Agent autonom durchführen? Wo werden Reparaturen dokumentiert? Und ab welchem Schweregrad braucht es einen menschlichen Review-Prozess? Das ist kein technisches Problem, es ist ein Organisationsproblem. Und Unternehmen, die das jetzt nicht adressieren, bauen Agenten-Architekturen, die niemand mehr versteht und irgendwann niemand mehr kontrolliert.
Die eigentliche Frage
MCP ist alles andere als tot. Die 2026-Roadmap des Protokolls adressiert das Token-Problem durch Server-Cards, On-Demand Tool Discovery und horizontale Skalierbarkeit. Die Linux Foundation hat MCP als offiziellen Standard übernommen, die Adoption steigt.
Aber das Signal, das Perplexitys CTO gesendet hat, ist real: Protokolle, die im Prototyp glanzvoll sind und in der Produktion kosten, überleben nur, wenn die Community das Problem schnell genug löst. CLI ist nicht die Zukunft, es ist die pragmatische Gegenwart für alle, die heute produktive Agenten-Systeme bauen müssen. Und selbstheilende Pipelines zeigen, dass die kosteneffizienteste Lösung manchmal darin besteht, den Agenten gar nicht erst dauerhaft einzusetzen.
Wer 2026 ernsthaft mit KI-Agenten arbeitet, kommt an einer Architekturentscheidung nicht vorbei: Welches Integrationsmuster passt zu welchem Use Case? Welche Token-Kosten sind akzeptabel? Welche Governance-Anforderungen stellt meine Branche? Und: Darf mein Agent seine eigenen Schnittstellen reparieren, und wenn ja, unter welchen Bedingungen?
Wer das heute nicht entscheidet, bekommt es 2027 als strategisches Problem zurück.
Für Fragen steht Ihnen gerne zur Verfügung:
Kevin Goldermann
Leiter Kompetenzteam IT & Datenmanagement
E-Mail
Quellen
- Why Perplexity Is Moving Away from MCP
- Why CLI Tools Are Beating MCP for AI Agents – Jannik Reinhard
- Show HN: mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
- MCP vs CLI: Benchmarking AI Agent Cost & Reliability – Scalekit
- Playwright CLI: The Token-Efficient Alternative to Playwright MCP
- Building a Self-Healing Data Pipeline That Fixes Its Own Python Errors – Towards Data Science
- MCP is Dead; Long Live MCP! – Charles Chen
- Code execution with MCP: building more efficient AI agents – Anthropic
- Six Fatal Flaws of the Model Context Protocol (MCP)
- MCP's 2026 Roadmap – WorkOS
