MCP vs. CLI: Wo AI-Agenten wirklich effizient werden

Christoph (CTO @ Basilicom)

Wer sich in den vergangenen Monaten mit AI-Agenten beschäftigt hat, kommt an einem Thema nicht vorbei: Wie verbindet man ein Sprachmodell mit der realen Welt? Wie gibt man ihm Zugriff auf Datenbanken, APIs, Dateisysteme oder Build-Pipelines? Die Antwort, die man derzeit am häufigsten hört, lautet: MCP - das Model Context Protocol.

MCP ist ein offener Standard, den Anthropic Ende 2024 vorgestellt hat. Die Idee ist bestechend: Ein einheitliches Protokoll, über das AI-Modelle strukturiert mit beliebigen externen Tools kommunizieren. Ein MCP-Server beschreibt seine Fähigkeiten in einem maschinenlesbaren Schema, der Agent wählt das passende Tool, übergibt Parameter, bekommt eine strukturierte Antwort. Sauber, standardisiert, erweiterbar.

In der Theorie klingt das überzeugend. In der Praxis haben wir - und offenbar nicht nur wir - eine differenziertere Sicht entwickelt.

Das Context-Window-Problem

Der Punkt, an dem MCP in der praktischen Arbeit am deutlichsten an Grenzen stößt, ist die Token-Effizienz. Ein Aspekt, der in der Begeisterung über das Protokoll oft untergeht.

Jeder MCP-Server injiziert bei der Verbindung ein Tool-Schema in das Context Window des Modells. Das umfasst Tool-Namen, Parameterbeschreibungen, Typ-Definitionen, Enums, Authentifizierungshinweise. Pro Tool können das je nach Komplexität zwischen 550 und 1.400 Tokens sein. Das klingt zunächst überschaubar - bis man sich anschaut, wie viele Tools ein typischer MCP-Server mitbringt.

Der GitHub-MCP-Server z.B. exponiert aktuell über 50 Tools - es waren einmal über 100. Wer drei oder vier MCP-Server anbindet - GitHub, eine Datenbank, Microsoft Graph, vielleicht noch Jira - landet schnell bei einem sehr großen Token Overhead. Und zwar bevor der Agent auch nur eine einzige Frage bearbeitet hat. Transparenzhinweis: Ja, GitHub kennt das Problem, ein dynamisches Tool-Loading existiert zumindest als Beta. 

Aber das ist dennoch kein theoretisches Problem. Aktuelle Benchmarks zeigen, dass MCP-basierte Tool-Schemas in typischen Deployments einen großen Teil des verfügbaren Kontexts konsumieren können. Tokens sind aber kein reiner Kosten-Indikator - sie bestimmen direkt, wie viel Reasoning-Kapazität dem Modell für die eigentliche Aufgabe bleibt. Weniger verfügbarer Kontext bedeutet schlechtere Ergebnisse bei komplexen, mehrstufigen Aufgaben.

Die Alternative, die es schon immer gab

Die nüchterne Gegenfrage lautet: Braucht man für viele dieser Aufgaben überhaupt ein Protokoll? Oder reicht eine Shell?

Sprachmodelle wurden auf Milliarden von Terminal-Interaktionen trainiert - Stack-Overflow-Antworten, GitHub-Repositories, Dokumentationen, Tutorials. Wenn man ein Modell bittet, git, docker, kubectl oder gh zu benutzen, greift es auf tief internalisierte Muster zurück. Es braucht kein Schema, um zu wissen, wie git log --oneline -10 funktioniert.

Das ist ein Punkt, der leicht unterschätzt wird. Ein MCP-Server präsentiert dem Modell ein proprietäres Schema, das es zum ersten Mal zur Laufzeit sieht. Das Modell muss verstehen, welches Tool was tut, wie die Parameter heißen, welche Werte zulässig sind - und das alles on-the-fly. Bei einem CLI-Befehl wie docker ps --filter "status=running" entfällt dieser Interpretationsschritt vollständig. Das Modell kennt den Befehl, kennt die Flags, kennt die Ausgabeformate. Das spart nicht nur Tokens, sondern reduziert auch die Fehlerrate bei der Tool-Nutzung.

