MCP ist tot; es lebe MCP

 (chrlschn.dev)
19 Punkte von GN⁺ 2026-03-16 | 6 Kommentare | Auf WhatsApp teilen
  • CLI ist zwar als neuer Trend für Agent-Tool-Interfaces aufgekommen, doch auch maßgeschneiderte CLIs leiden unter denselben Kontextproblemen wie MCP und müssen dafür Struktur sowie diverse Vorteile aufgeben
  • MCP im lokalen stdio-Modus und Remote-MCP auf Basis von Streamable HTTP sind vollständig unterschiedliche Use Cases, und diese Unterscheidung wird in der aktuellen Debatte übersehen
  • Die Funktionen Prompts und Resources von MCP sind ein Mechanismus, um standardisierte Skills und Dokumente in Echtzeit in der gesamten Organisation zu verteilen, und damit zentral für den Übergang von Vibe Coding zu systematischem Agentic Engineering
  • Zentrale MCP-Server standardisieren OAuth-Authentifizierung, Telemetrie und Observability und ermöglichen damit Sicherheit auf Organisationsebene sowie die Messung der Wirksamkeit von Tools
  • Für einzelne Entwickler kann eine CLI passend sein, aber auf Organisations- und Enterprise-Ebene ist MCP das heutige und künftige Tool, das Konsistenz, Sicherheit und Qualität gewährleistet

Influencer-getriebener Hype-Zyklus

  • Noch vor 6 Monaten war das Model Context Protocol (MCP) das größte Gesprächsthema der Branche, und jeder Vendor wollte Produkte rund um MCP auf den Markt bringen
  • Schon damals gab es die skeptische Sichtweise „Das ist doch nur eine API, warum braucht man dafür einen Wrapper?“, und tatsächlich entschieden sich einige Teams bewusst dafür, den MCP-Hype-Zyklus zu überspringen und stattdessen einfache Tool-Wrapper über REST-API-Endpunkten zu schreiben
  • Für die meisten Use Cases verbreitete sich die Wahrnehmung, MCP sei im Vergleich zum direkten Aufruf von APIs unnötiger Overhead
  • Inzwischen hat sich der Branchendiskurs zu MCP-Kritik und CLI-Lobpreisung verschoben; das hängt auch mit der Struktur zusammen, in der AI-Influencer ständig neue Trends erzeugen müssen, um Aufmerksamkeit aufrechtzuerhalten
  • Selbst prominente Namen wie Garry Tan oder Andrew Ng neigen dazu, persönliche Erfahrungen zu verallgemeinern, und eine von FOMO und Hype geprägte Influencer-Kultur verzerrt den Diskurs in diesem Feld
  • Es gibt tatsächlich Fälle, in denen eine CLI besser als Agent-Tool-Interface geeignet ist, aber eben nicht in allen Fällen

Token-Einsparung bei CLI: Realität und Grenzen

CLI-Tools im Trainingsdatensatz

  • CLI-Utilities wie jq, curl, git, grep, psql oder aws, die im Trainingsdatensatz von LLMs enthalten sind, können von Agenten sofort ohne zusätzliche Anweisungen, Schemas oder Kontext verwendet werden
  • MCP muss Tools in der Antwort von tools/list vorab deklarieren, wodurch gegenüber bereits bekannten CLI-Tools Overhead entsteht
  • CLI-Tools, die bereits in den Trainingsdaten enthalten sind, sollten immer gegenüber MCP bevorzugt werden

Grenzen maßgeschneiderter CLI

  • Bei maßgeschneiderten (bespoke) CLI-Tools kann das LLM die Verwendung nicht kennen, daher muss in AGENTS.md oder README.md eine Beschreibung bereitgestellt werden
  • Man kann ein Verzeichnis /cli-tools festlegen und auf sprechende Namen setzen, doch Agenten machen auf diese Weise häufig Fehler, sodass am Ende mehr erklärende Dokumentation nötig wird
  • Selbst bei Tools wie curl verschwindet der Vorteil der Token-Einsparung, sobald ein benutzerdefiniertes OpenAPI-Schema verstanden werden muss

Verkettete Extraktion und Transformation

  • Mit CLI-Ketten lassen sich Daten erst abrufen und dann transformieren, um die in das Kontextfenster eingehende Datenmenge zu verringern
  • Allerdings können formatierte Inhalte wie HTML, JSON oder XML auch mit Selektoren wie DOM/CSS, JSONPath oder XPath extrahiert werden; das ist also kein Alleinstellungsmerkmal der CLI

