Apideck CLI: Eine Low-Context-Alternative zu MCP für KI-Agenten

Das Kontextfenster-Problem von MCP

Der Artikel beschreibt ein spezifisches Szenario: Das Verbinden von GitHub, Slack und Sentry über MCP-Server (etwa 40 Werkzeuge insgesamt) verbraucht über 55.000 Tokens, bevor der Agent eine einzige Nutzernachricht verarbeitet. Das ist mehr als ein Viertel von Claudes 200k-Limit. Jede MCP-Werkzeugdefinition kostet 550–1.400 Tokens für ihren Namen, Beschreibung, JSON-Schema, Feldbeschreibungen, Aufzählungen und Systemanweisungen.

Ein Team berichtete, dass drei MCP-Server 143.000 von 200.000 Tokens (72 % des Kontextfensters) verbrauchten, sodass nur 57.000 Tokens für die eigentliche Konversation, abgerufene Dokumente, Schlussfolgerungen und Antworten übrig blieben.

David Zhang (@dzhng), der Duet entwickelt, beschrieb die vollständige Entfernung von MCP-Integrationen aufgrund eines "Trilemmas": Alles vorab laden und Arbeitsgedächtnis verlieren, Integrationen begrenzen, sodass der Agent nur mit wenigen Diensten kommunizieren kann, oder dynamisches Werkzeugladen aufbauen, was Latenz und Middleware-Komplexität erhöht.

Benchmark-Ergebnisse

Ein Benchmark von Scalekit führte 75 direkte Vergleiche durch (gleiches Modell: Claude Sonnet 4, gleiche Aufgaben, gleiche Prompts) und fand heraus:

• MCP kostet 4- bis 32-mal mehr Tokens als die CLI für identische Operationen
• Das Überprüfen der Sprache eines Repos verbrauchte 1.365 Tokens über die CLI gegenüber 44.026 über MCP
• Der Overhead besteht fast ausschließlich aus Schemata: 43 Werkzeugdefinitionen, die in jede Konversation injiziert werden, von denen der Agent ein oder zwei verwendet

Der Ansatz von Apideck CLI

Die Apideck CLI verwendet einen etwa 80-Token-Agenten-Prompt, der Zehntausende Tokens an Schema ersetzt. Sie bietet progressive Offenlegung via --help und strukturelle Sicherheit, die in die Binärdatei eingebaut ist. Jeder Agent, der Shell-Befehle ausführen kann, kann sie verwenden, ohne Protokollunterstützung zu benötigen.

Branchenreaktionen auf Kontextaufblähung

Der Artikel identifiziert drei Branchenansätze:

• MCP mit Komprimierungstricks: Schemata komprimieren, Werkzeugsuche verwenden, um Definitionen bei Bedarf zu laden, oder Middleware bauen, die OpenAPI-Spezifikationen in kleinere Teile zerlegt. Dies funktioniert für kleine, klar definierte Interaktionen, erhöht aber den Infrastrukturbedarf (Werkzeugregister, Suchlogik, Caching, Routing).
• CLI-first-Schnittstellen: Der von Apideck CLI gewählte Ansatz.
• Agent-nativer Protokolle: Erwähnt, aber nicht im bereitgestellten Quelltext detailliert beschrieben.