Der Token-Unterschied ist dabei erheblich. Ein typischer GitHub-MCP-Server bringt Dutzende Tools mit, deren Schema-Definitionen schnell auf fünfstellige Token-Zahlen kommen (Schema-Injektion, Reasoning, mehrere Tool-Calls, Response-Parsing), erledigt ein CLI-basierter Ansatz mit gh und einer Pipeline dieselbe Aufgabe in etwa 4.000 Tokens (ScaleKit Artikel). Das ist nicht eine marginale Verbesserung - das ist eine Größenordnung. Unabhängige Benchmarks kommen auf vergleichbare Ergebnisse: CLI-basierte Agenten arbeiten je nach Szenario 4- bis 32-mal token-effizienter als ihre MCP-Pendants.

Ein weiterer Vorteil von CLI-Tools: Composability. Die Unix-Philosophie - kleine Programme, die eine Sache gut machen und sich über Pipes verketten lassen - passt bemerkenswert gut zu der Art, wie AI-Agenten arbeiten. Ein Agent, der az vm list mit jq filtert und das Ergebnis per xargs an einen weiteren Befehl weitergibt, komponiert eine Daten-Pipeline aus Standardbausteinen. Mit MCP müsste derselbe Agent mehrere strukturierte Tool-Calls orchestrieren, Zwischenzustände verwalten und mit unterschiedlichen Response-Formaten umgehen.

Dieser Befund wird zunehmend auch von größeren Akteuren bestätigt. Perplexity hat im März 2026 angekündigt, intern teilweise von MCP auf REST-APIs und CLI-Tools umzustellen. Die Begründung: zu hoher Context-Window-Overhead und zu viel Reibung bei der Authentifizierung.

Was das für unsere Arbeit bedeutet

Bei Basilicom arbeiten wir seit über 25 Jahren mit komplexen Datenlandschaften. Unser Schwerpunkt - PIM, DAM, MDM auf Basis von Pimcore - dreht sich im Kern um die Frage, wie man Daten effizient strukturiert, transformiert und in verschiedene Kanäle ausspielt. Die Systemlandschaften unserer Kunden sind dabei selten trivial: ERP-Anbindungen, Multi-Channel-Ausspielungen, komplexe Datenmodelle mit Tausenden von Attributen und Relationen.

Wenn wir AI-gestützte Automatisierung in diesen Kontext einbringen, stellt sich dieselbe Frage wie überall: Wie integriert man Agenten sinnvoll in bestehende Systemlandschaften?

Pimcore bringt eine leistungsfähige Console-CLI mit, die auf der Symfony-Console-Komponente basiert. Datenimporte, Asset-Verarbeitung, Index-Rebuilds, Workflow-Operationen - all das lässt sich headless über bin/console-Befehle steuern. In Kombination mit der PHP-API gibt es kaum eine Operation, die sich nicht per CLI automatisieren ließe.

Für einen AI-Agenten, der in einer Pimcore-Umgebung Aufgaben erledigen soll, ist das ein erheblicher Vorteil. Statt einen spezifischen MCP-Server zu bauen und zu pflegen, der das gesamte Pimcore-Datenmodell als Tool-Schema exponiert, kann der Agent direkt auf bekannte CLI-Patterns zurückgreifen. Der Kontext-Overhead sinkt, die Composability steigt - weil der Agent Standard-Unix-Werkzeuge wie jq, grep oder xargs nutzen kann, um Ergebnisse zu filtern und weiterzuverarbeiten.

Ein konkretes Beispiel: Ein Agent soll prüfen, welche Produkte in einer Pimcore-Instanz unvollständige Datensätze haben - fehlende Bilder, leere Pflichtfelder, inkonsistente Übersetzungen. Per CLI lässt sich das über einen maßgeschneiderten Console-Command lösen, dessen Ausgabe der Agent direkt verarbeitet. Das gesamte Szenario - Abfrage, Filterung, Report-Erstellung - kommt mit wenigen Tausend Tokens aus. Ein äquivalenter MCP-Ansatz müsste zunächst das komplette Datenmodell als Schema exponieren, was bei einem umfangreichen PIM schnell fünfstellige Token-Zahlen erreicht.

Das ist im Übrigen kein Pimcore-spezifisches Argument. Es gilt für jede Integration, bei der ein etabliertes CLI-Tool existiert: az für Azure, aws für AWS, gh für GitHub, psql für PostgreSQL.

Und es betrifft auch die Wartbarkeit. Ein CLI-Befehl in einem Shell-Script ist transparent, versionierbar und debugbar. Ein MCP-Server ist ein zusätzlicher Dienst, der deployed, überwacht und gepflegt werden will. Für Teams, die ohnehin komplexe Infrastruktur betreuen, ist das ein relevanter Faktor.

Wo MCP trotzdem richtig ist

