MCP vs CLI 2026: Die Debatte läuft auf der falschen Ebene

Phillip Pham, AI Developer bei Pexon Consulting | 9 Min. Lesezeit | 21.09.2026

TL;DR: MCP vs CLI in fünf Sätzen

MCP vs CLI ist die falsche Frage. Beide funktionieren gut, sobald das Modell in einer REPL mit persistentem Zustand arbeitet. CLI wirkt überlegen, weil Bash mit dem Dateisystem genau so eine REPL ist. Das ist keine Schwäche von MCP, sondern fehlende Harnesses. Pexon Consulting baut deshalb zuerst die Ausführungsschicht, dann die Anbindung.

Das Problem: Warum CLI in der Praxis gewinnt, und warum das täuscht

Seit gut einem Jahr sehen Teams dasselbe Muster: Ein Coding-Agent mit Shell-Zugriff erledigt Aufgaben, an denen derselbe Agent mit zehn angebundenen MCP-Servern scheitert. Daraus ist eine Lagerbildung entstanden. Die einen erklären MCP für überflüssig, die anderen verteidigen es als Enterprise-Standard mit Auth und Audit.

Beide Lager haben recht mit ihrer Beobachtung und unrecht mit der Erklärung.

Der Unterschied liegt nicht im Protokoll. Er liegt darin, was zwischen zwei Aufrufen mit den Daten passiert. Beim klassischen MCP-Tool-Call wandert jedes Ergebnis zurück ins Kontextfenster. Das Modell muss es lesen, sich merken und im nächsten Call wieder ausschreiben. Bei der Shell landet das Ergebnis in einer Datei oder einer Pipe, und das Modell sieht nur, was es sehen muss.

Anthropic hat das im November 2025 beziffert: Ein Workflow von Google Drive nach Salesforce fiel von 150.000 auf 2.000 Tokens, also 98,7 Prozent weniger, als der Agent Code gegen die Tools schrieb, statt sie einzeln aufzurufen (Anthropic Engineering: Code execution with MCP). Gleiches MCP, gleiche Tools. Anders war nur die Umgebung.

Was Tobi Lütke am 21.09.2026 geschrieben hat

Tobi Lütke, Gründer und CEO von Shopify, hat die Diskussion in der Nacht auf den 21. September 2026 in einem Post auf X auf den Punkt gebracht (Originalpost von @tobi). Sinngemäß übersetzt:

Drei Aussagen stecken darin, und alle drei halten wir für richtig:

1. Die Vergleichsebene stimmt nicht. MCP ist ein Protokoll zur Tool-Beschreibung, CLI ist ein Aufrufweg. Beides sind Eingänge, keine Laufzeiten.
2. Der Gewinner ist der Zustand. Bash hat einen, ein nackter Tool-Call nicht.
3. LLMs können Systeme vorwärts entwickeln. Lütke führt das auf das Reinforcement Learning für agentisches Arbeiten zurück: Modelle haben gelernt, eine Codebasis schrittweise zu verändern oder Daten zu holen und dann weiterzuverarbeiten. Ohne Ausführungsumgebung können sie genau das nicht.

Lütke hat Shopify im April 2025 per internem Memo auf reflexive KI-Nutzung verpflichtet. Der Post kommt also nicht von der Seitenlinie, sondern von jemandem, der Agenten im eigenen Unternehmen durchsetzt.

MCP vs CLI: der eigentliche Unterschied ist der Zustand

Die kurze Antwort: Bash gewinnt nicht, weil Kommandozeilen besser sind, sondern weil Bash nebenbei ein Arbeitsgedächtnis mitliefert. Dateien überleben den einzelnen Befehl. Das Modell kann Zwischenergebnisse ablegen, filtern, zählen und erst das Ergebnis lesen.

Ein Beispiel, wie ein Agent mit Shell-Zugriff eine Frage über 40.000 Tickets beantwortet, ohne auch nur eines davon ins Kontextfenster zu laden:

# Schritt 1: Daten holen und ablegen, nichts davon landet im Kontext
curl -s "https://tickets.intern.example/api/export?monat=2026-08" > tickets.json

# Schritt 2: nur filtern und zählen, das Modell sieht zehn Zeilen statt 40.000
jq -r '.[] | select(.prioritaet=="hoch") | .komponente' tickets.json 
  | sort | uniq -c | sort -rn | head -10

# Schritt 3: im nächsten Turn auf derselben Datei weiterarbeiten
jq '[.[] | select(.komponente=="Zahlungsmodul")] | length' tickets.json

Derselbe Ablauf über drei klassische MCP-Calls sieht anders aus: Der Export kommt als Tool-Ergebnis zurück und steht komplett im Kontext. Der Agent muss ihn „im Kopf“ filtern. Bei Schritt 3 hat er das Ergebnis aus Schritt 1 entweder noch im Fenster (teuer) oder nicht mehr (falsch).

