CLI-Tools vs. MCP: Bessere KI-Agenten

Seien wir ehrlich: MCP (Model Context Protocol) sollte der universelle Verbinder zwischen KI-Modellen und der realen Welt sein. Ein sauberes, strukturiertes Protokoll, mit dem dein KI-Agent über eine standardisierte Schnittstelle mit jedem beliebigen Tool sprechen kann. Klingt in der Theorie großartig. In der Praxis? Ich greife immer öfter zu den altbewährten CLI-Tools – und damit bin ich nicht allein.

Nach Monaten, in denen ich KI-Agenten-Lösungen gebaut und mit beiden Ansätzen in realen Enterprise-Szenarien gearbeitet habe, lautet meine Einschätzung: CLI-Tools sind in vielen Fällen die bessere Wahl, und der Grund dafür ist erstaunlich einfach – Kontext-Effizienz.

Das Problem mit MCP, über das niemand spricht

MCP funktioniert. Das will ich gar nicht bestreiten. Aber hier ist das, was mir aufgefallen ist, nachdem ich mehrere MCP-Server in Agent-Workflows integriert hatte: MCP ist ein Kontext-Fresser.

Ein typischer MCP-Server stellt nicht nur die Tools bereit, die du brauchst. Er kippt ein komplettes Schema in das Kontextfenster deines Agenten – Tool-Definitionen, Parameterbeschreibungen, Authentifizierungs-Flows, State-Management, das ganze Paket.

Ich zeige dir, was ich meine. So sieht es aus, wenn du einen beliebten GitHub-MCP-Server anbindest:

{
  "tools": [
    {
      "name": "create_issue",
      "description": "Create a new issue in a GitHub repository",
      "inputSchema": {
        "type": "object",
        "properties": {
          "owner": { "type": "string", "description": "Repository owner" },
          "repo": { "type": "string", "description": "Repository name" },
          "title": { "type": "string", "description": "Issue title" },
          "body": { "type": "string", "description": "Issue body content" },
          "assignees": { "type": "array", "items": { "type": "string" } },
          "labels": { "type": "array", "items": { "type": "string" } },
          "milestone": { "type": "integer" }
        },
        "required": ["owner", "repo", "title"]
      }
    }
    // ... repeat this for 92 more tools
  ]
}

Das ist eine Tool-Definition. Der vollständige GitHub-MCP-Server bringt 93 Tools mit. Gesamte Kontext-Kosten? Rund 55.000 Tokens – bevor du auch nur eine einzige Frage gestellt hast. Das ist ungefähr die Hälfte des Kontextfensters von GPT-4o oder ein erheblicher Teil von Claudes Budget, der allein für die Infrastruktur draufgeht.

Jetzt staple mehrere MCP-Server übereinander. Ein typischer Enterprise-Agent braucht vielleicht GitHub, einen Datenbank-Connector, Microsoft Graph und eventuell Jira. Da landest du schnell bei über 150.000 Tokens allein für Tool-Definitionen.

Vergleiche das mit CLI:

gh issue create --repo my-org/my-repo --title "Bug in auth flow" --body "Steps to reproduce..."

Das Modell kennt gh bereits. Null Schema-Tokens verbraucht. Die gesamte Interaktion – Befehl plus Ausgabe – kostet dich vielleicht 200 Tokens.

Die Token-Rechnung, die mich umgestimmt hat

Ich habe einen direkten Vergleich an einer realen Aufgabe durchgeführt: „Liste alle nicht-konformen Intune-Geräte auf und exportiere ihre Details in eine CSV-Datei.”

MCP-Ansatz (Microsoft Graph MCP Server):

Phase	Token-Kosten
Injektion des Tool-Schemas	~28.000 Tokens
Agenten-Reasoning + Tool-Auswahl	~3.200 Tokens
MCP-Aufruf: Geräte mit Filter auflisten	~1.800 Tokens
Parsen der MCP-Antwort	~4.500 Tokens
MCP-Aufruf: Gerätedetails abrufen (pro Gerät)	~2.100 Tokens × N
Gesamt für 50 Geräte	~145.000 Tokens

CLI-Ansatz:

