Die Token-Steuer auf Tools, die du nie aufrufst

Verbinde einen Model-Context-Protocol-Server mit einem Agenten, und etwas passiert, bevor der Agent überhaupt arbeitet. Die meisten Clients nehmen jedes Tool, das dieser Server bereitstellt, und laden dessen Definition in den Kontext des Modells: den Namen, eine Beschreibung, das JSON Schema, das seine Argumente beschreibt. Diese Nutzlast sitzt im Kontext, und du bezahlst dafür, egal ob der Agent das Tool einmal oder nie aufruft.

Wir lesen eine Tool-Liste meist so, wie wir im Restaurant eine Speisekarte lesen. Mehr Optionen sehen nach mehr Können aus, und im Restaurant sind die Optionen tatsächlich gratis, bis du bestellst. Hier sind sie es nicht. Jeder Eintrag ist Text, der dauerhaft im Kontext liegt und den das Modell auf dem Weg zu jeder Entscheidung liest, und die Rechnung beginnt in dem Moment, in dem er auf die Karte kommt, bevor jemand bestellt.

Hier ist die Form einer Definition, direkt aus der Spezifikation:

{
  "name": "get_weather",
  "description": "Get current weather information for a location",
  "inputSchema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City name or zip code"
      }
    },
    "required": ["location"]
  }
}

Ein einzelnes Tool ist nichts. Das Problem ist, dass die Kosten mit der Größe des Katalogs skalieren, nicht mit der Größe der Aufgabe. Eine Aufgabe, die zwei Tools braucht, trägt trotzdem die Schemata für alle. Anthropic berichtet, dass ein typisches Setup aus fünf Servern rund 55.000 Token für Definitionen ausgibt, bevor der Agent irgendetwas tut, und weist darauf hin, dass die meisten Anfragen tatsächlich nur drei bis fünf dieser Tools brauchen. Treib den Katalog auf Tausende von Tools, und der Agent verarbeitet Hunderttausende Token, bevor er die Anfrage überhaupt liest. Ihre drastischste Zahl stammt aus einem anderen Fall, einem Workflow, der Daten von Google Drive nach Salesforce bewegt und von 150.000 Token auf 2.000 fiel. Der aber bündelt zwei Einsparungen, weniger geladene Definitionen und das Heraushalten der bewegten Daten aus dem Kontext, also lies ihn als das äußerste Ende der Kurve und nicht als Rate, die du auf deine eigene Tool-Liste anwenden kannst.

Token sind nur die sichtbare Hälfte der Steuer. Die leisere Hälfte ist die Auswahlqualität. Jedes zusätzliche Tool im Kontext ist eine Sache mehr, die das Modell beim Entscheiden von den anderen auseinanderhalten muss, und jenseits von etwa dreißig bis fünfzig Tools beginnt seine Treffsicherheit beim Auswählen des richtigen zu sinken. Die Definitionen helfen nicht immer: Aggregiere ein paar Server, und du stößt auf die Kollision, die die Spezifikation nennt, zwei verschiedene Server, die jeweils ein search-Tool bereitstellen, was jetzt ein unterscheidendes Präfix braucht, damit das Modell nicht nach dem falschen greift. Aus einer größeren Karte ist auch schwerer zu bestellen.

Ein berechtigter Einwand stumpft eine dieser Hälften ab. Der Tool-Block steht am Anfang des Prompts, der am besten cachebaren Region überhaupt, also liest der Agent ihn nach dem ersten Zug billig erneut. Stimmt, aber Caching rabattiert die Dollars, nicht das Kontextfenster, das die Definitionen belegen, und nicht die Treffsicherheit, die sie kosten. Es erstattet das erneute Lesen und lässt die zwei Dinge, die wirklich beißen, unberührt.

Hier fängt es an, dass der Aufruf eines Kommandozeilen-Tools weniger wie ein Rückschritt aussieht. Eine CLI, die der Agent aufruft, hält ihr Schema aus dem dauerhaft aktiven Kontext heraus; die Schnittstelle lebt in einem --help, das der Agent nur liest, wenn er sich entscheidet, das Ding zu benutzen. Ich stütze mich in meinem eigenen Setup darauf: Für Routinearbeit gegen ein internes Dashboard ruft der Agent einen gekapselten Befehl auf, statt die rohe API von Hand zusammenzubauen. Die Schema-Kosten sind aber nicht weg, sie haben sich verschoben. Was im Kontext verbleibt, ist ein Zeiger, eine Zeile irgendwo, die dem Agenten sagt, dass der Befehl existiert und wann er danach greifen soll, und die volle Argumentliste taucht erst beim Aufruf auf. Das ist der ganze Trick, und ja, das --help sind immer noch Token, sobald der Agent es liest.

