Dein Agent verbrennt 55.000 Token für Tool-Beschreibungen, bevor du ein Wort tippst

Anthropic hat ein Beispiel mit fünf Servern veröffentlicht, zu dem ich immer wieder zurückkomme. GitHub, Slack, Sentry, Grafana und Splunk an einem Agenten: 58 Tools, rund 55.000 Token an Tool-Definitionen. Das sind 27% eines 200K-Kontextfensters, ausgegeben, bevor der Agent ein einziges Wort deiner Anfrage gelesen hat. Nimm Jira dazu, und derselbe Beitrag sagt, dass du dich 100.000 Token näherst. In ihren eigenen internen Tests trug ein Setup 134.000 Token an Tool-Definitionen.

Ich baue Claude-Code-Skills und Agenten für Kunden und nutze diese Werkzeuge jeden Arbeitstag. Lange habe ich kein einziges Mal über MCP-Token-Verbrauch nachgedacht. Ich habe die verbundenen Server als kostenlos behandelt. Server verbinden, Fähigkeiten bekommen, fertig. Sie sind nicht kostenlos. Sie sind eine Grundgebühr auf jedem einzelnen Zug jedes einzelnen Gesprächs, und das meiste, wofür du zahlst, ist ein JSON-Schema, das das Modell nie aufrufen wird.

Was 55.000 Token dir tatsächlich kaufen

Die Zahlen schwanken je Server enorm, und das ist das Erste, was man verinnerlichen sollte. Ein öffentlicher Benchmark, der am 08.07.2026 neun populäre Server über stdio mit dem o200k_base-Tokenizer gemessen hat, fand eine Effizienzspanne von Faktor 25. Der offizielle Notion-Server: 24 Tools, 17.161 Token, 8,6% eines 200K-Fensters. Firecrawl: 26 Tools, 16.565 Token. Slack: 8 Tools, 679 Token. Der archivierte npm-GitHub-Server: 26 Tools, 3.546 Token. Gleiches Protokoll, gleiche Idee, zwei Größenordnungen Unterschied im Preis fürs Angesteckt-Lassen.

Andere Messungen des aktuellen offiziellen GitHub-Servers liegen deutlich höher, im Bereich von 17.000 bis 42.000 Token, je nachdem, welche Toolsets aktiviert sind. Diese Spanne ist keine schlampige Messung. Es sind die Toolset-Flags, die genau das tun, wofür sie da sind, und sie sagt dir, wo der Hebel liegt.

Unangenehm ist, dass diese Kosten kein einmaliges Laden sind. Es ist nicht wie eine große Datei, die du einmal liest und die dann aus der Relevanz rausrollt. Tool-Definitionen sitzen in jedem Zug im Request, denn das Modell muss jederzeit im Gespräch ein Tool wählen können.

Warum bei jedem Zug das ganze Schema mitgeht

Tools sind kein Code, den das Modell aufruft. Es ist Text, den das Modell liest. Jedes Tool, das du verbindest, wird zu einem Namen, einer Beschreibung und einem vollständigen JSON-Schema für seine Eingabe, serialisiert in den Request neben deinem System-Prompt und deinem Gespräch. Das Modell hat kein Verzeichnis, in dem es nachschlagen kann. Es hat eine flache Liste, im Prompt, jedes Mal.

Wenn du also einen Server mit 35 Tools verbindest und den Agenten dann bittest, eine Variable umzubenennen, liest der Agent trotzdem alle 35 Tool-Schemata. Er liest die Pagination-Parameter des Issue-Such-Tools. Er liest das Enum gültiger Sortierreihenfolgen des Pull-Request-Listers. Dann benennt er deine Variable um. Genau das meinen Leute, wenn sie sagen, MCP-Token-Verbrauch frisst dein Kontextfenster: nicht dass die Tools geschwätzig sind, wenn sie laufen, sondern dass sie teuer sind, wenn sie stillstehen. Wenn dir die Mechanik des Protokolls neu ist, habe ich einen längeren Text zu Model Context Protocol (MCP): Everything you need to know geschrieben, der behandelt, wie Client und Server tatsächlich reden.

Prompt Caching mildert die Geldseite davon, denn ein stabiler Tool-Block lässt sich cachen und billig wieder lesen. Für die Kontextseite tut es nichts. Gecacht oder nicht, diese 55.000 Token belegen weiterhin das Fenster.

Die Rechnung besteht nicht überwiegend aus Beschreibungen

Hier ist der Befund, der verändert hat, wie ich Tools schreibe. In demselben Benchmark steckten 97% der Token-Kosten von Notion in inputSchema, nicht in den menschenlesbaren Beschreibungen. Die Prosa war in Ordnung. Die Parameterdefinitionen waren gewaltig.

Das Team hat es als 7 Workflow-Tools statt 24 Endpunkt-Tools neu entworfen und dieselbe praktische Abdeckung für 773 Token bekommen. Von 17.161 auf 773, minus 95,5%, indem verändert wurde, was ein Tool ist, statt Adjektive zu kürzen.