Phase	Token-Kosten
Injektion des Tool-Schemas	0 Tokens
Agenten-Reasoning + Befehlszusammenstellung	~800 Tokens
Ausführung des Shell-Befehls	~150 Tokens
Parsen der Ausgabe	~3.200 Tokens
Gesamt für 50 Geräte	~4.150 Tokens

Das ist kein marginaler Unterschied. Das ist eine 35-fache Reduktion des Token-Verbrauchs. Und Tokens sind nicht nur eine Kostenkennzahl – sie hängen direkt damit zusammen, wie viel Reasoning-Kapazität deinem Agenten für das eigentliche Problem noch bleibt.

Praxisbeispiel: Automatisierung der Intune-Compliance

Ich führe dich durch beide Ansätze anhand einer Aufgabe, die ich tatsächlich für einen Kunden gebaut habe.

Das Ziel: Einen Agenten bauen, der die Gerätekonformität über einen Intune-Tenant hinweg prüft, Richtlinienverstöße identifiziert, mit den Gruppenmitgliedschaften in Entra ID abgleicht und einen Remediation-Report erstellt.

Der MCP-Ansatz

Ich habe drei MCP-Server eingerichtet: Microsoft Graph (für Intune und Entra ID), eine eigene Compliance-Regel-Engine und ein Reporting-Tool.

Agent Context Window:
├── System prompt:          ~2,000 tokens
├── Graph MCP schema:      ~28,000 tokens
├── Compliance MCP schema:  ~8,500 tokens
├── Reporting MCP schema:   ~5,200 tokens
├── Conversation history:   ~4,000 tokens
└── Available for reasoning: ~82,300 tokens (of 128K)

Der Agent funktionierte, aber er war spürbar langsamer. Das mehrstufige Reasoning brach nach 3–4 Tool-Aufrufen zusammen, weil der angesammelte Kontext aus den MCP-Antworten den Agenten in den hinteren Bereich seines Kontextfensters drängte, in dem die Aufmerksamkeitsqualität abnimmt. Ich musste den Workflow auf mehrere Agenten-Sitzungen aufteilen, um zuverlässige Ergebnisse zu erhalten.

Der CLI-Ansatz

Gleiche Aufgabe. Ich gab dem Agenten eine Shell mit mgc (Microsoft Graph CLI), az CLI und drei gezielten PowerShell-Skripten.

# The agent composed this pipeline autonomously:
mgc devices list --filter "complianceState eq 'noncompliant'" `
  --select "id,deviceName,complianceState,userPrincipalName" --output json |
  ConvertFrom-Json |
  ForEach-Object {
    $device = $_
    $groups = mgc users list-member-of --user-id $_.userPrincipalName `
      --output json | ConvertFrom-Json
    [PSCustomObject]@{
      DeviceName = $device.deviceName
      User       = $device.userPrincipalName
      Compliance = $device.complianceState
      Groups     = ($groups.displayName -join "; ")
    }
  } |
  Export-Csv -Path "compliance-report.csv" -NoTypeInformation

Agent Context Window:
├── System prompt:          ~2,000 tokens
├── Tool schemas:           0 tokens
├── Conversation history:   ~1,500 tokens
├── Command output:         ~3,200 tokens
└── Available for reasoning: ~121,300 tokens (of 128K)

Dem Agenten standen 95 % seines Kontextfensters für das Reasoning zur Verfügung. Er stellte die gesamte Pipeline in einem Zug zusammen, behandelte Edge Cases proaktiv und erledigte die Aufgabe in einer einzigen Sitzung. Kein Aufteilen nötig.

Warum KI-Modelle native CLI-Sprecher sind

Es gibt einen tieferen Grund, warum CLI so gut mit KI-Agenten funktioniert, und der geht über die Token-Effizienz hinaus.

KI-Modelle wurden auf Milliarden von Zeilen an Terminal-Interaktionen trainiert – Stack-Overflow-Antworten, GitHub-Repos, Dokumentationen, Tutorials. Wenn du Claude oder GPT bittest, git, docker, az, kubectl oder gh zu verwenden, zapfst du tief erlernte Muster an. Das Modell braucht kein Schema, um zu wissen, dass git log --oneline -10 die letzten 10 Commits anzeigt.

