CLI oder MCP: Wann nutzt du was?

Frage	Eher CLI	Eher MCP
Wird das Tool nur manchmal gebraucht?	Ja	Eher nein
Soll es in fast jedem Chat bereitstehen?	Eher nein	Ja
Ist Token-Effizienz wichtig?	Ja	Nur mit sauberer Tool-Auswahl
Soll der Agent Befehle, Dateien und Logs direkt prüfen?	Ja	Teilweise
Brauchst du eine standardisierte Tool-Oberfläche für viele Agenten?	Teilweise	Ja
Soll ein Team dieselbe Integration wiederverwenden?	Möglich	Oft besser

Eine CLI wird nur aufgerufen, wenn sie gebraucht wird.

Der Agent kann zum Beispiel sagen: „Ich brauche jetzt Screenshot-Analyse“, ruft ein CLI-Tool auf, liest die Ausgabe und arbeitet weiter. Vorher nimmt dieses Tool keinen Platz im Kontextfenster ein.

Das ist der große Vorteil: Die Fähigkeit liegt bereit, aber sie belastet nicht jeden Chat.

Bei MCP ist das anders. Ein MCP-Server stellt dem Agenten Tools, Beschreibungen und Schemas bereit. Je nach Oberfläche und Konfiguration werden diese Informationen beim Chatstart oder beim Tool-Setup in den Kontext geladen. Das kostet Tokens und Aufmerksamkeit im Modell, auch wenn du den MCP in diesem Chat gar nicht brauchst.

Das heißt nicht, dass MCP schlecht ist. Es heißt nur: Für selten genutzte Spezialtools ist MCP oft zu schwergewichtig.

Viele denken bei CLI sofort: „Dann muss ich selbst Terminalbefehle lernen.“

Das ist nur teilweise richtig.

Wenn du allein ohne Agent arbeitest, ja: Dann bedienst du die CLI direkt. In einem Agenten-Workflow ist die CLI aber oft nur die Schnittstelle, die der Agent nutzt. Du formulierst die Aufgabe in normaler Sprache, und der Agent führt den passenden Befehl aus.

Beispiel:

Prüfe bitte, ob die lokale Website läuft, und sag mir, welche Fehler im Build auftauchen.

Der Agent kann dann selbst Befehle wie npm run build, curl, git status oder ein spezialisiertes CLI-Tool ausführen. Du siehst am Ende nicht „Terminalarbeit“, sondern ein geprüftes Ergebnis.

Eine CLI ist meist besser, wenn:

• das Tool nur gelegentlich gebraucht wird
• der Agent es bei Bedarf selbst aufrufen kann
• du konkrete Ausgaben, Dateien, Logs oder Fehlercodes brauchst
• das Tool gut dokumentierte Befehle hat
• du Workflows skripten oder wiederholen willst
• Token-Effizienz wichtiger ist als permanente Sichtbarkeit im Chat

Typische Beispiele:

• GitHub über gh
• lokale Builds und Tests
• Dateikonvertierung
• Screenshot- oder Browser-Helfer
• Export- und Backup-Skripte
• interne Tools mit klaren Befehlen

Der Agent braucht dafür nur genug Anleitung: Wie heißt das Tool? Welche Befehle sind erlaubt? Was darf es nicht tun? Wo liegen sensible Grenzen?

Das kann in einer kurzen Projektanweisung, einem AGENTS.md, einer Skill-Datei oder einer kleinen Tool-Notiz stehen.

MCP ist meist besser, wenn:

• ein Tool in vielen Chats regelmäßig gebraucht wird
• mehrere Agenten dieselbe Integration nutzen sollen
• die Tool-Funktionen stark strukturiert sind
• Berechtigungen und Toolgrenzen sauber über den Server modelliert werden sollen
• der Agent nicht nur Befehle ausführen, sondern eine standardisierte Tool-Liste sehen soll
• eine Oberfläche MCP nativ unterstützt und du die Integration bewusst aktiv hältst

Typische Beispiele:

• Dateisystemzugriff in einem definierten Workspace
• Browser-Automation mit klaren Aktionen
• Datenbankzugriff mit begrenzten Queries
• interne Business-Systeme mit kontrollierten Funktionen
• Team-Setups, in denen viele Nutzer dieselbe Verbindung brauchen

MCP lohnt sich also dann, wenn die dauerhafte Verfügbarkeit den Kontextverbrauch rechtfertigt.

Ein Agent kann nur eine begrenzte Menge Kontext gleichzeitig sehen. Dazu gehören deine Aufgabe, bisherige Chat-Nachrichten, Dateien, Systemanweisungen und Toolbeschreibungen.