Das ist der Kern. Nicht die Syntax entscheidet, sondern ob es einen Ort gibt, an dem Zustand zwischen den Schritten liegt.

Die drei REPLs, die heute funktionieren

Lütke nennt drei Umgebungen, die das Problem heute lösen. Wir ergänzen, wo sie in Unternehmensprojekten passen und wo nicht.

Wie groß der Effekt beim Code Mode ist, hat Cloudflare am 20.02.2026 gezeigt: Die Cloudflare-API hat über 2.500 Endpunkte. Als einzelne MCP-Tools wären das rund 1,17 Millionen Tokens Schema. Mit Code Mode schrumpft das auf zwei Tools, search() und execute(), und etwa 1.000 Tokens Kontext (Cloudflare Blog: Code Mode). MCP bleibt dabei das Protokoll darunter. Es wird nur anders aufgerufen.

Die QuickJS-Linie lebt: Der Community-Fork quickjs-ng hat am 18.09.2026 Version v0.17.0 veröffentlicht (3.773 GitHub-Stars, Abruf 21.09.2026).

Unsere Empfehlung: Für interne Datenagenten ist Jupyter unterschätzt. Für alles, was produktiv auf Kundendaten läuft, ist eine echte Shell auf einem echten Server der teuerste Weg, weil Sie die Absicherung komplett selbst bauen.

Lütkes Wette: eine SQLite für Agenten-Ausführung

Der spannendste Teil des Posts ist die Prognose. Lütke wettet, dass bald jemand (oder schon jemand?) eine einbettbare Mini-Ausführungsumgebung im Stil von SQLite baut. Sie soll Bash, TypeScript oder Tool-Calls in eine gemeinsame Zwischensprache übersetzen, einen Ausführungsplan, der sich vor dem Start leicht sicherheitsprüfen lässt. Gebaut für Durable Execution. CLI, MCP, WebMCP und was sonst kommt, docken nur noch als Eingänge an.

Wir halten die Wette für gut. Und ein Teil davon existiert bereits in Einzelteilen:

Der letzte Punkt wird gern übersehen. Mit der Spec 2026-07-28 ist MCP ausdrücklich zustandslos geworden. Das Protokoll sagt damit selbst: Zustand ist Aufgabe des Hosts. Genau das ist Lütkes These, nur aus der Gegenrichtung formuliert.

Was noch fehlt, ist die gemeinsame Zwischensprache. Heute prüft jede Umgebung auf ihre eigene Art. Ein Plan, der „lies Datei X, rufe Tool Y mit Spalte Z auf, schreibe nach W“ vor der Ausführung als Ganzes zeigt, wäre für Freigaben, Audit und Rechteprüfung ein echter Schritt nach vorn. Einzelne Tool-Calls lassen sich prüfen, eine Absicht über zehn Schritte bisher kaum.

So sieht die Richtung heute schon aus. Ein MCP-Tool wird als Befehl in einer eingebetteten Bash registriert, der Agent verarbeitet das Ergebnis mit gewohnten Werkzeugen weiter, und das Dateisystem hält den Zustand zwischen den Aufrufen:

// npm install just-bash   (Stand 21.09.2026: v3.4.2, Beta)
import { Bash, defineCommand } from "just-bash";

// Ein MCP-Tool als Shell-Befehl. In echt ruft callTool() den MCP-Client auf,
// hier liefert eine Attrappe feste Daten, damit das Beispiel lokal läuft.
async function callTool(name: string, args: Record<string, string>) {
  return [
    { auftrag: "A-1001", status: "offen", werk: "Ulm" },
    { auftrag: "A-1002", status: "erledigt", werk: "Ulm" },
    { auftrag: "A-1003", status: "offen", werk: "Graz" },
  ];
}

const erpAuftraege = defineCommand("erp-auftraege", async (args) => {
  const daten = await callTool("erp.auftraege_suchen", { werk: args[0] ?? "" });
  return { stdout: JSON.stringify(daten), stderr: "", exitCode: 0 };
});

const bash = new Bash({ customCommands: [erpAuftraege] });

// Aufruf 1: Tool-Ergebnis landet in einer Datei, nicht im Kontext des Modells
await bash.exec("erp-auftraege > auftraege.json");

// Aufruf 2: späterer Turn, gleiche Datei, nur die Antwort geht ans Modell
const r = await bash.exec(
  `jq '[.[] | select(.status=="offen")] | group_by(.werk) | map({werk: .[0].werk, offen: length})' auftraege.json`
);
console.log(r.stdout);

Kein Protokollwechsel, kein Lagerkampf. MCP liefert die Daten, die Umgebung hält sie, das Modell arbeitet wie in einer Shell.

Was das für Ihre Architektur-Entscheidung heißt