MCP-Server hingegen sind eigene Schemas, die das Modell zur Laufzeit zum ersten Mal sieht. Selbst mit guten Beschreibungen muss das Modell über unbekannte Tool-Schnittstellen spontan nachdenken. Das ist zusätzliche kognitive Last, die direkt mit der eigentlichen Aufgabe konkurriert.

Hier ein kurzer Vergleich, wie ein Agent mit beiden interagiert:

# CLI: The model already knows this
docker ps --filter "status=running" --format "{{.Names}}: {{.Status}}"

# MCP: The model has to interpret this schema first
{
  "name": "list_containers",
  "inputSchema": {
    "properties": {
      "status_filter": { "enum": ["running", "stopped", "all"] },
      "format_fields": { "type": "array", "items": { "enum": ["name", "status", "image", "ports"] } }
    }
  }
}

Die CLI-Variante ist selbsterklärend. Die MCP-Variante verlangt vom Modell, seine Absicht auf eine unbekannte Abstraktionsschicht abzubilden.

CLI-Komponierbarkeit: Die Unix-Philosophie trifft auf KI

Einer der stärksten Vorteile von CLI-Tools ist die Komponierbarkeit – und KI-Agenten sind erstaunlich gut darin.

# Agent-composed pipeline: Find Azure VMs with high CPU,
# get their Intune compliance status
az vm list --query "[?powerState=='VM running']" -o json |
  jq -r '.[].name' |
  xargs -I {} mgc devices list
    --filter "displayName eq '{}'"
    --select "complianceState" -o json |
  jq '[.[] | {name: .displayName, compliance: .complianceState}]'

Versuch mal, diesen tool-übergreifenden Workflow mit MCP zu bauen. Du müsstest beide Server geladen haben, der Agent müsste mehrere strukturierte Aufrufe orchestrieren, Zwischen-State verwalten und mit unterschiedlichen Antwortformaten umgehen. Mit CLI leitet der Agent einfach Text durch vertraute Tools.

Benchmarks bestätigen das

Das ist nicht nur meine Erfahrung. Aktuelle Benchmarks aus der Community bestätigen das Muster. Ein detaillierter Vergleich führte identische Browser-Automatisierungsaufgaben sowohl über MCP- als auch über CLI-Schnittstellen aus. Das Ergebnis: CLI erreichte einen um 28 % höheren Task-Completion-Score bei in etwa gleicher Gesamt-Token-Zahl – was bedeutet, dass die Tokens effektiver für das eigentliche Problemlösen statt für Protokoll-Overhead eingesetzt wurden.

Der Token Efficiency Score (TES) erzählte die Geschichte: CLI erzielte 202 gegenüber MCPs 152, ein Effizienzvorteil von 33 %. Und CLI erledigte Aufgaben, die MCP strukturell gar nicht bewältigen konnte, wie etwa Memory-Profiling, weil es vollen Zugriff auf selektive Abfragen und gezielte Ausgaben hatte, anstatt ganze Datenstrukturen abzukippen.

Wann MCP weiterhin Sinn ergibt

Ich behaupte nicht, dass MCP tot ist. Es gibt legitime Anwendungsfälle, in denen es die richtige Wahl ist:

Strukturierte Produktionsumgebungen, in denen du strikte Eingabevalidierung, OAuth-basierte Authentifizierungs-Flows und Audit-Trails brauchst. Die Schema-Erzwingung von MCP verhindert, dass Agenten fehlerhafte Befehle ausführen.

Mandantenfähige SaaS-Plattformen, bei denen Tools eine feingranulare Berechtigungssteuerung benötigen. MCPs Protokoll zur Aushandlung von Fähigkeiten löst das elegant.

Nicht-CLI-Tools und -Dienste, die keine Kommandozeilen-Schnittstelle haben. Wenn du mit Figma, Notion oder einer eigenen internen API integrierst, ist MCP oft die einzige praktikable Option. Aber du kannst dir dafür auch eine eigene CLI bauen.

Discovery-lastige Szenarien, in denen Agenten verfügbare Tools dynamisch finden müssen. MCPs tools/list-Endpunkt gibt Agenten eine strukturierte Möglichkeit, Fähigkeiten zu entdecken. Bei CLI muss der Agent bereits wissen, welche Tools existieren.

