MCP vs. CLI für KI-Agenten: Was wir aus sieben MCP-Servern gelernt haben

Dieser Beitrag richtet sich an Entwicklerinnen und Entwickler, die eigene KI-Agenten bauen oder mit Claude Code, Codex und Co. programmieren. Wir haben für immoJUMP sieben MCP-Server-Varianten gebaut — und benutzen für unsere eigenen Coding-Agenten inzwischen meistens ein Kommandozeilen-Tool statt MCP. Hier stehen die Gründe, mit gemessenen Zahlen aus unserem eigenen Stack, und die Stellen, an denen MCP trotzdem die richtige Wahl bleibt.

Kurzfassung

Was MCP kostet, bevor die erste Frage gestellt ist

Das Model Context Protocol regelt, wie ein KI-Client — Claude, ChatGPT, Cursor, Claude Code — mit einem Server spricht, der Werkzeuge anbietet: Name, Beschreibung, JSON-Schema für die Parameter. Der Client fragt beim Verbinden die komplette Werkzeugliste ab, und in den meisten Clients steht ab diesem Moment jedes dieser Schemas im Kontext des Modells — bei jeder einzelnen Anfrage, egal ob das Werkzeug gebraucht wird oder nicht.

Der Kontext eines Sprachmodells ist Arbeitsspeicher und Rechnung zugleich. Wir haben die Werkzeug-Definitionen unseres eigenen MCP-Servers genau so, wie der Client sie bekommt, als kompaktes JSON ausgegeben und gemessen:

Das ist die Untergrenze. Der Client rendert die Schemas in sein eigenes Format, meist mit mehr Whitespace, und dazu kommen die Ergebnisse jedes Aufrufs, die ebenfalls durch den Kontext laufen. Bei aktuellen Modellpreisen (5 US-Dollar je Million Eingabe-Tokens) sind 13.000 Tokens rund 6,5 Cent — pro Anfrage, nicht pro Sitzung. Eine Agenten-Sitzung mit 50 Schritten trägt allein für die Schemas mehrere Dollar; Prompt-Caching macht das billiger, aber die Schemas belegen den Platz im Kontext trotzdem bei jedem Schritt.

Anthropic hat dasselbe Problem im November 2025 in einem eigenen Beitrag beschrieben („Code execution with MCP“): In ihrem Beispiel schrumpfte der Verbrauch von 150.000 auf 2.000 Tokens, als der Agent Werkzeug-Definitionen nur noch bei Bedarf nachlud statt alle vorab zu bekommen — 98,7 Prozent weniger.

Unser Workaround: sieben Einstiegspunkte für eine API

Weil 172 Werkzeuge in einem Server nicht praktikabel sind, haben wir mcp-immojump aufgeteilt: drei Stufen (Standard, Profi, Vollausbau) und vier Domänen-Server (Immobilien, CRM, Pipeline, Organisation). Sieben Einstiegspunkte für eine einzige API.

Das funktioniert, verlagert aber die Entscheidung, welche Werkzeuge ein Agent braucht, vom Agenten auf den Menschen — und zwar vor der ersten Frage. Wer den Standard-Server verbunden hat und nach Darlehen fragt, bekommt „kenne ich nicht“. Wer den Vollausbau verbindet, zahlt 27.000 Tokens pro Anfrage für Werkzeuge, die er in den meisten Sitzungen nicht anfasst. Das Tiering ist die Arbeit, die das Protokoll dem Modell nicht abnimmt.

Was ein CLI anders macht

Ein Kommandozeilen-Tool lädt vorab gar nichts. Der Agent ruft es auf, wenn er es braucht, und erschließt sich den Umfang schrittweise über --help. Unser CLI immojump hat 80 Befehle in 16 Ressourcen; die komplette Markdown-Referenz liegt bei 42 KB — in der Größenordnung des Standard-MCP-Servers. Nur lädt sie nie jemand komplett.

So sieht die Erschließung aus, wenn ein Agent zum ersten Mal Kontakte auflisten soll:

immojump --help                 # 2,4 KB — 16 Ressourcen, eine Bildschirmseite
immojump contacts --help        # 0,5 KB — die 8 Befehle dieser Ressource
immojump contacts list --help   # 0,9 KB — Endpoint, Risk-Level, Parameter, Beispiel
# Summe: 3,8 KB, rund 1.000 Tokens

Statt 13.000 Tokens für alles: 1.000 Tokens für genau das, was gerade gebraucht wird. Die Hilfe zum Befehl enthält denselben Inhalt wie im MCP-Schema — Endpoint, Risk-Level, bekannte Parameter, ein Beispiel — nur zu dem Zeitpunkt, an dem er zählt. Ab der zweiten Sitzung entfallen die ersten beiden Schritte meist ganz: Das Modell hat sich die Grammatik gemerkt (immojump <ressource> <befehl> -q key=value) und geht direkt auf den Befehl.

