MCP und CLI kombinieren: So optimieren Sie dynamische KI-Workflows

KI-Agenten scheitern oft an einem vermeintlich kleinen Fehler: Ein Server stürzt ab, doch der Rest läuft weiter. Genau das passierte einem Entwicklerteam, als ein MCP-Server als Plugin registriert war und mit dem Agenten neu startete – mit leeren Caches und verlorenen Verbindungen. Die Lösung? MCP-Server als eigenständige Prozesse betreiben. Dieser Ansatz revolutionierte ihre Workflows.

Warum MCP-Server keine Plugins sein sollten

Ein Plug-in lebt im Prozess des Hauptagenten. Stirbt dieser, stirbt auch das Plug-in – inklusive aller offenen Verbindungen und Cache-Daten. MCP-Server hingegen sind eigenständige Prozesse, die über Ports kommunizieren. Ein Beispiel aus der Praxis:

• Der Agent nutzte ark-delegator als Plugin über WSL.
• Nach einem Neustart des Daemons war der Server leer, weil die Verbindungspools zurückgesetzt wurden.
• Doch die MCP-Server auf den Ports 8101 bis 8106 liefen weiter – weil sie unabhängig verwaltet wurden.

Der Unterschied: Plug-ins teilen sich Schicksal mit dem Hauptprozess. MCP-Server überleben dessen Neustarts. Diese Lebenszyklus-Unabhängigkeit rettet Sessions und spart Ressourcen.

Die Architektur: Sechs fokussierte Server statt eines Monolithen

Das Team setzte auf sechs spezialisierte MCP-Server, jeder mit 3-8 Tools – gesteuert über oh-my-mcp und systemd. Die Vorteile:

• Geringere Schema-Overhead: Insgesamt nur 8.000–10.000 Token, weniger als ein einzelner GitHub-MCP-Server mit 14.000 Token.
• Unabhängige Neustarts: Jeder Server kann separat neu gestartet werden, ohne den Agenten zu blockieren.
• Netzwerkweite Erreichbarkeit: Alle Server sind über Server-Sent Events (SSE) auf ihren Ports zugänglich.

# oh-my-mcp config.yaml
servers:
  ark-exec:
    transport: stdio
  ark-memory:
    transport: stdio
  ark-resolve:
    transport: stdio
  mempalace:
    transport: stdio
  ark-gist:
    transport: stdio
  ark-delegator:
    transport: stdio

Für strukturierte Operationen wie Abfragen oder Suchen nutzt der Agent die MCP-Server direkt. Ad-hoc-Befehle wie npm view oder git push werden dagegen über den CLI-Bridge server-commands-rtk ausgeführt – mit Token-Optimierung und automatischer Protokollierung.

Effizienzvergleich: MCP vs. Roh-CLI vs. RTK-gefiltert

Das Team analysierte die Token-Nutzung für typische Befehle wie Paketabfragen oder Git-Operationen:

| Operation | Methode | Token-Nutzung | Vorteil | |-------------------------|-----------------------|---------------|-----------------------------| | npmPackageDownloads() | MCP-Tool | ~170 | 2,4x günstiger als Roh-CLI | | npm view @ev3lynx/md-analyzer | Ungefiltert RAW | ~2.000+ | Keine Struktur | | npm view @ev3lynx/md-analyzer | RTK-gefiltert | ~400 | 5x effizienter als unstrukturiert | | git push origin main | Roh-CLI | ~50 | Kein Schema-Overhead |

Fazit:

• MCP eignet sich für strukturierte Eingaben/Ausgaben (z. B. Abfragen mit bekanntem Schema).
• Roh-CLI ist ideal für Befehle mit minimalem Output (z. B. git push).
• RTK-Filterung reduziert Token in CLI-Befehlen um ~90% und spart bei häufigen Aufrufen spürbare Kosten.

Audit-Logging ohne MCP-Overhead

Ein häufiges Missverständnis: MCP erzwinge strukturierte Protokollierung. Doch auch CLI-Tools können umfassende Audit-Logs liefern – mit einem zentralen Wrapper:

{
  "timestamp": "2026-07-08T10:01:27Z",
  "command": "git push origin main",
  "exitCode": 0,
  "duration_ms": 3240,
  "rtk_filtered": true
}

Der Unterschied liegt in der Architektur:

• MCP protokolliert auf Protokoll-Ebene (strukturierte I/O).
• CLI-Bridge protokolliert auf Anwendungsebene (flexibel, ohne Schema-Zwang).

Für Compliance-Anforderungen reicht oft eine CLI-Lösung mit JSONL-Logging und Rotation.

Der hybride Dispatch-Mechanismus

Das Team entwickelte eine dreistufige Logik für die Befehlsverarbeitung:

1. MCP-Server (strukturierte Operationen)

• Wird genutzt für Abfragen, Suchen oder Lesevorgänge.
• Beispiel: mempalace für semantische Suche.

1. CLI-Bridge (ad-hoc-Befehle)

• Führt Befehle wie git push oder npm view aus.
• Inklusive RTK-Tokenfilterung und Audit-Logging.

1. Hybride Entscheidungslogik

• Der Agent prüft den Befehlstyp (z. B. type in ["query", "search", "read"]) und leitet ihn entsprechend weiter.

def dispatch(operation):
    if operation.type in ("query", "search", "read"):
        return call_mcp(operation)
    elif has_tool(operation):
        return run_raw(operation)
    else:
        return run_raw_rtk(operation)  # CLI mit Audit-Logging

Diese Logik läuft seit Monaten in der Produktion und reduziert sowohl Token-Kosten als auch Ausfallrisiken.

Praktische Erkenntnisse aus dem Einsatz

Die Umstellung auf unabhängige MCP-Server und eine hybride Architektur brachte mehrere Vorteile:

• Ausfallsicherheit: Ein Server-Crash betrifft nur einen Teil des Systems.
• Skalierbarkeit: Neue Tools lassen sich einfach als separate Server hinzufügen.
• Kostenersparnis: Durch gezielte MCP-Nutzung und RTK-Filterung sanken die Token-Kosten um bis zu 90% bei bestimmten Operationen.
• Transparenz: Die CLI-Bridge liefert detaillierte Audit-Logs – ohne MCP-spezifische Komplexität.

Langfristiger Tipp: Vermeiden Sie monolithische MCP-Server mit Hunderten von Tools. Stattdessen setzen Sie auf kleine, fokussierte Server mit klaren Verantwortungsbereichen. Kombinieren Sie diese mit einer schlanken CLI-Bridge für unstrukturierte Aufgaben. So erhalten Sie ein robustes, wartbares und kosteneffizientes System.

Die Zukunft der KI-Agenten liegt nicht im Entweder-oder, sondern im intelligenten Zusammenspiel verschiedener Technologien. MCP und CLI sind keine Gegensätze – sie sind perfekte Partner für dynamische, skalierbare Workflows.