Wenn Sie gerade evaluieren, ob Ihre Agenten „auf MCP“ oder „auf CLI“ gebaut werden sollen: Stellen Sie die Frage anders. Wir sehen in Projekten immer wieder, dass Teams Wochen in die Protokollwahl stecken und die Ausführungsschicht nebenbei improvisieren. Das ist die falsche Reihenfolge.

Worauf Sie bei der Auswahl achten sollten:

1. Wo liegt Zustand zwischen zwei Schritten? Wenn die Antwort „im Kontextfenster“ lautet, bekommen Sie Kosten- und Qualitätsprobleme, egal mit welchem Protokoll.
2. Lässt sich ein Lauf unterbrechen und fortsetzen? Freigabeschritte, Timeouts und Abstürze kommen in jedem produktiven Prozess vor. Ohne Snapshot oder Checkpoint beginnt der Agent von vorn.
3. Was sieht die Sicherheitsprüfung? Einzelne Calls oder den ganzen Plan? Für regulierte Umgebungen brauchen Sie Letzteres.
4. Ist die Sandbox wirklich eine? Kein Host-Dateisystem, keine Umgebungsvariablen mit Secrets, Netzwerk nur per Freigabeliste.
5. Bleibt MCP als Anbindung erhalten? Auth, Katalog und Audit sind die echten Stärken von MCP. Die wollen Sie nicht gegen Shell-Skripte eintauschen, sondern in eine REPL hineinholen.

Unsere klare Position: MCP für die Anbindung von Systemen, eine REPL mit persistentem Zustand für die Ausführung, und eine Freigabeschicht dazwischen. Wer heute MCP abschafft, weil CLI im Coding-Agent besser lief, verliert Governance und gewinnt nichts, was eine gute Ausführungsschicht nicht auch liefert. Die Anbindungsseite beschreiben wir auf unserer Seite zur MCP-Integration für KI-Agenten, die Einordnung in den Gesamtstack im AI Engineering Stack.

Die Risiken der Ausführungsseite sind real. Wie Rechte, Sandboxing und DSGVO zusammenspielen, haben wir im Beitrag zum Sandboxing von LLM-Agenten beschrieben.

Pexon Consulting (80 Mitarbeitende, Deutschland, ISO 27001) baut solche Ausführungsschichten für Agenten, die auf Unternehmensdaten laufen. Framework-agnostisch, weil sich genau diese Schicht in den nächsten zwölf Monaten am stärksten bewegen wird.

Häufig gestellte Fragen

Ist MCP oder CLI besser für KI-Agenten?

Keins von beiden ist grundsätzlich besser. CLI wirkt in Coding-Agenten überlegen, weil Bash mit dem Dateisystem Zustand zwischen den Schritten hält. Läuft MCP in einer REPL mit persistentem Zustand, etwa per Code Mode, verschwindet der Unterschied weitgehend. Die Frage lautet also: Welche Ausführungsumgebung, nicht welches Protokoll.

Was hat Tobi Lütke zu MCP vs CLI gesagt?

Der Shopify-CEO schrieb am 21.09.2026 auf X, MCP vs CLI sei die falsche Diskussion auf der falschen Ebene. Beides funktioniere, solange es über eine REPL mit persistentem Zustand laufe. Er wettet auf eine einbettbare, SQLite-artige Ausführungsumgebung, die Bash, TypeScript und Tool-Calls in einen prüfbaren Ausführungsplan übersetzt.

Was ist Code Mode bei MCP?

Code Mode wandelt die Tools eines MCP-Servers in eine TypeScript-API um. Das Modell schreibt Code gegen diese API, der in einer Sandbox läuft, typischerweise einem V8-Isolate oder QuickJS. Cloudflare reduziert so eine API mit über 2.500 Endpunkten auf zwei Tools und rund 1.000 Tokens Kontext.

Was kostet der Umstieg von klassischen MCP-Calls auf eine REPL-Umgebung?

Die Bibliotheken selbst sind Open Source und kostenlos. Der Aufwand liegt in der Sandbox, den Rechten und dem Betrieb: Anthropic weist ausdrücklich darauf hin, dass Code-Ausführung Isolation, Ressourcenlimits und Monitoring braucht. Dem stehen Token-Einsparungen von 80 bis über 98 Prozent in den veröffentlichten Beispielen gegenüber, die sich bei hohem Volumen schnell rechnen.

Brauchen wir MCP noch, wenn Agenten Bash können?

Ja, für alles jenseits des lokalen Rechners. MCP bringt standardisierte Anbindung, Authentifizierung und einen prüfbaren Tool-Katalog. Bash bringt davon nichts mit. Der sinnvolle Weg ist, MCP-Tools in eine Ausführungsumgebung zu holen, statt sie durch Shell-Skripte mit hartcodierten Tokens zu ersetzen.

Nächster Schritt

Verwandte Themen