Das ist die eigentliche Lehre. Die meisten MCP-Server sind eine dünne Hülle um eine REST-API, ein Tool pro Endpunkt, ein Schema pro Tool, jeder optionale Query-Parameter getreu abgebildet. Dieses Design ist ehrlich und leicht zu generieren, und es ist der Grund, warum dein Kontextfenster voll ist. Ein Tool, das sagt "erstelle eine Seite in dieser Datenbank mit diesem Titel und diesem Inhalt", kostet einen Bruchteil eines Tools, das jedes Feld freilegt, das die Notion-API akzeptiert, und es ist das, das dein Agent tatsächlich gebraucht hat.

Der eigentliche Schaden ist die Tool-Auswahl

Wären es nur Token, könntest du dich mit einem größeren Fenster freikaufen. Das schlimmere Problem ist, dass das Modell schlechter darin wird auszuwählen.

Anthropics eigene Auswertung liefert den saubersten Beleg, denn sie hält alles andere konstant und ändert nur, ob Tools vorab geladen oder bei Bedarf gesucht werden. In ihrer MCP-Auswertung ging Opus 4 von 49% auf 74% Genauigkeit. Opus 4.5 ging von 79,5% auf 88,1%. Die Tools haben sich nicht geändert. Das Modell hat sich nicht geändert. Geändert hat sich nur die Zahl der gleichzeitig im Kontext liegenden Tool-Definitionen, und ein Viertel der Fehler war weg.

Es kursiert eine viel dramatischere Zahl, aus Arbeiten rund um das Berkeley Function Calling Leaderboard, wo die Genauigkeit bei Terminplanungsaufgaben von 43% auf 2% fällt, während die Toolliste von 4 auf 51 wächst. Ich habe diese Zahl nur über Sekundärquellen gesehen, nicht an der Quelle, behandle sie also als Richtungsangabe und nicht als Fakt, den du in einem Meeting zitierst. Die Richtung ist allerdings unstrittig. Praktiker berichten durchgehend, dass die Qualität irgendwo jenseits von 15 bis 20 aktiv genutzten Tools zu rutschen beginnt.

In der Praxis sieht das nicht so aus, dass der Agent sagt, er sei verwirrt. Das sagt er nie. Er nimmt einen plausiblen Nachbarn. Er ruft das Such-Tool auf, wenn du das Get-Tool wolltest. Er ruft die Nur-Lese-Variante von dem auf, was er schreiben sollte. Du liest hinterher das Protokoll, und der falsche Aufruf sieht fast vernünftig aus, was genau der Grund ist, warum es schwer zu erwischen ist. Ich habe schon darüber geschrieben, welches Claude-Modell ich für Coding-Arbeit tatsächlich nutze, und ich sage das hier: Ein kleineres Modell mit fünf gut gewählten Tools schlägt ein größeres, das in sechzig ertrinkt.

Wie du deinen eigenen Overhead misst

Nimm nicht die Zahlen von irgendwem, meine eingeschlossen. Miss deinen eigenen MCP-Token-Verbrauch, denn deine Serverversionen und deine Toolset-Flags entscheiden die Antwort.

In Claude Code schlüsselt /context dein Fenster nach System-Prompt, Memory-Dateien, MCP-Tools und freiem Platz auf. Ein wichtiger Vorbehalt: Frühere Versionen haben den MCP-Verbrauch stark überzeichnet, weil sie jedes Tool in einem separaten Request gemessen und so den gemeinsamen System-Overhead einmal pro Tool gezählt haben. Ein Entwickler hat XcodeBuildMCP direkt mit rund 14.000 Token gemessen, während /context etwa 45.000 meldete. Das wurde im Januar 2026 behoben, stell also sicher, dass du aktuell bist, bevor du bei der Zahl in Panik verfällst.

Die präzise Methode ist der Token-Counting-Endpunkt. POST /v1/messages/count_tokens nimmt denselben Body wie ein normaler Message-Request, inklusive des tools-Arrays, und gibt die Eingabe-Tokenzahl zurück. Schick ihm deine Toolliste mit einer Ein-Wort-Nachricht, dann schick sie noch mal mit leerer Toolliste, und die Differenz ist deine Grundgebühr. Gleiche Modell-ID wie im Produktivbetrieb, denn die Zählungen sind modellspezifisch.

Die Offline-Methode, wenn du nur eine Rangfolge willst: Jeden Server starten, den tools/list-Handshake fahren, die Antwort als JSON serialisieren und mit einem Tokenizer zählen. Genau das hat der Neun-Server-Benchmark getan, und es ist ein Skript von zwanzig Zeilen.

Was du zuerst streichst

Fang mit den Servern an, die du seit einer Woche nicht aufgerufen hast. Nicht die, die du nicht nutzt, sondern die, die du nicht aufrufst. Das ist ein Unterschied, und die zweite Liste ist länger, als du erwartest.

Dann nutz die Toolset-Flags. Der offizielle GitHub-Server nimmt GITHUB_TOOLSETS, um nur die Gruppen zu aktivieren, die du brauchst, oder --dynamic-toolsets (GITHUB_DYNAMIC_TOOLSETS=1 in Docker), damit der Agent Gruppen einschalten kann, wenn ein Prompt danach verlangt. Issues und Pull Requests statt alles zu aktivieren ist die ertragreichste einzelne Änderung, die die meisten machen können, und sie kostet eine Zeile Konfiguration.