Schrittweiser Kontextverbrauch

  • Während MCP das gesamte Toolset und die Schemas vorab lädt, kann eine CLI Kontext über --help schrittweise laden
  • Bei maßgeschneiderten CLI-Tools muss der Agent jedoch Help-Inhalte über mehrere Turns hinweg erkunden und lädt dadurch letztlich ähnliche Informationen wie ein MCP-Schema, nur ohne Struktur
  • In ausreichend komplexen Flows durchsucht der Agent am Ende ohnehin den Großteil des Baums, sodass der Einsparungseffekt gering ist
  • Laut Forschung von Vercel verbesserte sich die Nutzung von Dokumentation durch Agenten, wenn der gesamte Dokumentationsindex in AGENTS.md abgelegt wurde; die vollständigen Schemas vorab bereitzustellen, begünstigt die richtige Tool-Auswahl
  • Da Anthropic derzeit ein Kontextfenster von 1 Million Tokens anbietet, ist fraglich, ob Token-Einsparung überhaupt noch ein ausschlaggebendes Argument ist

Die Doppelnatur von MCP: stdio vs. Streamable HTTP

Grenzen des stdio-Modus

  • Im stdio-Modus läuft ein MCP-Server lokal zusammen mit dem Agenten und fügt gegenüber dem Schreiben einer einfachen CLI unnötige Komplexität hinzu
  • Für die meisten Use Cases ist MCP im stdio-Modus unnötig

Der transformative Wert von Streamable HTTP

  • MCP mit Streamable-HTTP-Transport ermöglicht es, dieselbe Logik auf einem zentralen Server auszuführen, und ist für die Einführung in Organisationen und Enterprises ein Schlüsselelement, um Vibe Coding in Agentic Engineering zu überführen
  • Die meisten Influencer unterscheiden diese beiden Modi nicht sauber

Vorteile zentraler MCP-Server

Umfangreiche Backend-Funktionen

  • Auf einem zentralen Server können Tools umfangreiche Plattformfunktionen wie Postgres-Instanzen oder Cypher-Graphabfragen auf Basis von Apache AGE nutzen
  • Auf Agent-Seite müssen nur HTTP-Endpunkt und Authentifizierungstoken konfiguriert werden, was die Bereitstellung einfach macht
  • Auch lokale Datenbanken wie SQLite sind möglich, stoßen aber an Grenzen, wenn Zustände organisationsweit geteilt werden sollen

Ephemere Agent-Runtimes

  • In ephemeren Runtime-Umgebungen wie GitHub Actions lassen sich über einen Remote-MCP-Server Tools mit komplexem Backend ohne Installation nutzen
  • Die Verwaltung zustandsbehafteter Workloads in zustandslosen Umgebungen wird an den zentralen Server delegiert

Authentifizierung und Sicherheit

  • Wenn über eine CLI auf gesicherte APIs zugegriffen werden soll, müssen alle Entwickler direkten Zugriff auf API-Keys haben, was für Operations-Teams eine große Belastung darstellt
  • Hinter einem zentralisierten MCP-Server authentifizieren sich Entwickler per OAuth am MCP-Server, während sensible API-Keys und Secrets hinter dem Server kontrolliert bleiben
  • Wenn Teammitglieder das Unternehmen verlassen, reicht es, nur die OAuth-Tokens zu widerrufen; Zugriff auf andere Keys und Secrets hatten sie von vornherein nie

Telemetrie und Observability

  • Auf einem zentralen MCP-Server lassen sich OpenTelemetry-Traces und Metriken mit Standardwerkzeugen erfassen
  • So kann nachvollzogen werden, welche Tools effektiv sind, welche Agent-Runtimes verwendet werden und an welchen Stellen Tools scheitern
  • Auch mit CLI-Tools ist das möglich, aber lokale Deployments erfordern Updates bei den Nutzern, und für jedes CLI-Tool müsste das Telemetrie-Scaffolding erneut nachgebaut werden

Standardisierte Sofortbereitstellung und automatische Updates

  • Verteilte Tools (Pakete) verursachen Probleme bei der Kompatibilität von API-Versionen, aber MCP kann Clients über Subscriptions und Notifications über Updates informieren
  • MCP Prompts entsprechen einem vom Server gelieferten SKILL.md, und MCP Resources entsprechen einem vom Server gelieferten /docs