Die verlockende Lehre lautet „CLIs schlagen MCP-Server", und sie ist die falsche. Die CLI gewinnt nicht, weil sie eine CLI ist. Sie gewinnt, weil sie die Schema-Kosten aufschiebt, bis die Arbeit nach dem Tool greift, und ein Server kann genauso aufschieben. Anthropics eigene Antwort auf das Token-Problem gibt MCP nicht auf; sie ändert, wann die Definitionen laden, und die Claude API liefert das jetzt als Einstellung. Markiere ein Tool mit defer_loading, und es bleibt aus dem Prompt heraus, bis ein Such-Tool es hervorholt, woraufhin sein Schema an die Konversation angehängt ankommt. Dieses letzte Detail ist das, worauf es ankommt. Das Laden auf Abruf muss anhängen, weil der Tool-Block am Anfang des Prompts lebt, wo der Cache liegt; ein entdecktes Schema als Ergebnis zu liefern lässt dieses gecachte Präfix intakt, während das Bearbeiten des registrierten Tool-Sets an Ort und Stelle es neu schreibt und für das Privileg bezahlt. Schiebe durch Anhängen auf, und du hörst auf, das ganze Gebäude zu mieten, um einen Raum zu benutzen.

Der Rahmen, der übrig bleibt, ist also gar kein Protokollkrieg. Die Tool-Oberfläche ist ein Token-Budget, und du solltest sie wie eines bepreisen. Jede Fähigkeit, die du eingeschaltet lässt, ist Kontext, den du in jede Entscheidung trägst, die der Agent trifft. Bevor du das nächste Tool hinzufügst, stell die Frage, die die Kosten wirklich vorhersagt: Wird der Agent bei der Arbeit vor ihm danach greifen, oft genug, um seinen Platz am Anfang des Prompts zu verdienen?

Diese Frage hat eine Kehrseite, die der Steuer-Rahmen verbergen kann: Manchmal ist das dauerhaft geladene Tool die richtige Wahl. Anthropics eigene Faustregel hält die Handvoll Tools geladen, die bei fast jeder Anfrage genutzt werden, und schiebt den langen Schwanz auf, denn ein Tool, nach dem der Agent ständig greift, ist dauerhaft geladen billiger, einmal bezahlt und gecacht, als jedes Mal danach zu suchen. Und manche Tools lassen sich gar nicht aufschieben. Nichts davon ist ein Argument gegen das Bauen von Servern, und ich liefere einen. clipboard-mcp ist ein kleines Rust-Binary, und der Grund, warum es einen dauerhaften Platz verdient, ist nicht Vorliebe, sondern Form: Eines seiner drei Tools beobachtet die Zwischenablage auf Änderungen, was einen lebenden, an die Session gebundenen Prozess braucht, was ein einmaliger Shell-Aufruf nicht sein kann. agent-recall, eine Memory-Bibliothek, die ich pflege, trifft die entgegengesetzte Wahl, auf der Ausgabeseite: Eine Abfrage gibt ein zusammengefasstes Briefing zurück statt der rohen Zeilen dahinter, weil die Zeilen im Kontext landen und dort den Rest der Session sitzen würden. Diese Kosten fallen pro Aufruf an statt pro Zug, aber sie belohnen dieselbe Sorgfalt.

Die Zahl, auf die es zu achten gilt, ist nicht, wie viele Tools dein Agent sehen kann. Es ist, ob die Token, die er für Definitionen ausgibt, sich bewegen, wenn die Aufgabe es tut. Ändere die Aufgabe, und eine korrekt bepreiste Oberfläche gibt anders aus, weil sie trägt, was diese Aufgabe braucht. Eine nach dem Katalog bepreiste Oberfläche gibt jedes Mal dasselbe aus, egal was die Arbeit ist, und das ist die Steuer, die in voller Höhe ankommt: Du bezahlst für Tools, die du nie aufrufst.