Wenn viele MCP-Tools geladen sind, konkurrieren deren Beschreibungen mit dem eigentlichen Arbeitskontext. Das kann dazu führen, dass der Agent mehr Tokens verbraucht oder schlechter priorisiert.

Eine CLI ist hier oft schlanker: Der Agent muss nicht jedes mögliche Werkzeug permanent im Kontext halten. Er kann bei Bedarf tool --help, eine kurze Skill-Anweisung oder einen konkreten Befehl nutzen.

Merksatz:

MCP macht Tools sichtbar. CLI macht Tools abrufbar. Sichtbarkeit kostet Kontext. Abrufbarkeit kostet erst dann, wenn du sie nutzt.

Es gibt inzwischen Tools, die genau diese Lücke schließen: MCP-Funktionen werden nicht dauerhaft als Chat-Tools geladen, sondern bei Bedarf über eine CLI aufgerufen.

Beispiele:

• mcp2cli: macht MCP-Server, OpenAPI-Spezifikationen oder GraphQL-Endpunkte zur CLI, damit Agenten Tools bei Bedarf abrufen können.
• mcp-cli: erlaubt Agenten, MCP-Server über CLI-Befehle zu inspizieren und aufzurufen, statt alle Schemas dauerhaft in den Chat zu laden.
• Peter Steinbergers MCP-Helper-Gist: zeigt den Ansatz, MCPs über CLI-Kommandos und progressive Offenlegung nutzbar zu machen.

Auch Peter Steinbergers Peekaboo ist ein gutes Beispiel für CLI-first-Denken: Ein visuelles Tool kann vom Agenten bei Bedarf aufgerufen werden, ohne dauerhaft als schweres MCP-Tool im Kontext zu liegen.

Du musst diese Tools nicht sofort nutzen. Wichtig ist der Gedanke: Nicht jede Integration muss permanent als MCP geladen sein. Manche Fähigkeiten sind als CLI viel sparsamer.

Nutze diese Reihenfolge:

1. Braucht der Agent das Tool nur manchmal? Dann starte mit CLI.
2. Kann der Agent das Tool sicher per Befehl aufrufen? Dann bleib bei CLI.
3. Muss das Tool in vielen Chats sofort sichtbar sein? Dann prüfe MCP.
4. Verbraucht der MCP viel Kontext, wird aber selten genutzt? Dann prüfe CLI oder MCP-über-CLI.
5. Braucht ein Team standardisierte Rechte und Funktionen? Dann ist MCP oft besser.

GitHub

Für viele Aufgaben reicht die GitHub-CLI gh: Issues lesen, PRs prüfen, Branches ansehen, Kommentare holen. Ein Agent kann diese Befehle direkt ausführen und die Ausgabe auswerten.

Ein GitHub-MCP kann trotzdem sinnvoll sein, wenn dein Setup stark auf Tool-Calls ausgelegt ist oder du GitHub in vielen Chats ständig brauchst. Für gelegentliche Repository-Arbeit ist CLI oft schlanker.

Screenshots und UI-Prüfung

Ein Screenshot-Tool als CLI kann der Agent genau dann starten, wenn er eine visuelle Prüfung braucht. Das ist effizient, weil die Fähigkeit nicht jeden Chat belastet.

Ein MCP für Browser- oder UI-Automation lohnt sich eher, wenn du viele wiederholte Browser-Aktionen brauchst und die Oberfläche die Tool-Calls sauber unterstützt.

Interne Business-Tools

Wenn ein internes Tool klare Befehle hat, kann eine CLI reichen: Daten exportieren, Report erzeugen, Status prüfen.

Wenn mehrere Agenten kontrolliert auf dasselbe System zugreifen sollen, mit klaren Berechtigungen und stabiler Toolbeschreibung, ist MCP oft die bessere Architektur.

Du musst nicht „CLI oder MCP“ als Glaubensfrage entscheiden.

Die bessere Frage ist:

Soll der Agent diese Fähigkeit permanent sehen oder nur bei Bedarf abrufen?

Wenn sie permanent sichtbar sein soll, nimm MCP. Wenn sie nur gelegentlich gebraucht wird, ist CLI oft einfacher, günstiger und token-effizienter.

• Was ist eine CLI? Kommandozeile einfach erklärt für AI-Agenten
• MCP erklärt: So verbindest du Claude mit externen Tools und Datenquellen
• API-Anbindung mit Claude: So verbindest du jedes Tool Schritt für Schritt
• OpenAI Codex erklärt: Der AI-Coding-Agent von OpenAI im Überblick
• Datenschutz und Connectors: Was kann Claude sehen und wie schützt du dich?