Der organisatorische Wert von MCP Prompts und Resources

  • Dynamische Inhalte: *.md-Dateien in einem Repository sind statische Dateien, die manuell aktualisiert werden müssen, während serverbasierte Prompts und Resources in Echtzeit dynamisch generiert werden können
    • Dokumente, Preisdaten oder der aktuelle Systemstatus, die nur in bestimmten Kontexten nützlich sind, können ohne Tool-Aufruf dynamisch injiziert werden
  • Automatische Konsistenz-Updates: Über Repositories oder Pakete verteilte *.md-Dateien müssen synchronisiert werden; werden sie jedoch über MCP-Prompts ausgeliefert, bleiben sie immer auf dem neuesten Stand
    • Auch offizielle Dokumentation von Drittanbietern muss nicht manuell ins Repository kopiert und aktualisiert werden, wenn sie über den Server proxied wird
  • Organisationsweiter Wissensaustausch: Inhalte, die für die gesamte Organisation gelten — etwa Security-, Telemetrie-Best-Practices oder Überlegungen zur Infrastruktur-Bereitstellung — lassen sich konsistent über alle Repositories, alle Workflows und alle Agent-Frontends (Claude Code, Codex, VS Code Copilot, GitHub Agents, OpenCode usw.) verteilen
    • In Microservice-Umgebungen kann ein Team auf die Dokumentation anderer Services zugreifen, oder ein Service-Team kann bei jeder Bereitstellung dynamisch Skills ausliefern
  • Es gibt bestätigte Beispiele dafür, dass MCP Prompts und Resources in OpenCode, Claude Code CLI usw. tatsächlich funktionieren; mit der MCP-Client-Konfiguration ist nach der Bereitstellung keine gesonderte Pflege mehr nötig

Fazit: Auf Organisationsebene ist MCP Gegenwart und Zukunft

  • Vor 6 Monaten war MCP noch das große Gesprächsthema, heute wird es als Hauptursache für Context Bloat kritisiert, doch die ähnlichen Trade-offs und Fallstricke maßgeschneiderter CLI werden dabei übersehen
  • Wenn Teams darüber nachdenken, wie sie von Vibe Coding zu Agentic Engineering übergehen, landen sie ganz natürlich bei Design und Mission von MCP
  • Wie das jüngste Beispiel aus dem Amazon-AWS-Bereich zeigt — dort ist für AI-unterstützte Änderungen die Freigabe durch Senior Engineers erforderlich — müssen Teams die von AI-Agenten produzierten Softwaresysteme am Ende betreiben und warten
  • Die Ratschläge von Garry Tan und Andrew Ng mögen in homogenen individuellen Umgebungen funktionieren, lassen sich aber nur schwer unverändert auf organisatorische Kontexte übertragen, in denen Teams mit unterschiedlichen technischen Fähigkeiten und Erfahrungen auf konsistente Qualität hinarbeiten müssen
  • Wer zuverlässige und wartbare Software ausliefern will, braucht Engineering-Disziplin, die Konsistenz, Sicherheit, Qualität und Genauigkeit gewährleistet; dafür ist MCP heute das geeignete Tool für Organisationen und Enterprises

Verwandte Beiträge

6 Kommentare

 
slowandsnow 2026-03-16

CLI ist ein lokales Tool, MCP ist ein Server – der Einsatzzweck ist daher völlig unterschiedlich.
 
cnaa97 2026-03-17

Wäre es nicht dasselbe, wenn man die CLI auf dem Server ausführt?
 
ng0301 2026-03-16

MCP wiederauferstanden!
 
edunga1 2026-03-16

Verwandtes Dokument: MCP ist tot. Es lebe die CLI
 
hmmhmmhm 2026-03-16

Ich hoffe, dass die Diskussion über eine Art CLI-Sandbox-Funktion weiter vorankommt, damit CLI-Tools auch in mobilen Apps nutzbar werden. Wenn man echte mobile Kompatibilität anstrebt, scheint der Engpass am Ende beim Sandboxing zu liegen.
 