Danach teile nach Aufgabe statt nach Fähigkeit. Ein Sub-Agent mit vier Tools und einem engen Auftrag schlägt einen Generalisten mit vierzig, und er kostet pro Durchlauf auch weniger. Das ist derselbe Instinkt hinter dem meisten KI-Werkzeug, das meine Ein-Personen-Agentur betreibt: schmal, zweckgebaut, wegwerfbar.

Die Abwägungen sind real, sei also ehrlich zu ihnen. Von Hand zu filtern heißt, dass jemand die Allowlist pflegt, und sie veraltet. Lazy Loading kostet einen Rundlauf, um ein Tool zu finden, bevor es aufgerufen werden kann, also Latenz. Sub-Agenten kosten Orchestrierungskomplexität und eigenen Kontext. Viele Server hinter einem Gateway zu proxen zentralisiert das Ausdünnen und zentralisiert den Ausfall. Nichts davon ist kostenlos. Alles davon ist billiger als der Status quo.

Was ausgeliefert wurde und was noch Behelf ist

Echte Dinge sind ausgeliefert. Anthropics Tool Search Tool ist das große: Du markierst Tools mit defer_loading: true, sie bleiben über Regex- oder BM25-Suche auffindbar, und nur die Treffer kommen in den Kontext. Ihr veröffentlichtes Beispiel geht von rund 77.000 Token an Vorab-Definitionen auf rund 8.700 und erhält 191.300 Token nutzbares Fenster statt 122.800. Das ist die Reduktion um 85%, die alle zitieren, und sie kommt mit den Genauigkeitsgewinnen von oben. Claude Code wendet dieselbe Idee automatisch an, sobald deine MCP-Tool-Beschreibungen rund 10.000 Token überschreiten.

Programmatisches Tool Calling ist die andere Hälfte. Statt dass Tool-Ergebnisse durch das Modell zurückfließen, schreibt das Modell Code, der Tools aufruft, und bringt nur an die Oberfläche, was zählt. Anthropic hat gemessen, dass der Durchschnittsverbrauch bei komplexen Rechercheaufgaben von 43.588 auf 27.297 Token fällt, minus 37%, während die Genauigkeit in ihrem GIA-Benchmark von 46,5% auf 51,2% steigt.

Das Protokoll selbst hat sich vorsichtiger bewegt. Die Spezifikation vom 28.07.2026 ist die größte Überarbeitung seit dem Start: ein zustandsloser Kern, selbstbeschreibende Requests, ein optionaler Discovery-Aufruf, und Clients können tools/list-Antworten jetzt so lange cachen, wie es das ttlMs des Servers erlaubt. Das ist eine echte Verbesserung für die Infrastruktur und für wiederholte Kosten. Es ist kein Lazy-Loading-Mechanismus. Verzögertes Laden ist weiterhin ein Client-Feature, was heißt, dass es dort funktioniert, wo dein Client es implementiert, und sonst nirgends. Falls du dich je gefragt hast, warum sich dasselbe MCP-Setup in zwei Werkzeugen unterschiedlich verhält, das ist der Grund. Es ist auch ein Teil davon, warum ich für manche Arbeit ein lokales Modell im Spiel behalte, wo ich den ganzen Request kontrolliere und genau weiß, was drinsteht.

Was ich tatsächlich dagegen tue

Ich halte drei oder vier Server gleichzeitig verbunden, nicht fünfzehn. Ich teile Arbeit in Sub-Agenten mit kleinen Toolsets. Wenn ich für einen Kunden einen Server baue, schreibe ich Workflow-Tools, statt seine API Endpunkt für Endpunkt zu spiegeln, denn das Notion-Ergebnis hat mich überzeugt, dass dort das Geld liegt.

Ich habe keine saubere Regel dafür, wann sich ein Server seinen Platz verdient. Die ehrliche Faustregel, die ich benutze, lautet: Wenn ich mich nicht erinnere, wann der Agent ihn zuletzt aufgerufen hat, fliegt er raus. Das ist nicht streng. Es lag öfter richtig als falsch.

Ziemlich sicher bin ich mir, dass das in ein oder zwei Jahren aufhört, ein Problem zu sein, das man von Hand verwaltet, sobald verzögertes Laden allgemein statt client-spezifisch ist. Bis dahin ist es ein Konfigurationsproblem, das dir gehört, und es lohnt zwanzig Minuten mit /context und dem Token-Counting-Endpunkt. Wenn du auch abwägst, was der Betrieb kostet, habe ich die Break-even-Rechnung lokale Hardware gegen Cloud-APIs separat durchgespielt.

Wenn du Agenten für ein Unternehmen baust und dir der Tool-Wildwuchs davongelaufen ist, ist das die Art Sache, die ich für Kunden bei Wunderlandmedia entwirre. Meistens ist die Lösung kleiner, als Leute erwarten.