Warum Modelle das ohne Anleitung können

Sprachmodelle sind auf Jahrzehnten Software-Dokumentation trainiert: Man-Pages, Stack-Overflow-Antworten, READMEs, Shell-Skripte, CI-Logs. Die Grammatik Werkzeug Ressource Verb --flag Wert, die Konvention, dass --help erklärt, Exit-Code 0 Erfolg bedeutet und Fehler auf stderr landen — das steht im Trainingsmaterial hunderttausendfach, von git über kubectl bis gh.

Ein CLI, das sich an diese Konventionen hält, muss dem Modell nicht erklärt werden. Es kennt das Muster, nur nicht unsere Vokabeln — und die holt es sich per --help. Deshalb gilt beim Bauen eines CLI für Agenten genau eine Regel: keine Eigenkreationen. Ressource-Verb-Struktur, Flags mit zwei Strichen, JSON auf stdout, Fehler auf stderr, Exit-Codes, die etwas bedeuten. Jede Abweichung kostet den Vorteil, für den man das CLI gebaut hat.

Ein MCP-Server definiert dagegen bei jedem Werkzeug sein eigenes Vokabular: Parameter-Namen, Verschachtelung, was optional ist, wie Fehler aussehen. Ein Modell kann nicht wissen, ob immobilien_patch und immobilien_update verschiedene Dinge tun, ohne beide Beschreibungen zu lesen. Beim CLI stehen sie untereinander in der Ressourcen-Hilfe: „update: vollständig ersetzen“, „patch: einzelne Felder ändern“. Eine Zeile, entschieden.

Der unterschätzte Vorteil: Verkettung in der Shell

Ein Punkt, der in der Debatte meist fehlt: Ein CLI läuft in einer Shell, und eine Shell kann verketten. „Alle Kontakte ohne E-Mail-Adresse auf das Tag ‚nachpflegen‘ setzen“ ist per MCP ein Listen-Aufruf, dessen komplettes Ergebnis durch den Kontext läuft, gefolgt von n einzelnen Tag-Aufrufen — jeder ein Roundtrip durch das Modell. Per CLI ist es ein Skript:

immojump contacts list -q slim=true --fields id,email \
  | jq -r '.[] | select(.email == null or .email == "") | .id' \
  | xargs -I{} immojump tags set contact {} --tag-ids 17

Die Zwischenergebnisse berühren den Kontext nicht. Genau das ist der Mechanismus hinter Anthropics 98,7 Prozent: Code statt Roundtrips. Ein CLI liefert ihn kostenlos mit, weil die Shell schon da ist. --fields projiziert die Antwort außerdem auf die Spalten, die der Agent wirklich braucht — ein Kontakt mit allen Aktivitäten kann sonst mehrere Kilobyte groß sein.

Fehler sind sichtbarer

„Weniger fehleranfällig“ ist unser Eindruck aus einigen Wochen Alltag, keine Messung. Die Mechanik dahinter lässt sich aber benennen: Ein CLI hat drei getrennte Kanäle — stdout für Daten, stderr für Fehler, Exit-Code für den Status. Ein Agent erkennt einen Fehlschlag am Exit-Code, ohne den Text interpretieren zu müssen. Ein MCP-Werkzeug liefert dagegen oft eine Textantwort, in der Erfolg und Fehler gleich aussehen.

Und ein gutes CLI schlägt laut fehl. Ein Flag, das ein Befehl nicht kennt, ist ein Usage-Fehler mit Exit-Code 2 — kein stilles Ignorieren bei Exit 0. Das haben wir beim Bauen teuer gelernt: Stilles Verwerfen ist der teuerste Fehlermodus überhaupt, weil der Agent glaubt, er hätte etwas getan.

Wo MCP gewinnt

Wer nach diesem Text glaubt, MCP sei erledigt, hat uns falsch verstanden. Es gibt vier Situationen, in denen MCP ohne Diskussion die richtige Wahl ist.