Das heißt nicht, dass MCP keine Berechtigung hat. Es gibt Szenarien, in denen das Protokoll klare Vorteile bietet.

In Multi-Tenant-Umgebungen, wo feingranulare Berechtigungssteuerung auf Tool-Ebene notwendig ist, bietet MCP mit seinem Capability-Negotiation-Mechanismus eine saubere Lösung. In Produktionsumgebungen, die strikte Input-Validierung und Audit-Trails erfordern, verhindert MCP, dass ein Agent fehlerhafte Befehle absetzt. Die OAuth-2.1-Authentifizierung ist ein solides Sicherheitsfundament. Wenn ein Tool für viele unterschiedliche Akteure arbeitet. geht aktuell kein Weg an MCP vorbei.

Ebenso gibt es Dienste, die schlicht kein CLI haben - Figma, Notion, diverse interne APIs. Hier ist MCP oft der pragmatischste Integrationsweg.

Und schließlich: Tool-Discovery. Wenn ein Agent zur Laufzeit herausfinden muss, welche Werkzeuge ihm überhaupt zur Verfügung stehen, liefert MCP mit seinem Endpoints eine strukturierte Antwort. CLI setzt voraus, dass der Agent bereits weiß, was installiert ist oder wir die Liste liefern.

Unser Ansatz

Wir sehen das Thema nicht als Entweder-oder. Der pragmatische Ansatz, den wir bei Basilicom verfolgen, lässt sich auf eine einfache Heuristik bringen: Wenn ein bewährtes CLI-Tool existiert, nutzen wir es. Wenn die Anforderungen nach strukturierter Zugriffskontrolle, dynamischer Tool-Discovery oder formaler Schema-Validierung verlangen, setzen wir MCP ein.

In der konkreten Projektarbeit heißt das: Für Daten-Pipelines, Pimcore-Operationen und Infrastruktur-Aufgaben arbeiten Agenten bei uns primär CLI-basiert. Für die Anbindung an SaaS-Dienste oder in Szenarien mit komplexen Berechtigungsanforderungen evaluieren wir MCP als Integrationsschicht.

Was wir unseren Kunden dabei empfehlen: Messen Sie den Context-Overhead Ihrer Tool-Integrationen. Viele Teams wissen nicht, wie viele Tokens ihre MCP-Server verbrauchen - und wundern sich dann, warum der Agent bei komplexen Aufgaben zunehmend unzuverlässig wird. Ein einfacher Test: Vergleichen Sie die Token-Kosten einer Aufgabe über MCP mit derselben Aufgabe über CLI. Das Ergebnis ist oft ernüchternd, aber aufschlussreich.

Entscheidend ist nicht die Frage, welches Protokoll gerade populär ist. Entscheidend ist, ob der Agent genug Kontext behält, um seine eigentliche Aufgabe gut zu lösen. Wer sein Context Window mit Tool-Schemas füllt, bevor die eigentliche Arbeit beginnt, hat ein Architekturproblem - unabhängig davon, wie elegant das Protokoll dahinter ist.

Die Erfahrung aus unseren Projekten zeigt: Die effektivsten AI-Integrationen sind oft die unspektakulärsten. Ein Agent, der über die Shell eine Pimcore-Console-Aktion auslöst, die Ausgabe mit jq filtert und das Ergebnis in eine CSV schreibt, ist weder besonders aufregend noch besonders neuartig. Aber er funktioniert zuverlässig, ist wartbar und lässt dem Modell maximalen Spielraum für das, was es eigentlich gut kann: Reasoning.

Das Feld entwickelt sich schnell weiter. MCP ist bereits auf dem Weg - schmalere Schemas, dynamisches Tool-Loading, bessere Token-Ökonomie. Das sind technische Probleme, die sich lösen lassen. Gleichzeitig wird die CLI-Welt nicht verschwinden. Im Gegenteil: Die Tatsache, dass jedes Sprachmodell CLI-Befehle aus dem Training kennt, ist ein struktureller Vorteil, der mit jeder Modellgeneration stabiler wird.

Für uns bei Basilicom bedeutet das: Wir beobachten beide Welten, investieren in beide wo es sinnvoll ist, und entscheiden projektbezogen. Dogma hilft niemandem - weder dem Architekten noch dem Agenten.

Am Ende geht es nicht um den raffiniertesten Integrationsweg. Es geht um den kürzesten Weg zwischen Modell und Ergebnis. Und dieser Weg führt, öfter als man denkt, durch das Terminal - Bei Unix ist das übrigens seit über 50 Jahren so :-)