MCP ist tot. Es lebe die CLI

 (ejholmes.github.io)
36 Punkte von GN⁺ 2026-03-02 | 8 Kommentare | Auf WhatsApp teilen
  • MCP verliert in der Branche schnell an Aufmerksamkeit, und nun ist ein CLI-basierter Ansatz praktischer
  • LLMs sind bereits sehr geübt im Umgang mit Kommandozeilen-Tools und können Aufgaben auch ohne separates Protokoll allein mit Dokumentation und CLI ausführen
  • CLI kann von Menschen und LLMs in derselben Umgebung ausgeführt und debuggt werden, was die Ursachenanalyse vereinfacht
  • Auch bei Composability, Authentifizierung und Stabilität ist CLI effizienter als MCP und einfacher zu warten
  • MCP verursacht in der Praxis anhaltende Reibung, etwa durch instabile Initialisierung, wiederholte Re-Authentifizierung und fehlende Zugriffskontrolle
  • In den meisten Fällen ist CLI die einfachere und verlässlichere Wahl, und Unternehmen sollten sich eher auf APIs und CLI-Angebote als auf MCP-Server konzentrieren

Grenzen von MCP und die Überlegenheit der CLI

  • Nach der Ankündigung von Anthropic zum Model Context Protocol (MCP) hat die Branche eilig MCP-Server gebaut, aber wichtige Tools wie OpenClaw und Pi unterstützen es nicht, und ein praktischer Nutzen ist nicht erkennbar
    • LLMs können Aufgaben bereits über CLI und Dokumentation erledigen
    • MCP fügt neue Endpunkte und Authentifizierungsmechanismen hinzu, dupliziert damit aber bestehende Funktionen
  • LLMs sind für die Nutzung von CLI-Tools optimiert und sehr versiert darin
    • Sie wurden auf Millionen von man pages, Stack-Overflow-Antworten und GitHub-Shell-Skripten trainiert
    • Wenn man Claude zum Beispiel den Befehl gh pr view 123 gibt, führt es ihn wie angegeben aus
  • MCP versprach eine sauberere Schnittstelle, in der Praxis müssen Beschreibung, Parameter und Einsatzzeitpunkt jedes Tools jedoch genauso dokumentiert werden

CLI ist auch für Menschen nützlich

  • Mit der CLI können Menschen und LLMs dieselben Befehle teilen
  • Wenn Jira sich unerwartet verhält, kann man denselben Befehl jira issue view direkt ausführen und das Problem reproduzieren
  • Bei MCP existieren Tools nur innerhalb der LLM-Konversation, sodass man bei Problemen mühsam JSON-Übertragungslogs durchsuchen muss
  • Debugging sollte keinen Protokoll-Decoder erfordern
  • Bei CLI sind Ein- und Ausgabe klar, was die Fehlersuche erleichtert

Kombinierbarkeit (Composability)

  • CLI lässt sich über Pipelines mit jq, grep, Dateiumleitungen usw. kombinieren
  • Beispiel für die Analyse großer Terraform-Pläne:
    • terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
  • Mit MCP muss man entweder den gesamten Plan in das Kontextfenster kippen (teuer und oft unmöglich) oder benutzerdefinierte Filterung direkt im MCP-Server implementieren
  • Der CLI-Ansatz nutzt bereits vorhandene, gut dokumentierte Tools, die sowohl Menschen als auch Agenten verstehen können

Authentifizierungsprobleme

  • MCP ist bei der Authentifizierung unnötig meinungsstark (opinionated)
  • CLI-Tools verwenden bereits bewährte Authentifizierungsschemata: aws mit Profilen und SSO, gh mit gh auth login, kubectl mit kubeconfig
  • Ob ein Mensch das Tool direkt nutzt oder Claude es ausführt: Es gilt derselbe Authentifizierungsablauf
  • Wenn es Authentifizierungsprobleme gibt, lassen sie sich mit bestehenden Verfahren wie aws sso login oder gh auth refresh beheben, ohne MCP-spezifisches Troubleshooting