GN⁺ 2026-03-16
Hacker-News-Kommentare

  • Ich habe das Gefühl, dass die meisten derzeit erscheinenden AI-Integrationsfunktionen schlecht entworfen sind.
    In einer Situation, in der nicht einmal grundlegende Befehle standardisiert sind, gibt es statt Dokumentation nur ungenaue, von LLMs erzeugte Hilfetexte im Überfluss.
    Am Ende werden sich die sogenannten „AI-Standards“ wohl wiederholt bilden und wieder verschwinden. LLMs sind ihrem Wesen nach textbasiert und können daher kaum so präzise arbeiten wie Netzwerkprotokolle. Diese textzentrierte Engineering-Praxis führt letztlich zu einer instabilen Abstraktionspyramide.

  • Ich denke, bei AI-Tools ist am nützlichsten eine Struktur, in der probabilistische Agenten von deterministischen Gates umhüllt werden.
    Deshalb verwende ich MCP über HTTP. NanoClaw erhöht zum Beispiel die Sicherheit, indem es WhatsApp-Nachrichten deterministisch filtert und API-Keys proxyt. Solche Strukturen machen AI vertrauenswürdiger.

    • Ich folge einem ähnlichen Muster. Mein autonomer Agent Smith verbindet MCP über ein Service Mesh, sodass Policies (OPA) und Monitoring zentral verwaltet werden.
      Diese Struktur bietet hohe Sicherheit und einfache Verwaltbarkeit, und aus dem Tool-Katalog lässt sich auch automatisch eine CLI generieren.
      Ein Implementierungsbeispiel gibt es unter smith-gateway.
    • Selbst wenn ein Agent kompromittiert wird, müssen die Grenzen erhalten bleiben. Wir verwenden kryptografische Delegationstoken mit aufgabenspezifisch begrenztem Scope und validieren sie an der Grenze der MCP-Tools.
      Den Open-Source-Core findet man unter tenuo.
    • Der Kern guter AI-Tooling besteht heutzutage nicht darin, Freiheit zu geben, sondern Einschränkungen zu setzen.
      MCP trennt die Entscheidungsfindung der AI klar von der deterministischen Ausführung des Systems. Ich nutze Claude Code zusammen mit einem MCP-Server; kreative Problemlösung übernimmt die AI, während die Ausführung über vorhersagbare Pfade läuft — sehr effizient.

  • MCP ist eine fest definierte Protokollspezifikation für die Kommunikation zwischen AI-Apps.
    Anders als klassische „Integrationen“, bei denen APIs zwischen Apps gewaltsam zusammengeschnürt werden, bietet es eine wiederverwendbare Kommunikationsabstraktion wie HTTP, FTP oder SMTP.
    Ich denke, dass AI eine solche gemeinsame Sprache braucht, um mit verschiedenen Diensten zu interagieren.
    Die Spezifikation ist unter modelcontextprotocol.io/specification/2025-11-25 zu finden.

    • Manche sagen jedoch: „Das ist eine Lösung für das falsch verstandene Problem.“
      Eigentlich gebraucht werde kein neues Protokoll, sondern eine schrittweise erkundbare CLI- oder API-Spezifikation. MCP sei nur eine Übergangslösung aus der Zeit, als frühe Agenten keine CLI ausführen konnten.
    • Eine andere Meinung lautet: „Wenn AI wirklich AI ist, warum braucht sie dann ein separates Protokoll, um HTTP oder FTP zu verstehen?“
      Aus dieser Sicht ist MCP letztlich nur eine temporäre Lösung für technische Unreife.
    • Es wird auch die grundlegende Frage gestellt, ob man überhaupt ein neues Protokoll schaffen muss.
    • Kritisiert wird außerdem, dass MCP faktisch nur eine maßgeschneiderte API-Definition auf JSON-RPC-Basis sei und deshalb kaum standardisierter oder wiederverwendbarer wirke als bestehende Ansätze.
    • Manche meinen auch, dass CLI-Tools sich von MCP letztlich gar nicht unterscheiden, da auch sie eine „wiederverwendbare Kommunikationsabstraktion“ darstellen.

  • Als MCP zum ersten Mal erschien, wirkte es auf mich wie überengineerter Müll, deshalb habe ich mich nicht weiter dafür interessiert.
    Bis heute bereue ich das nicht. Bei LangChain ist es ähnlich. Etwas nur wegen seiner Popularität zu übernehmen, ist riskant.

    • Trotzdem versehe ich inzwischen meinen gesamten Code mit MCP-Schnittstellen. Für LLMs ist das Debugging dadurch viel einfacher geworden, und MCP ist zu einer Komponente geworden, die fast so wichtig ist wie die UI.
      Schon mit sehr geringem Zeitaufwand lässt sich viel Effizienz gewinnen.
    • Natürlich ist der „sniff test“ nützlich, aber allein reicht er nicht aus.
      Manchmal überlebt gerade ein grobschlächtiges Tool, weil es komplexe Integrationsprobleme überraschend einfach löst.
      Wer es von Anfang an ignoriert, weil es hässlich wirkt, verpasst womöglich die Chance, dass es später zur Standardinfrastruktur wird.
    • LangChain ist nicht überengineert, sondern Chaos ganz ohne Design.
    • Manche sagen im Gegenteil, MCP sei populär geworden, weil es zu einfach sei.
      Es gelte weniger als überengineert, sondern eher als klare und intuitive Struktur.
    • Es gibt auch Leute, die immer noch nicht genau wissen, was LangChain eigentlich ist.

  • Remote-MCP ist in dem Sinne okay, dass Authentifizierung automatisch gehandhabt wird und der Zugriff auf Services einfach ist.
    Im Vergleich zur Kombination aus CLIs + Skills ist die Kontextlast (context bloat) jedoch groß, und Vorteile der Unix-CLI wie Pipeline-Verarbeitung oder Heredoc-Eingaben gehen verloren.
    Aus der Ausgabe von --help lassen sich bei CLIs effizient automatisch Skills erzeugen.
    MCP benötigt einen dauerhaften Prozess, CLIs können dagegen nur bei Bedarf ausgeführt werden.

    • Natürlich müssen CLIs installiert werden, dafür hat MCP den Vorteil, dass es einfach nur per Konfiguration funktioniert.

  • Ich halte MCP weiterhin für eine unnötige Schicht.
    Dass CLI > MCP gilt, sehe ich auch so, aber die Vorteile bei Dokumentation und Zentralisierung lassen sich auch anders lösen.
    Mit Skills kann man zum Beispiel Anleitungen sowohl für CLI als auch für APIs hinterlegen, und sie werden nur bei Bedarf geladen.
    Auch die Vorteile eines zentralisierten MCP lassen sich in Wirklichkeit gut mit bestehenden Proxys oder AWS SSO umsetzen.
    Am Ende scheint es mir besser, mit Skills zu dokumentieren und die eigentliche Interaktion über CLI oder REST-API abzuwickeln.

    • Dagegen gibt es allerdings auch Widerspruch.
      Es wird argumentiert, dass der Inhalt von Skills letztlich in den Kontext aufgenommen wird und Last erzeugt, und dass ein Proxy die Funktionen von MCP nicht vollständig ersetzen kann.
      MCP kann über den /-Befehl und @-Referenzen Prompts und Ressourcen aktivieren; das ist mit einem Proxy nicht möglich.
      Entsprechende Demos finden sich in den .gif-Dateien am Ende des Artikels sowie in der MCP-Spezifikation.

  • Ich habe weiterhin den Eindruck, dass MCP besser für Consumer-Umgebungen geeignet ist.
    In Entwicklungsumgebungen ist es komplex und ineffizient, aber normale Nutzer können über MCP leicht erkennen, welche Funktionen ein Modell ausführen kann.
    Es braucht keine Umgebungs­konfiguration, und in einer GUI lassen sich Antworten wie bei Siri oder Google Assistant visualisieren.

  • Aus Sicht von jemandem, der AI-Tools für nichttechnische Nutzer innerhalb eines Unternehmens bereitstellt, war ein zentralisierter MCP-Ansatz sehr nützlich.
    Markenton, interne Terminologie, gemeinsamer Datenzugriff und Domänenkontext konnten dadurch konsistent verwaltet werden.
    Über die Resource-Methoden von MCP ließen sich standardisierte „Skills“ bereitstellen und Muster für die Datenanbindung kontrollieren.

  • Der Autor betrachtet mehrere Konzepte aus verschiedenen Blickwinkeln, scheint aber bestehende Konzepte wie Token Notation (TOON) nicht zu kennen.
    Es entsteht fast der Eindruck, als wünsche er sich, dass so etwas existiert.

  • Das eigentliche Problem von MCP ist die Wartungslast.
    Wenn man zum Beispiel eine GitHub-Integration braucht, ist man auf npm-Wrapper angewiesen, statt einfach eine bereits gut dokumentierte API zu verwenden.
    Ich nutze einfach die gh-CLI oder curl. Wenn sich die API ändert, liest der Agent die neue Dokumentation und passt sich an.
    Bei MCP muss man warten, bis der zwischengeschaltete Wrapper aktualisiert wird.
    Auch die Sicherheitsargumentation ist widersprüchlich — anfangs kam es ohne Authentifizierung heraus, jetzt wird Sicherheit als Vorteil angeführt.
    Tatsächlich sind das Probleme, die alte Methoden wie chroot oder scoped tokens längst gelöst haben.
    Der einzige echte Vorteil von MCP liegt bei OAuth-Flows für Nichtentwickler. Für Entwickler-Tools halte ich es für sinnvoller, einfach bessere CLIs zu bauen.