CLI vs. MCP: Was ist 2026 der bessere Ansatz für AI-Agents?

Kaum eine Frage beschäftigt den Agent-Bau 2026 so sehr wie diese: Sollen AI-Agents ihre Tools über das Model Context Protocol (MCP) bekommen – den Standard, den Anthropic Ende 2024 vorstellte – oder reicht ihnen eine schlichte Kommandozeile, ein CLI-Tool, das sie wie ein Mensch aufrufen? Die Debatte wird hart geführt, oft mit spektakulären Zahlen: 98 Prozent weniger Tokens, 32-mal günstiger. Die meisten davon sind echt – und trotzdem führt die Frage in die Irre.

Denn „CLI vs. MCP“ stellt zwei Dinge gegeneinander, die auf verschiedenen Ebenen liegen. MCP hat den Standardisierungskampf längst gewonnen. Was die Branche gerade verwirft, ist nicht MCP selbst, sondern die naive Art, wie Agents MCP zunächst genutzt haben. Wer die Zahlen richtig liest, sieht keinen Sieger, sondern eine Arbeitsteilung.

Was MCP gewonnen hat

MCP ist innerhalb eines Jahres zum De-facto-Standard geworden, wie es in der jungen KI-Branche selten etwas wird. Am 9. Dezember 2025 übergab Anthropic das Protokoll an die neu gegründete Agentic AI Foundation unter dem Dach der Linux Foundation – mitgetragen von Block und OpenAI, unterstützt von Google, Microsoft, AWS, Cloudflare und Bloomberg. Zu diesem Zeitpunkt waren „more than 10,000“ öffentliche MCP-Server veröffentlicht. Ein herstellerneutraler Standard mit dieser Reichweite verschwindet nicht wieder.Quelle: Linux Foundation, Formation of the Agentic AI Foundation, 09.12.2025

Das Problem: MCPs Invocation-Modell

Der Standard ist das eine, die Art der Nutzung das andere. Das ursprüngliche MCP-Modell lädt die Definitionen aller verbundenen Tools vorab in den Context – bevor der Agent überhaupt die erste Anweisung liest. Anthropic beschreibt das Problem in einem eigenen Engineering-Beitrag deutlich: Bei vielen verbundenen Tools könnten so „hundreds of thousands of tokens“ anfallen, ehe eine Anfrage bearbeitet wird. Dazu kommt ein zweiter Kostenblock: Jedes Zwischenergebnis läuft durch das Modell zurück – ein zweistündiges Meeting-Transkript zwischen zwei Tool-Calls kann allein rund 50.000 zusätzliche Tokens bedeuten.Quelle: Anthropic Engineering, Code execution with MCP, 04.11.2025

Simon Willison, einer der aufmerksamsten Beobachter der Szene, formulierte es im Oktober 2025 so: Der offizielle GitHub-MCP-Server „famously consumes tens of thousands of tokens of context“. Sein Fazit fiel entsprechend aus: „Almost everything I might achieve with an MCP can be handled by a CLI tool instead.“ Ein LLM weiß ohnehin, wie man ein CLI-Tool mit --help erkundet – dafür braucht es keine vorab geladenen Schemata.Quelle: Simon Willison, 16.10.2025

Der Fix: Code Execution statt Tool-Flut

Die Antwort, auf die sich Anthropic und Cloudflare unabhängig voneinander zubewegten, heißt Code Execution: Statt alle Tools vorab zu laden und jedes Ergebnis durchs Modell zu schleifen, bekommt der Agent eine Sandbox und schreibt Code, der nur die gerade benötigten Tools on demand lädt. Anthropic beziffert die Ersparnis an einem Beispiel-Workflow (Google Drive nach Salesforce) mit einem Sturz von 150.000 auf 2.000 Tokens – 98,7 Prozent. Wichtig, und Anthropic sagt es selbst: Das ist ein illustratives Beispiel, kein Benchmark, und es „requires a secure execution environment with … sandboxing“; der Nutzen „should be weighed against these implementation costs“.Quelle: Anthropic Engineering, Code execution with MCP, 04.11.2025

Cloudflare geht mit „Code Mode“ noch weiter: Über nur zwei Tools – search() und execute() in einer V8-Isolate-Sandbox – stellt es die komplette Cloudflare-API mit über 2.500 Endpoints in rund 1.000 Tokens bereit, statt geschätzter 1,17 Millionen. Das sind 99,9 Prozent weniger. Auch diese Zahl ist vom Hersteller an der eigenen API gemessen, und die 1,17 Millionen sind eine Schätzung: Die Richtung ist eindeutig, die exakte Zahl gilt für genau diesen Fall.Quelle: Cloudflare, Code Mode, 20.02.2026

