MCP verursacht hohe Kosten vor der ersten Aktion
Das Model Context Protocol, kurz MCP, verbindet KI-Modelle mit externen Werkzeugen und Datenquellen. In der üblichen Implementierung werden jedoch umfangreiche Werkzeugdefinitionen in den Prompt geladen. Das belegt Kontextraum und verursacht API-Kosten, bevor der Agent eine produktive Aufgabe erledigt.
Mario Zechner, Entwickler des Coding-Agenten Pi, hatte MCP deshalb lange nicht nativ integriert. Beim Chrome DevTools MCP belegten die vorab geladenen Definitionen rund 18.000 Token. Das entspricht etwa 9 % eines Kontextfensters mit 200.000 Token.
| Komponente | Prompt-Verbrauch | Anteil an 200.000 Token |
|---|---|---|
| Chrome DevTools MCP | ca. 18.000 Token | ca. 9 % |
| Playwright MCP mit 21 Werkzeugen | ca. 13.700 Token | ca. 6,8 % |
| Frühere CLI-Browserwerkzeuge von Pi | 225 Token Dokumentation | ca. 0,1 % |
Mit jedem zusätzlichen MCP-Server kann dieser Grundverbrauch weiter steigen. Das betrifft nicht nur die Rechnung des Modellanbieters. Weniger verfügbarer Kontext kann auch dazu führen, dass relevante Anweisungen, Quelltexte oder Zwischenergebnisse früher verdrängt werden.
Pi 1.0 setzt Codemode zwischen Modell und Werkzeuge
Pi wurde Anfang des Jahres von Earendil übernommen. Mit Pi 1.0 hat der Coding-Agent nun native MCP-Unterstützung erhalten, allerdings ohne sämtliche Werkzeugdefinitionen direkt an das Modell zu übergeben.
Die Zwischenschicht heißt Codemode. Sie läuft in einer isolierten QuickJS-Sandbox und kann benötigte Werkzeuge per JavaScript suchen, aufrufen und deren Ergebnisse vorfiltern. Die Sandbox besitzt weder Node-APIs noch direkten Zugriff auf Dateisystem, Netzwerk oder Zeitgeber.
Im Prompt erscheint standardmäßig nur eine einzeilige Beschreibung des jeweiligen MCP-Servers. Die detaillierten Werkzeugdefinitionen bleiben außerhalb des Modellkontexts und werden erst bei Bedarf auffindbar. Damit verfolgt Pi einen ähnlichen Ansatz wie andere Optimierungen, die den Tokenverbrauch von Agenten-Frameworks gezielt reduzieren.
Sinngemäß erklärt Earendil: MCP wurde nicht nur wegen der Weiterentwicklung des Protokolls in den Kern aufgenommen. Auch die dafür notwendigen technischen Änderungen hätten sich grundsätzlich als nützlich erwiesen.
Werkzeuge lassen sich einzeln freigeben
Über toolExposure kann festgelegt werden, wie Pi mit einzelnen Funktionen umgeht. Bestimmte Werkzeuge können direkt im Prompt sichtbar sein, nur über Codemode aufgerufen oder vollständig blockiert werden.
Bei einer GitHub-Anbindung könnte beispielsweise die Codesuche direkt verfügbar sein. Lesezugriffe lassen sich hinter Codemode halten, während Löschoperationen gesperrt bleiben. Eine solche Trennung reduziert nicht nur den Prompt-Umfang, sondern unterstützt auch das Prinzip minimaler Berechtigungen, das angesichts bekannter Sicherheitslücken in MCP-basierten Agenten relevant ist.
Prompt-Footprint sinkt von 5.300 auf 3.300 Token
Codemode verwendet standardmäßig ein Budget von 3.000 Token für Werkzeugdeklarationen. Funktionen oberhalb dieser Grenze bleiben dynamisch auffindbar, ohne dauerhaft den Prompt zu belasten. MCP-Werkzeuge mit der voreingestellten Sichtbarkeit werden diesem Budget nicht zugerechnet.
| Messwert in Pi 1.0 | Vorher | Nachher |
|---|---|---|
| Prompt-Token bei einem Beispielaufruf mit GPT-5.6 | ca. 5.300 | ca. 3.300 |
| Standardbudget für Werkzeugdeklarationen | 3.000 Token | |
Die Reduktion von rund 2.000 Token entstand durch kürzere Codemode-Beschreibungen, ausgelagerte Dokumentation für Modell-APIs und das Vermeiden doppelter Deklarationen. Die Entwicklung knüpft an die bereits dokumentierte Senkung des Prompt-Overheads in Pi 1.0 an.
Das Problem der Weiterverarbeitung bleibt relevant
Zechner kritisiert außerdem die eingeschränkte Komponierbarkeit klassischer MCP-Aufrufe. Damit ist gemeint, dass Ergebnisse nicht ohne Weiteres direkt an andere Werkzeuge übergeben, gefiltert oder gespeichert werden. Stattdessen müssen sie häufig zunächst durch das Kontextfenster des Agenten laufen.
Sinngemäß nach Mario Zechner: Ergebnisse eines MCP-Servers müssen durch den Kontext des Agenten geschleust werden, um auf der Festplatte gespeichert oder mit anderen Ergebnissen kombiniert zu werden.
CLI-Werkzeuge und Skripte sind in diesem Punkt häufig schlanker. Ausgaben lassen sich über bekannte Mechanismen filtern, weiterreichen oder speichern, ohne sie vollständig an das Modell zu senden. Codemode überträgt einen Teil dieses Prinzips auf MCP, beseitigt aber nicht automatisch alle grundsätzlichen Einschränkungen des Protokolls.
Was Unternehmen daraus ableiten können
Für eigene KI-Agenten sollte nicht nur die Zahl der verfügbaren Werkzeuge bewertet werden. Entscheidend ist auch, wie viele Token deren Beschreibungen bei jeder Anfrage belegen. Besonders bei mehreren MCP-Servern kann daraus ein dauerhafter Kostenblock entstehen.
Eine sinnvolle Architektur hält selten benötigte Werkzeuge aus dem Standard-Prompt heraus, begrenzt Berechtigungen und verarbeitet umfangreiche Ergebnisse vor dem nächsten Modellaufruf. Leichtgewichtige Skripte, eigene CLI-Werkzeuge und isolierte Ausführungsumgebungen können dafür eine wirtschaftliche Alternative zu umfangreichen Agenten-Frameworks sein.
Für Unternehmen im DACH-Raum kommen Datenschutz und Kontrolle über Datenflüsse hinzu. Eine Sandbox ohne direkten Netzwerk- oder Dateisystemzugriff reduziert die Angriffsfläche, ersetzt jedoch keine Prüfung des gesamten Agenten-Workflows. Welche Auswirkungen die dynamische Werkzeugerkennung auf Latenz und Laufzeit hat, ist bislang nicht belegt. Auch zu Lizenzbedingungen und Kosten von Pi 1.0 nennt das vorliegende Material keine Details.