Der Sweet Spot? Nutze CLI als Standard und greife auf MCP zurück, wenn du seine spezifischen Garantien brauchst.

Praktische Leitlinien für den Bau CLI-first-Agenten

Wenn du diesen Ansatz übernehmen möchtest, hier die Muster, die gut funktionieren:

1. Stelle ein fokussiertes Tool-Manifest statt MCP-Schemas bereit. Anstatt vollständige MCP-Tool-Definitionen zu laden, gib deinem Agenten eine leichtgewichtige Markdown-Datei:

## Available Tools
- `mgc`: Microsoft Graph CLI. Use for Intune, Entra ID, Teams, SharePoint queries.
- `az`: Azure CLI. Use for Azure resource management, VMs, networking.
- `gh`: GitHub CLI. Use for repos, issues, PRs, actions.
- Custom scripts in /tools/: compliance-check.ps1, export-report.ps1

Das sind ~100 Tokens statt über 50.000.

2. Baue schlanke Wrapper-Skripte für komplexe mehrstufige Operationen.

# /tools/get-noncompliant-devices.ps1
param(
    [string]$OutputFormat = "json",
    [switch]$IncludeGroupMembership
)

$devices = mgc devices list `
    --filter "complianceState eq 'noncompliant'" `
    --select "id,deviceName,userPrincipalName,complianceState,lastSyncDateTime" `
    --output $OutputFormat

if ($IncludeGroupMembership) {
    $devices | ConvertFrom-Json | ForEach-Object {
        $groups = mgc users list-member-of --user-id $_.userPrincipalName --output json
        $_ | Add-Member -NotePropertyName "groups" -NotePropertyValue ($groups | ConvertFrom-Json).displayName
        $_
    } | ConvertTo-Json -Depth 5
} else {
    $devices
}

Der Agent ruft ein einziges Skript auf, anstatt sich durch fünf MCP-Tool-Aufrufe zu denken.

3. Nutze Flags für strukturierte Ausgabe. Die meisten modernen CLIs unterstützen --output json oder --format json. Das liefert Agenten saubere, parsebare Daten ohne den Overhead eines MCP-Antwort-Wrappers.

# Structured output that agents parse effortlessly
az vm list --output json --query "[].{name:name, state:powerState, os:storageProfile.osDisk.osType}"

mgc devices list --output json --select "deviceName,complianceState"

kubectl get pods -o json | jq '.items[] | {name: .metadata.name, status: .status.phase}'

4. Nutze --help als dynamische Dokumentation. Wenn sich der Agent bei einem Befehl unsicher ist, kann er mgc devices list --help für Just-in-time-Dokumentation aufrufen. Das ist token-effizienter, als das gesamte Schema vorab zu laden – der Agent zahlt die Token-Kosten nur dann, wenn er die Information tatsächlich braucht.

Die wichtigsten Erkenntnisse

Fang mit CLI an. Bevor du zu MCP greifst, frag dich: Gibt es bereits ein CLI-Tool dafür? Wenn ja, nutze es. Dein Agent schneidet mit dem zusätzlichen Kontext-Spielraum besser ab.

Miss dein Kontext-Budget. Verfolge, wie viele Tokens deine Tool-Integrationen verbrauchen. Du wirst vielleicht schockiert sein, wie viel Overhead MCP hinzufügt – und wie direkt sich das auf die Reasoning-Qualität des Agenten auswirkt.

Entwirf auf Komponierbarkeit hin. Baue kleine, fokussierte CLI-Tools, die eine Sache gut machen. Lass den KI-Agenten sie kombinieren. Das ist die Unix-Philosophie – und wie sich zeigt, lieben KI-Agenten sie.

Reserviere MCP für das, worin es gut ist. Produktionssicherheit, Zugriffskontrolle in mandantenfähigen Umgebungen, Tool-Discovery in großen Organisationen. Nutze es nicht nur, weil es das neue, glänzende Ding ist.

Die Zukunft des KI-Agenten-Toolings dreht sich nicht um das ausgefeilteste Protokoll. Es geht um den schlanksten Weg zwischen dem Modell und der Aktion. Und gerade jetzt führt dieser Weg durch das Terminal.