Realitäts-Check: weniger Tokens sind nicht automatisch besser

Wer daraus „CLI schlägt MCP“ macht, verkürzt. Der bislang sauberste kontrollierte Vergleich stammt von Mario Zechner (August 2025): Er ließ denselben Coding-Agent einmal über MCP und einmal über CLI dieselben Aufgaben lösen. Beide erreichten 100 Prozent Erfolg, die Kosten waren praktisch gleich (19,45 gegen 19,95 US-Dollar) – und die MCP-Variante war sogar 23 Prozent schneller (51 gegen 66 Minuten). Zechners Schluss: „The protocol is just plumbing.“ Entscheidend sei das Tool-Design, nicht das Protokoll.Quelle: Mario Zechner, MCP vs CLI, 15.08.2025

Bei den reinen Tokens liegt die CLI dagegen oft klar vorn. Ein reproduzierbarer Benchmark von Scalekit (Claude Sonnet 4, GitHub-Aufgaben, beide mit 100 Prozent Erfolg) zeigt je nach Aufgabe 1,3- bis 80-mal weniger Tokens für die CLI – etwa 1.365 gegen 27.313 beim Abruf von Repo-Infos, 4.998 gegen 400.013 beim Zusammenfassen von Pull Requests. Doch weniger Tokens heißt nicht schneller: In einem Playwright-Test von Outpost/Ranger war die token-schlanke CLI rund doppelt so langsam wie MCP (240–304 gegen 90–120 Sekunden), weil sie Ergebnisse in Dateien schrieb und dadurch mehr Round-Trips brauchte. Die Autorin hält ausdrücklich fest, es sei „not really a comparison of MCPs vs CLIs“ – sondern der konkreten Interface-Entscheidungen der beiden Tools.Quelle: Scalekit, mcp-vs-cli-benchmark (GitHub) · Outpost/Ranger, 03.04.2026

Wann CLI besser ist – und wann MCP

Damit lässt sich die eigentliche Frage endlich konkret beantworten. Code und CLI spielen ihre Stärke aus, wenn viele Tools im Spiel sind, wenn Schritte verkettet oder große Zwischenergebnisse gefiltert werden müssen, und wenn das Tool ohnehin schon als Kommandozeile existiert – ein Modell bedient git, gh oder curl, ohne dass man ihm dutzende Schemata vorlädt. Armin Ronacher bringt es in „Your MCP Doesn't Need 30 Tools: It Needs Code“ auf den Punkt: Statt 30 einzelner Tools reiche oft ein einziges, das Code entgegennimmt und ausführt.Quelle: Armin Ronacher, 18.08.2025

MCP ist die bessere Wahl, wenn das Tool-Set klein und sauber geschnitten ist – dann sind die Schema-Kosten vernachlässigbar und der direkte Aufruf ist schneller und einfacher (bei Zechner war MCP 23 Prozent schneller). Es gewinnt außerdem dort, wo es um Interoperabilität geht – ein Tool, das viele verschiedene Agents nutzen sollen – sowie bei Multi-User-Auth, Governance und Auditierbarkeit. Ein oft übersehener Punkt: MCP hält Zustand, eine CLI nicht. Ronacher weist ausdrücklich darauf hin, dass Shell-Tools zustandslos sind, MCP dagegen „stateful out of the box“ – eine CLI muss ihren Context bei jedem Aufruf neu aufbauen, was ihn schnell teurer macht als MCPs Overhead. Und ohne sichere Sandbox für Code-Ausführung ist der direkte Tool-Call ohnehin die risikoärmere Option.Quelle: Mario Zechner, 15.08.2025 · Armin Ronacher, 18.08.2025

Was „gutes Tool-Design“ konkret heißt

Wenn das Tool-Design entscheidet, lohnt der Blick darauf, was gutes Design ausmacht – Anthropic hat die eigenen Erkenntnisse dazu veröffentlicht. Erstens: wenige, hochwirksame Tools statt dünner API-Wrapper – ein schedule_event statt getrennter list_users, list_events und create_event. Zweitens: klare, mit Präfixen gruppierte Namen (asana_search, jira_search), damit der Agent nicht zwischen ähnlichen Tools rät. Drittens: Ergebnisse in menschenlesbarer Form zurückgeben, nicht als kryptische UUIDs – laut Anthropic steigert das die Trefferquote des Modells messbar.Quelle: Anthropic Engineering, Writing effective tools for AI agents, 11.09.2025