1. Kein Terminal, kein CLI. Claude.ai, Claude Desktop, ChatGPT, die Handy-App: keine Shell. Für unsere Kunden — Immobilieninvestoren ohne Terminal — ist der immoJUMP MCP Server genau deshalb der richtige Weg: Server-URL eintragen, einmal anmelden, fertig. Das CLI ist für Coding-Agenten und Automatisierung, nicht für Endnutzer.
2. Anmeldung. MCP bringt OAuth mit: Der Nutzer meldet sich im Browser an, der Client bekommt ein Token, kein Mensch kopiert Schlüssel. Ein CLI braucht einen Token in einer Konfigurationsdatei oder Umgebungsvariable — für Entwickler normal, für alle anderen eine Hürde.
3. Feinkörnige Freigaben. Ein Host wie Claude Code kann MCP-Werkzeuge einzeln erlauben oder abfragen: „Kontakt löschen“ immer nachfragen, „Kontakte auflisten“ durchwinken. Ein CLI läuft über das Bash-Werkzeug, und Bash ist aus Sicht des Hosts eine einzige Berechtigung. Wir lösen das im CLI über Risk-Level pro Befehl (dazu gleich) — aber das bleibt eine Selbstbeschränkung des Werkzeugs, keine Grenze, die der Host erzwingt.
4. Null Installation. Ein Remote-MCP-Server ist eine URL. Ein CLI ist ein Binary, das auf jeder Maschine liegen und aktuell sein muss.

Wie wir das CLI gebaut haben

Für alle, die den gleichen Weg gehen wollen, die Entscheidungen, die sich bewährt haben:

• Go, nur Standardbibliothek, ein Binary. Kein Runtime, kein npm install, kein Python-Environment auf dem CI-Runner.
• Eine deklarative Registry als einzige Quelle. Jeder Befehl ist eine Spec-Zeile: Ressource, Verb, Endpoint, Risk-Level, Parameter. Daraus entstehen Dispatch, --help, die Markdown-Referenz (immojump docs) und ein JSON-Schema (immojump schema). Hilfe und Verhalten können nicht auseinanderlaufen.
• Risk-Level am Endpoint, nicht am Aufrufweg. Jeder Befehl trägt read, write, external oder destructive. --readonly lässt nur lesende Befehle zu, --allow read,write erlaubt eine Liste. Eine leere Liste ist ein Konfigurationsfehler, kein „alles erlaubt“.
• Der Escape-Hatch erbt das Risk-Level. immojump api DELETE /api/contacts/42 darf nicht lockerer sein als immojump contacts delete 42. Das Risk gehört zum Endpoint, sonst umgeht der Umweg die Policy.
• JSON auf stdout, --fields zum Projizieren, --pretty für Menschen. Standardausgabe ist Maschinenformat; wer liest, sagt es dazu.

Wohin sich das entwickelt

Ehrlicherweise schrumpft der Kontext-Vorsprung des CLI gerade. Claude Code lädt MCP-Werkzeuge inzwischen verzögert: In unserer aktuellen Sitzung stehen die 87 immoJUMP-Werkzeuge als „deferred“ und werden erst per Werkzeug-Suche nachgeladen, wenn eines gebraucht wird. Die Anthropic-API kennt dasselbe Muster, und „Code execution with MCP“ macht aus MCP-Servern Code-Bibliotheken in einem Dateisystem, die ein Agent per Verzeichnis-Listing erkundet.

Anders gesagt: Das MCP-Ökosystem übernimmt gerade das Prinzip des CLI. Erst die Übersicht, dann das Detail, Zwischenergebnisse im Code statt im Kontext. Was bleibt, sind die drei anderen Vorteile: die Konventionen aus dem Trainingsmaterial, die Verkettung in der Shell und die Nachvollziehbarkeit im Transcript — jeder Aufruf ist eine Zeile, die ein Mensch kopieren, prüfen und wiederholen kann. Ein MCP-Aufruf ist ein JSON-Blob, den niemand nachspielt.

Unsere Regel

1. Coding-Agent, CI-Pipeline, Automatisierung: CLI. Null Kontext bis zum ersten Aufruf, Konventionen, die das Modell kennt, Verkettung inklusive.
2. Chat-Client ohne Shell, Endnutzer, OAuth: MCP. Es gibt keine Alternative, und es soll auch keine geben.
3. Wer beides anbietet: beide aus derselben API speisen und die Fachlogik im Backend lassen. Weder der MCP-Server noch das CLI dürfen eigene Regeln kennen — sonst pflegt man drei Produkte statt eines.

Selbst ausprobieren

immojump-cli ist offen auf GitHub. Ein Befehl installiert es, kein Go nötig:

curl -fsSL https://raw.githubusercontent.com/immoJUMP/immojump-cli/main/install.sh | sh
immojump --help

Wer lieber mit Claude, ChatGPT oder Codex im Browser oder Desktop arbeitet, statt im Terminal, findet die passende Anleitung hier: immoJUMP MCP Server verbinden — Claude & Codex in 5 Minuten. Wer einen eigenen Server-Agenten dauerhaft anbinden will, mit Bot-Token statt Benutzer-Token und harten Rechtegrenzen: immoJUMP-MCP für Server-Agenten.

Fragen zum Aufbau beantworten wir gern direkt — schreib uns an info@immojump.de.