Betriebliche Probleme: keine beweglichen Teile (No Moving Parts)

  • Ein lokaler MCP-Server erfordert einen separaten Prozess, der gestartet und am Laufen gehalten werden muss; in Claude Code wird er als Kindprozess erzeugt, was gelegentlich Probleme verursacht
  • CLI-Tools sind einfach Binärdateien auf der Festplatte; Hintergrundprozesse, Zustandsverwaltung oder Initialisierung sind nicht nötig

Unannehmlichkeiten in der Praxis

  • Instabile Initialisierung: MCP-Server starten nicht, sodass Claude Code häufig neu gestartet werden muss; danach muss der Zustand zurückgesetzt und erneut versucht werden
  • Wiederholte Re-Authentifizierung: Bei mehreren MCP-Tools muss jedes einzeln authentifiziert werden; bei CLI mit SSO oder langlebigen Zugangsdaten gibt es dieses Problem nicht
  • Grobe Zugriffskontrolle: In Claude Code können MCP-Tools anhand ihres Namens erlaubt werden, aber schreibgeschützte Beschränkungen oder Parametergrenzen lassen sich nicht festlegen
    • Bei CLI ist feingranulare Zugriffskontrolle möglich, etwa gh pr view zu erlauben und für gh pr merge eine Genehmigung zu verlangen

Wann MCP sinnvoll ist

  • Wenn es überhaupt kein entsprechendes CLI-Tool gibt, kann MCP passend sein
  • Der Wert als standardisierte Schnittstelle und die Möglichkeit von Use Cases, in denen MCP besser geeignet ist als CLI, werden anerkannt
  • Für die meisten Aufgaben ist CLI jedoch einfacher, schneller zu debuggen und zuverlässiger

Zentrale Lehre und eine Bitte an Builder

  • Die besten Tools sind solche, die für Menschen und Maschinen gleichermaßen funktionieren; CLI wurde über Jahrzehnte iterativ entworfen, ist kombinierbar, leicht zu debuggen und in bestehende Authentifizierungssysteme integriert
  • MCP wollte eine bessere Abstraktion schaffen, aber es gab bereits eine ausreichend gute Abstraktion
  • Unternehmen, die in MCP-Server investieren, aber keine offizielle CLI haben, sollten ihre Strategie überdenken;
    stellt man zuerst eine gute API und dann eine gute CLI bereit, können Agenten sie von selbst nutzen
  • So lässt sich unnötige Protokollkomplexität reduzieren und Produktivität sowie Wartbarkeit verbessern

Verwandte Beiträge

8 Kommentare

 
sonnet 2026-03-03

Es ist nicht so, dass MCP keine Vorteile hätte; vielmehr sind wir aus der Illusion erwacht, es unterschiedslos für Anwendungsfälle einzusetzen, in denen MCP keine Vorteile bietet. Auch wenn man Microservices für LLMs öffnet, würde man dafür nicht die CLI verwenden, denn MCP ist ein „API“-Protokoll.
 
brainer 2026-03-03

Damals konnte man auch einfach die API verwenden. Eigentlich hat man MCP wegen der Grenzen von long context genutzt, aber diese Grenzen sind inzwischen größtenteils überwunden.
 
jamsya 2026-03-03

Volle Zustimmung.
Auch ohne installiertes AWS MCP holt sich Claude Code anscheinend einfach selbst alles Nötige über die AWS CLI 😂
 