Den größten Hebel hat der Rückgabewert. Tools sollten paginieren, filtern und kürzen und über einen Parameter wie response_format eine knappe statt vollständige Antwort erlauben – in Anthropics Beispiel braucht die knappe Variante nur rund ein Drittel der Tokens. Dass diese Denkweise trägt, stützt auch die peer-reviewte Arbeit CodeAct (ICML 2024): Über 17 LLMs erzielt ausführbarer Code als Action-Space bis zu 20 Prozent höhere Erfolgsraten als JSON-Tool-Calling, weil sich Schleifen und mehrere Tools in einem Schritt verbinden lassen. Das eigentliche Problem sind schlecht gebaute Tools, die bei jedem Aufruf unnötiges JSON auskippen – nicht das Protokoll.Quelle: Anthropic Engineering, Writing effective tools for AI agents, 11.09.2025 · CodeAct (arXiv:2402.01030)

Wenn du bei MCP bleibst: die Token-Last senken

Wer klassisches MCP nutzt, muss die aufgeblähten Kosten nicht hinnehmen. Anthropics Tool Search lädt Tool-Definitionen erst bei Bedarf: Statt rund 72.000 Tokens für über 50 MCP-Tools fallen nur noch etwa 8.700 an – 85 Prozent weniger –, und die Tool-Auswahl wird dabei sogar genauer (Opus 4.5 stieg von 79,5 auf 88,1 Prozent). Programmatic Tool Calling, das Zwischenergebnisse in einer Sandbox statt im Context hält, senkt den Verbrauch zusätzlich um rund 37 Prozent. On-demand-Laden ist also kein Bruch mit MCP, sondern seine ausgereiftere Nutzung.Quelle: Anthropic Engineering, Advanced tool use, 24.11.2025

Die Kehrseite: Sicherheit

Ein Punkt, den die Effizienz-Debatte gern übergeht, ist Sicherheit – und hier hat MCP eine ernste Kehrseite. Weil Tool-Beschreibungen direkt ins Modell fließen, sind sie ein Einfallstor: Beim Tool Poisoning schmuggelt eine manipulierte Beschreibung Anweisungen ein, beim Rug Pull ändert ein Server sein Tool nach der Freigabe, und beim Confused-Deputy-Problem wird ein Agent mit weitreichenden Rechten dazu gebracht, sie im Sinne eines Angreifers zu nutzen. Das OWASP-Projekt führt diese Risiken samt Gegenmaßnahmen: OAuth 2.1 mit PKCE und eng gefasste, pro Server getrennte Scopes; Tool-Definitionen per Hash pinnen und auf Änderungen alarmieren; bei destruktiven Aktionen eine menschliche Bestätigung verlangen; und jede Tool-Ausgabe als nicht vertrauenswürdigen Input behandeln, bevor sie zurück ins Modell geht.Quelle: OWASP, MCP Security Cheat Sheet

Die Architektur, die 2026 bleibt

Setzt man die Belege zusammen, ergibt sich kein Entweder-oder, sondern ein Stack. MCP ist die Interoperabilitäts-Schicht – der Standard, über den Agents und Tools sich überhaupt finden. Code Execution und CLI sind die Runtime – die Art, wie der Agent die Arbeit tatsächlich erledigt. Direktes JSON-Tool-Calling bleibt sinnvoll dort, wo es nur wenige Tools gibt. Anthropic selbst formuliert es an seinen Agent Skills so: Skills „complement Model Context Protocol (MCP) servers“ – MCP legt die Fähigkeiten offen, Skills und Code kodieren die Arbeitsabläufe, on demand geladen, um den Context zu schonen.Quelle: Anthropic Engineering, Agent Skills, 16.10.2025

Genau so bauen es die großen Agents auch. Claude Code, OpenAI Codex CLI, Cursor, GitHub Copilot, Gemini CLI und Devin sprechen alle MCP – und erledigen die eigentliche Arbeit über Terminal, Code-Ausführung und Dateisystem. Wer heute einen Agent baut, wählt nicht CLI oder MCP. Er nutzt MCP, um Tools anzubinden, und Code, um sie zu benutzen.

Fazit

Die ehrliche Antwort auf „CLI oder MCP?“ lautet nicht „das eine gewinnt“, sondern „wofür welches“. Die spektakulären Token-Zahlen – 98,7 Prozent bei Anthropic, 99,9 Prozent bei Cloudflare – sind real, aber vom Hersteller an ausgewählten Workflows gemessen; sie beweisen, dass on-demand geladene Tools den Context im großen Maßstab drastisch entlasten, nicht dass ein Protokoll dem anderen überlegen ist. Die entscheidende Variable, auf die fast jede saubere Messung zeigt, ist das Tool-Design – nicht das Protokoll.