CLI statt MCP: Warum Chrome DevTools mit Copilot effizienter läuft

Die Frage, ob Entwickler Tools über CLI-Befehle oder MCP-Server (Model Context Protocol) steuern sollten, gewinnt an Brisanz – besonders wenn es um Token-Effizienz und Agenteninteraktion geht. Ein aktuelles Experiment mit GitHub Copilot CLI und Chrome DevTools liefert überraschende Erkenntnisse: Ein Wrapper, der die MCP-Schnittstelle in eine CLI-Skill umwandelt, reduziert den Overhead dramatisch. Während klassische MCP-Integration bis zu 5.000 Tokens an Kontext vorab benötigt, bleibt die CLI-Variante deutlich schlanker.

Warum CLI die Token-Flut bremst

Das Chrome DevTools MCP-Projekt ermöglicht es KI-Agenten, direkt mit dem Browser zu interagieren – etwa um Seiten zu navigieren oder UI-Elemente zu inspizieren. Doch der Preis für diese Flexibilität ist hoch: In einem Test mit GitHub Copilot CLI (Modell: gpt-5.3-codex-medium) verschlang die direkte MCP-Integration 24.000 Tokens allein für den Tool-Kontext, bevor die eigentliche Aufgabe begann. Zum Vergleich: Eine leere CLI-Sitzung startet mit nur 19.000 Tokens, wobei der MCP-Overhead hier auf 155 Tokens schrumpft.

Die Token-Sparsamkeit von `mcp2cli` – einem Tool, das MCP-Server in CLI-Befehle übersetzt – ist verblüffend. Laut Herstellerangaben lassen sich damit 96 bis 99 % der Tokens einsparen, die sonst für Tool-Schemas verschwendet werden. Doch warum ist das so?

• Keine System-Prompt-Verschmutzung: CLI-Befehle sind für KI-Modelle bereits vertraut. Ein git commit-Aufruf erfordert keine ausführliche JSON-Beschreibung des Tools, wie es bei MCP der Fall ist.
• Kein Ballast durch Schemas: MCP-Server laden ihre Funktionsdefinitionen als JSON-Schemas in den Kontext. CLI-Tools nutzen stattdessen bekannte Befehle wie chrome-devtools --navigate, die der Agent aus früheren Trainingsdaten kennt.
• Lokal optimierte Discovery: Statt sich auf statische Dokumentation zu verlassen, kann der Agent CLI-Befehle dynamisch erkunden – etwa durch chrome-devtools --help oder --list-actions.

Der Aufbau des Experiments: MCP vs. CLI im Vergleich

Für den Test wurde ein privates Python/Streamlit-Projekt als Testumgebung genutzt. Die Aufgabe bestand darin, einen neunstufigen Smoke-Test auszuführen – eine Standardprozedur, um die Stabilität einer Webanwendung zu prüfen. Dabei wurden zwei Ansätze verglichen:

1. Direkte MCP-Integration: Der Agent nutzte das Chrome DevTools MCP ohne Umwege.
2. CLI-Skill-Wrapper: Ein eigens erstellter Wrapper, der die MCP-Funktionen über mcp2cli als CLI-Befehle verfügbar machte.

Die Entwicklung des CLI-Wrappers erfolgte in mehreren Schritten:

• Ein minimaler Coding-Agent (pi mit gpt-5.4-mini) analysierte die öffentlichen Dokumentationen der Projekte Chrome DevTools MCP und mcp2cli.
• Der Agent generierte einen ersten Wrapper, der die MCP-Operationen in CLI-Befehle übersetzte.
• Anschließend wurde der Wrapper mit GitHub Copilot CLI (gpt-5.3-codex-high) validiert und verfeinert.

Dank dieser automatisierten Tool-Erstellung entfiel die Notwendigkeit, einen separaten MCP-Server zu installieren – ein Vorteil, der besonders bei gewichtigen Agenten-Umgebungen wie Copilot CLI ins Gewicht fällt.

Die Ergebnisse: Token-Verbrauch und Performance im Fokus

Die Messungen zeigen ein gemischtes Bild, das weniger die Tools selbst als vielmehr die Arbeitsweise des KI-Modells widerspiegelt. Hier die zentralen Erkenntnisse:

Token-Verbrauch pro Lauf

| Modus | Gesamtkontext (Tokens) | Nachrichtenkontext (Tokens) | Laufzeit | Erfolg | |---------------------------|-------------------------|------------------------------|-----------------|---------| | CLI-Skill #1 | 39.000 | 20.500 | nicht erfasst | – | | CLI-Skill #2 | 37.000 | 18.100 | 259 Sekunden | 9/9 | | CLI-Skill #3 | 38.000 | 18.900 | 141 Sekunden | 9/9 | | Direkte MCP #1 | 40.000 | 16.100 | nicht erfasst | – | | Direkte MCP #2 | 62.000 | 38.700 | 101 Sekunden | 9/9 | | Direkte MCP #3 | 79.000 | 55.900 | 241 Sekunden | 9/9 |

• Direkte MCP-Integration führte in einem Fall zu einer extrem langen Laufzeit (241 Sekunden) und einem Token-Verbrauch von 79.000, während die schnellste MCP-Sitzung nur 101 Sekunden benötigte.
• CLI-Skills wiesen eine stabilere Token-Nutzung auf, blieben aber in der Laufzeit hinter den schnellsten MCP-Läufen zurück.

Kritische Beobachtungen

• Agenten-Pfade dominieren die Performance: Ein einziger falscher Klick, eine überflüssige Wartezeit oder eine fehlerhafte Element-ID kann die Token-Bilanz und Laufzeit explodieren lassen. Beispielsweise verzögerte sich ein MCP-Lauf durch eine 120-Sekunden-Wartezeit, die der Agent einleitete.
• Kontext-Engineering hilft nur begrenzt: Während sich die Token-Nutzung durch CLI-Wrapper optimieren lässt, bleibt die Qualität der Agenten-Entscheidungen der entscheidende Faktor.

Fazit: CLI als pragmatische Alternative für KI-gestützte Browserautomatisierung

Die Experimente zeigen: CLI-basierte Werkzeuge wie `mcp2cli` bieten klare Vorteile, wenn es um Token-Effizienz und Entwicklerfreundlichkeit geht. Besonders in Umgebungen mit begrenzten Kontextfenstern – wie bei GitHub Copilot CLI – kann die Umgehung von MCP-Server-Schemata die Performance signifikant verbessern.

Allerdings darf nicht vergessen werden, dass die tatsächliche Effizienz stark vom KI-Modell und seiner Fähigkeit abhängt, CLI-Befehle korrekt auszuführen. Während die Token-Einsparungen beeindruckend sind, bleibt die Stabilität der Agenten-Entscheidungen der entscheidende Faktor für den Erfolg. Wer also nach einer schlanken, kostengünstigen Lösung sucht, sollte CLI-Tools wie mcp2cli in Betracht ziehen – allerdings mit der Bereitschaft, die Agenten-Pfade durch manuelle Validierung zu optimieren.

Für Entwicklerteams, die Browserautomatisierung in KI-Agenten integrieren, könnte dies ein wichtiger Schritt sein: Weg von komplexen MCP-Servern, hin zu bekannten, token-sparenden CLI-Befehlen – ohne dabei auf Flexibilität verzichten zu müssen.