GN⁺ 2026-03-02
Hacker-News-Kommentare

  • Ich habe lange versucht, das nicht zu sagen, aber inzwischen bin ich überzeugt, dass MCP praktisch keinen echten Vorteil bietet
    Ich betreibe AI-Agenten, die meinen gesamten Entwicklungs-Workflow über Shell-Befehle steuern, und selbst wenn sie CLI-Flags zum ersten Mal sehen, verstehen sie sie allein anhand der --help-Ausgabe gut
    MCP-Server waren dagegen immer instabil und mussten ständig gepflegt werden
    CLI lässt sich mit jq, grep, Datei-Umleitungen usw. zusammensetzen, während MCP an das vom Server zurückgegebene Format gebunden ist
    Letztlich denke ich, dass die Einführung von MCP eher ein „AI-first“-Marketing-Signal als eine technische Entscheidung ist

    • MCP ist 2024 stark gewachsen, aber Anfang 2025 hat sich das Narrativ mit dem Aufkommen von Terminal-Agenten (Claude Code) schnell verändert
    • Ich bevorzuge im Gegenteil MCP. Im Vergleich zur CLI sind Fehlerbehandlung und Debugging deutlich sauberer, und man kann riskante Flags einschränken oder Ergebnisse per Paginierung aufteilen
      MCP kann man einfach als Wrapper verstehen, ähnlich wie REST oder gRPC
    • Ich meide MCP ebenfalls. Ich habe das JIRA-MCP ausprobiert, und es war ein Chaos. Stattdessen war es viel effizienter, das LLM APIs direkt aufrufen und Skripte schreiben zu lassen
      Für mich sind LLM-CLI-Tools derzeit der Höhepunkt
    • Unser Unternehmen stellt webexklusive interne Tools wie ein Wiki per MCP bereit, sodass Claude Logs und Metriken direkt abfragen kann
      Allerdings ist es unpraktisch, dass MCP-Ergebnisse immer im Kontextfenster landen. Es wäre gut, sie ins Dateisystem dumpen zu können
    • MCP-Server wirken auf mich wie ein Übergangsprodukt aus einer Zeit, als LLMs noch weniger weit waren. Ich denke, Training mit CLI-Daten ist viel sinnvoller

  • MCP ist wie eine Blackbox-API, die sich sofort aufrufen lässt, ohne Installation oder Resource Provisioning
    CLI kann dagegen auf die lokale Umgebung zugreifen und ist dadurch viel präziser
    Mit jq und der duckdb-CLI sample ich große Datendateien, und Opus 4.6 passt die Queries automatisch an und erkundet die Daten
    CLI reagiert in Echtzeit und ist daher besonders nützlich für explorative Datenanalyse
    Häufig genutzte CLIs sind showboat, br, psql, roborev usw.

    • Ich habe dieselbe Erfahrung gemacht. Die Text-Ein- und -Ausgabe der CLI passt am besten dazu, wie LLMs trainiert werden
      Es hat Spaß gemacht, duckdb zusammen mit ChatGPT zu verwenden; ich frage mich, ob du im System-Prompt festlegst, dass eine lokale DB beibehalten werden soll
    • Statt CLI könnte man Befehle auch in Docker-Containern ausführen und so Installationsprobleme vermeiden. Man könnte sogar ein „Skill“ bauen, das diesen Ansatz automatisiert
    • Als Nicht-Muttersprachler im Englischen finde ich es irgendwie lustig, Pluralformen wie MCPs zu verwenden

  • MCP ist sinnvoll, wenn man Werkzeuge entdeckt, die es in der CLI nicht gibt, und sie kontextbezogen aufruft
    Zum Beispiel stellt mein echomindr eine Datenbank mit aus Podcasts extrahierten Gründerentscheidungen per MCP bereit
    Wenn Claude Fragen zu Startups bekommt, sucht es nach realen Gründererfahrungen und beantwortet sie damit
    CLI eignet sich, wenn der Mensch bereits weiß, welches Tool er verwenden will, während MCP besser für entdeckungsorientierte Tool-Auswahl geeignet ist

  • Der Autor scheint AI-Nutzung nur aus einer Entwicklerperspektive zu betrachten
    Die meisten Nutzer verwenden LLMs über webbasierte Interfaces wie ChatGPT
    Für Unternehmen ist MCP viel besser geeignet, um Marketing-, Sales- und Projektmanagement-Tools anzubinden

  • MCP an sich ist nicht schlecht, aber stdio MCP ist überdesignt
    Stattdessen ist Streamable HTTP + OAuth Discovery derzeit der effizienteste Weg zur AI-Integration
    Zum Beispiel ermöglicht Sentry MCP mit nur einer URL Authentifizierung und Datenzugriff
    Das Problem ist die Art der MCP-Implementierung. Wenn man MCP statt per Bash-Aufruf als HTTP-Endpunkt bereitstellt, funktioniert es deutlich flexibler

    • Sowohl CLI als auch MCP brauchen ein konsistent auf API-Ebene entworfenes Berechtigungssystem. Der Teil mit Streamable HTTP müsste etwas genauer erklärt werden
    • Ich sehe das genauso. Zentralisierte Authentifizierung und Telemetrie sind viel einfacher. Man sollte es nur für den richtigen Einsatzzweck verwenden

  • Einige meiner Kunden haben keinen MCP-Server, aber Entwickler verlangen ihn trotzdem
    Am Ende haben wir die Postman-API als JSON exportiert und bereitgestellt, aber die Entwickler wollten einen MCP-Server
    Ob MCP unterstützt wird, funktioniert wie eine Marketing-Checkliste

  • Dieser Blog wirkt stark entwicklerzentriert
    Wenn man Tools oder Services für Nicht-Entwickler anbindet, ist MCP viel natürlicher

    • Genau. In Chat-Interfaces kann man keine CLI ausführen, und Services für Nicht-Entwickler haben oft überhaupt keine CLI
    • Ich habe mich auch gefragt, ob man in Web- und Mobile-Interfaces wie ChatGPT oder LeChat überhaupt eine CLI ausführen kann
    • Interfaces für Nicht-Entwickler entwickeln sich bereits in Richtungen wie OpenClaw und Claude Cowork

  • Stellenausschreibungen wie „Suche jemanden mit 5 Jahren MCP-Erfahrung“ sind damit am Ende zu einem bedeutungslosen Meme geworden

  • Einer der Gründe, warum CLI besser als MCP ist, liegt darin, dass es informationstheoretisch ein optimiertes Format besitzt
    Die Ausgaben von Unix-Tools platzieren zusammengehörige Informationen nahe beieinander, sodass der Aufmerksamkeitsmechanismus von LLMs effizient arbeiten kann
    JSON ist leicht zu parsen, aber unbequem zu lesen und zum Schlussfolgern
    CLI-Formate sind sowohl für Menschen als auch für LLMs intuitiv
    Siehe auch: Entropy and Information Layout

  • Der Vergleich zwischen MCP und CLI ist ein bisschen so, als würde man OpenAPI mit Strings (JSON) vergleichen
    MCP ist formal definiert, während CLI eher ein abstraktes Interface auf dem Niveau von (String, List String, Map Int Stream) -> PID ist
    Am Ende sind beide nur APIs; wichtig ist, das passende Werkzeug zur Zielerreichung auszuwählen

    • CLI liefert aber mit --help bereits vollständige Dokumentation, daher ist schwer zu argumentieren, dass MCP-Standardisierung besser ist, wenn ein LLM das verstehen kann
    • Wichtiger als Theorie ist die tatsächliche Nutzungserfahrung. Wenn man sagen will, MCP und CLI seien gleich, müsste man zum Beispiel zeigen, dass Playwright CLI und MCP bei Token-Verbrauch und Konfigurierbarkeit identisch sind
      Wenn nicht, wird man in der Praxis direkt spüren, dass die beiden Ansätze unterschiedlich sind
 
develosopher 2026-03-03

Wenn jemand ein SaaS entwickelt hat und für die AI-Integration zwischen CLI und MCP abwägt, würde er sich wahrscheinlich zuerst für MCP entscheiden. Die Unterstützung einer CLI bedeutet schließlich zusätzliche Wartungspunkte. Beides kann zwar koexistieren, aber ich glaube nicht, dass CLI verschwinden wird.
 
hanje3765 2026-03-03

Es scheint, als würde mit steigender Intelligenz von LLMs die Notwendigkeit von MCP unklarer werden.
Ich habe tatsächlich auch dieses Gefühl.
 
m00nlygreat 2026-03-03

Remote-Ausführung scheint sich bei MCP einzuordnen, lokale Ausführung dagegen bei Skills.
 
hulryung 2026-03-03

Ich habe auch begonnen, statt MCP direkt eigene Tools mit der CLI zu bauen und zu nutzen.