MCP-Tool-Overhead: 26 Tools kosten $0.03 pro Aufruf

Wer einen MCP-Server an seinen Agenten anbindet, zahlt schon vor der eigentlichen Arbeit einen Aufpreis pro Aufruf: Die 26 Tools des GitHub-Servers kosten bei jedem einzelnen Aufruf von Claude Opus 4.8 $0.0302, unabhängig davon, ob ein Tool verwendet wird. Sichtbar wird dieser Mechanismus erst in den Verbrauchsdaten. Die Höhe hängt stärker vom verwendeten Modell als von der Anzahl angebundener Tools ab, lässt sich aber größtenteils reduzieren. Wir haben die gesamte Kette vermessen: fünf Modellfamilien, fünf reale MCP-Server, synthetische Staffeln mit 0 bis 40 Tools sowie die Einsparungen durch Caching und schlankere Schemas.

TL;DR

• Tool-Definitionen werden bei jedem API-Aufruf erneut als Input-Token berechnet; ein kleines Tool belegte bei Claude Opus 4.8 genau 401 Token.
• Dasselbe Toolset kostet bei Claude 2.7x mehr Token als bei GPT-5.6 (gemessen wurden 173 gegenüber 64 pro Tool).
• Der reale GitHub-MCP-Server mit 26 Tools kostet bei Opus 4.8 pro Aufruf $0.0302, bei Gemini 3.6 Flash dagegen $0.0029. Das ist ein Unterschied um den Faktor 10.
• Explizites Caching reduziert die laufenden Kosten des Blocks auf ein Zehntel. Toolsets unterhalb der Mindestgröße lassen sich jedoch nicht cachen, und schon die Änderung eines einzelnen Tools führt zur erneuten Abrechnung des gesamten Blocks.

Wie werden aus einem MCP-Server Input-Token?

Die Verarbeitung besteht aus drei Stufen. Kosten entstehen erst in der letzten, dafür bei jedem Aufruf erneut. Vorab zur Abgrenzung: MCP-Server stellen drei Primitive bereit: Tools, Ressourcen und Prompts. Nur Tools verursachen laufende Kosten, weil der API-Parameter tools bei jeder Anfrage sämtliche Schemas enthalten muss. Für Ressourcen und Prompts gibt es keine eigenen API-Felder. Sie kosten erst dann Token, wenn ihr Inhalt tatsächlich in die Konversation geladen wird. In Stufe 1 fragt der Agent-Client die Schemas per JSON-RPC mit tools/list vom MCP-Server ab. Das geschieht einmal pro Session und beansprucht kein Modell. In Stufe 2 überführt der Client die Schemas in den API-Parameter tools und entfernt dabei MCP-spezifische Felder wie annotations und outputSchema. Auch das ist kostenlos. In Stufe 3 rendert der Provider diese Schemas bei jeder Anfrage als verborgenen Prompt-Text. Die API ist zustandslos, das Modell kann sich also nicht merken, welche Tools verfügbar sind. Dieser gerenderte Text wird bei jedem Aufruf zum vollen Input-Tarif berechnet, unabhängig davon, ob die Tools verwendet werden.

Das kleinste mögliche Beispiel: Eine Anfrage, deren User-Nachricht nur „Reply OK“ lautet, kostet bei Opus 4.8 genau 11 Prompt-Token. Kommt ein einfaches get_weather-Tool mit zwei Parametern und einer einzeiligen Beschreibung hinzu, kostet dieselbe Anfrage 412 Token. Dieses einzelne Tool erhöht also jeden Aufruf um 401 Token beziehungsweise $0.002. Auffällig ist der Unterschied zu den übertragenen Daten: Das JSON des Tools umfasst als Text nur etwa 130 Token, durch das Rendering des Providers verdreifacht sich die Zahl fast.

Was kostet ein Tool je Modell?

Das Modell hat einen deutlich größeren Einfluss, als die meisten Teams erwarten. Wir haben identische synthetische Toolsets mit je drei Parametern und einzeiligen Beschreibungen in Staffeln von 0 bis 40 Tools durch fünf Modellfamilien geschickt und die abgerechneten Differenzen ausgewertet:

Bei denselben Tools liegt der Unterschied bei 2.7x: Claude erzeugt den ausführlichsten Tool-Harness der Gruppe, GPT-5.6 den kompaktesten. Auch das Verhältnis zum übertragenen JSON variiert in beide Richtungen. Claude berechnet etwa das 1.36-Fache einer groben Schätzung aus Bytezahl geteilt durch vier. GPT-5.6 und Gemini kommen dagegen auf ungefähr die Hälfte dieses Werts. Die Token-Anzahl von Tool-Blöcken lässt sich nicht zwischen Modellfamilien übertragen. Die Kalkulation muss deshalb pro Modell erfolgen, nicht pro Schema.

Was kosten reale MCP-Server pro Aufruf?

Die folgende Tabelle zeigt fünf echte, unveränderte Server aus dem offiziellen MCP-Repository. Wir haben sie über das übliche Feld-Mapping konvertiert und den mitgeführten Overhead pro Aufruf gemessen:

Die letzte Zeile zeigt zwei Dinge. Sequential-thinking stellt nur ein Tool bereit, kostet aber bei vier der fünf Modellfamilien mehr als die neun Tools von Memory. Der Grund ist die extrem lange Beschreibung des einzelnen Tools: Entscheidend ist nicht die Anzahl der Tools, sondern die gerenderte Größe. Die oberste Zeile dürfte für Entwickler von Agenten noch überraschender sein: Wird das GitHub-Toolset über eine Agenten-Episode mit 10 Aufrufen mitgeführt, kostet das bei Opus 4.8 insgesamt $0.30, bei Gemini dagegen $0.03. Noch bevor die eigentliche Arbeit beginnt, liegt eine volle Größenordnung dazwischen. GLM 5.2 ist in Dollar sogar noch günstiger, obwohl es mehr als doppelt so viele Token wie Gemini berechnet. Ein niedriger Listenpreis gleicht also ein ausführlicheres Rendering aus. Token und Kosten sollten getrennt kalkuliert werden.

Wie viel vom Toolset verwenden Agenten tatsächlich?

Pro Aufruf meist nur einen kleinen Teil. Deshalb wirkt dieser Aufpreis besonders unverhältnismäßig. Im Tooling-Szenario unserer Agent-Suite wird ein Set aus 8 Tools bei allen drei Aufrufen einer typischen Episode mitgeführt, obwohl jeder Aufruf höchstens ein Tool verwendet. Jeder Aufruf bezahlt also acht Schemas, um eines davon zu nutzen. Zu den gemessenen Tarifen von Opus 4.8 belegt dieser Block aus 8 Tools etwa 1,674 Token pro Aufruf. Pro Episode entstehen damit rund 5,000 Token allein durch das Mitführen der Schemas. Das Tool-Loop-Szenario ist günstiger ausgelastet: Drei Tools werden bei fast jedem Aufruf eingesetzt. Trotzdem wird der Block bei allen vier bis fünf Aufrufen der Schleife erneut übertragen. Die Datensätze zeigen ein klares Muster: Pro Aufruf kommt selten mehr als ein Tool zum Einsatz. Die Kosten des Toolsets skalieren daher mit dem, was angebunden ist, nicht mit dem, was der Agent tatsächlich ausführt.

Kann Caching die Tool-Kosten auffangen?

Bei den richtigen Modellen größtenteils, allerdings haben wir drei klare Einschränkungen gemessen. Bei Claude Opus 4.8 ist der Tool-Block ein cachefähiges Präfix erster Klasse. Nachdem wir das letzte Tool mit cache_control markiert hatten, wurde unser Block aus 20 Tools einmalig geschrieben: 3,682 Token mit dem 1.25x-Aufschlag für Schreibvorgänge. Jeder weitere Aufruf las ihn zum Faktor 0.1x aus dem Cache, wodurch die effektiven laufenden Kosten um 90% sanken. Das automatische Caching von Kimi K3 schnitt ohne jede Konfiguration noch besser ab: Beim zweiten Aufruf kamen 2,048 der 2,112 Token des Blocks aus dem Cache, also 97%, wie üblich in Blöcken zu 256 Token. Die expliziten Breakpoints von GPT-5.6 bepreisen dieselbe Struktur mit 1.25x für Schreibvorgänge und 0.1x für Lesevorgänge, wie unsere Messungen dieser Modellfamilie am ersten Tag zeigten. Geminis impliziter Cache lieferte bei drei vorbereiteten Tests des Tool-Blocks keinen einzigen Treffer. Das entspricht unseren sonstigen Messungen dazu. Ein möglicher Rabatt sollte dort als Bonus gelten, nicht als Kalkulationsgrundlage.

Die drei Einschränkungen: Erstens gibt es eine Mindestgröße. Ein Block aus 2 Tools umfasst bei Claude etwa 655 Token und liegt damit unter dem Cache-Minimum von 1,024 Token. Kleine Toolsets lassen sich deshalb auch mit expliziter Markierung überhaupt nicht cachen. Die modellspezifischen Mindestgrößen bestimmen, ob diese Optimierung verfügbar ist. Zweitens sind Änderungen teuer. Der Tool-Block steht ganz am Anfang des Prompts. Jede Änderung an der Tool-Liste invalidiert daher auch alles, was dahinter liegt. Wir haben den Effekt direkt gemessen: Nach dem Hinzufügen eines Tools zu einem gecachten Set aus 20 Tools schrieb Claude Opus 5 den gesamten Block mit 4,082 Token erneut und berechnete dafür den erhöhten Schreibpreis. Die Tool-Liste sollte während einer Session unverändert bleiben, andernfalls fällt der Schreibpreis bei jeder Änderung erneut an. Drittens soll genau diese Einschränkung durch Anthropics Beta für Tool-Änderungen während einer Konversation aufgehoben werden, die für Opus 5 dokumentiert ist. Damit können Tools zwischen Turns geändert werden, ohne den Cache zu invalidieren. Für Agenten mit vielen Tools ist das die relevante Funktion.

Wie lässt sich der Tool-Block verkleinern?

Zuerst Parameter reduzieren, dann Beschreibungen. Bei unserem Block aus 20 Tools brachte das Kürzen der Beschreibungen auf jeweils einen knappen Teilsatz eine Einsparung von 10%. Die Reduktion von drei Parametern auf einen sparte 34%. Zusammen sank der Verbrauch um 44%, von 3,768 auf 2,128 Token. Die meisten Token stecken in den Parameterschemas, also in Namen, Typen und verschachtelten Beschreibungen. Das widerspricht der üblichen Vorgehensweise, Beschreibungen sorgfältig zu kürzen, während Schemas unkontrolliert wachsen.

Noch wirksamer ist es, ungenutzte Tools gar nicht erst anzubinden. Jeder zusätzliche MCP-Server hängt seinen vollständigen Block an jeden Aufruf. Eine zweite Konfigurationszeile kann den Aufpreis also verdoppeln. Wenn der Client Filter unterstützt, lässt sich durch die Registrierung einer Teilmenge der Server-Tools der Overhead ungefähr proportional reduzieren. Bleiben vom GitHub-Server nur fünf der 26 Tools aktiv, sinken die $0.0302 von Opus 4.8 bei durchschnittlicher Tool-Größe des Servers schätzungsweise auf $0.007. Wer Modelle aus mehreren Familien verwendet, sollte außerdem den oben gemessenen Unterschied von 2.7x einplanen. Wird derselbe Agent ohne neue Kalkulation von Gemini auf Claude umgestellt, verdreifacht sich der Token-Verbrauch für das Mitführen der Tools nahezu.

FAQ

Verursacht MCP selbst Token-Kosten?

Nein. Das MCP-Protokoll, die Discovery, JSON-RPC und die technische Ausführung von Tools berühren das Modell nicht und werden nicht berechnet. Kosten entstehen erst, wenn der Client die Schemas des Servers an den API-Parameter tools übergibt. Der Provider rendert sie bei jedem Aufruf erneut als kostenpflichtigen Prompt-Text. MCP sorgt vor allem für die Größenordnung: 26 Tools lassen sich mit einer einzigen Zeile anbinden, danach werden aber auch 26 Schemas bei jedem Aufruf mitgeführt.

Kosten ungenutzte Tools etwas?

Ja, genauso viel wie genutzte. Das Modell muss bei jedem Aufruf alle Schemas lesen, um zu wissen, welche Tools es aufrufen könnte. Unsere Datensätze aus der Agent-Suite zeigen höchstens einen Tool-Aufruf pro API-Aufruf, während jedes Mal das vollständige Set berechnet wird. Ein angebundener, aber ungenutzter Server verursacht reine Mitführungskosten. Caching kann sie reduzieren, vollständig entfernen lassen sie sich nur durch kleinere Toolsets oder das Trennen der Verbindung.

Kosten MCP-Ressourcen und -Prompts wie Tools Token?

Nein. Nur Tools verursachen Kosten bei jedem Aufruf, weil über den Parameter tools sämtliche Schemas mit jeder Anfrage erneut übertragen werden. Ressourcen werden erst berechnet, wenn der Client sie liest und ihren Inhalt in die Konversation einfügt. Dann handelt es sich um normalen Input, der wie jedes abgerufene Dokument bepreist wird. Dabei gilt dieselbe Schichtung: Veränderliche Ressourceninhalte gehören hinter die Cache-Breakpoints. Auch Prompt-Templates kosten erst bei ihrer Verwendung Token, und zwar für den von ihnen erzeugten Text. Ungenutzte Ressourcen und Prompts eines angebundenen Servers sind kostenlos. Taucht eine MCP-Integration auf der Rechnung auf, sollten deshalb zuerst die Tools geprüft werden.

Invalidiert eine Änderung der Tool-Liste den Prompt-Cache?

Ja, vollständig. Der Tool-Block wird am Anfang des Prompts gerendert. Jede Änderung schreibt ihn und alle dahinterliegenden Cache-Inhalte neu. Bei unserer Messung führte das Hinzufügen eines einzelnen Tools dazu, dass ein Block mit 4,082 Token erneut zum erhöhten Faktor 1.25x berechnet wurde. Die Tool-Liste sollte pro Session unverändert bleiben, Änderungen sollten gebündelt werden. Anthropics Beta für Tool-Änderungen während einer Konversation soll genau diesen Nachteil bei Opus 5 beseitigen.

Gemessen am 2026-07-31 über das Synthorai-Gateway: synthetische Tool-Staffeln mit 0-40 Tools und n=2 sowie fünf reale Toolsets von MCP-Servern, deren Schemas live per JSON-RPC tools/list von den offiziellen Servern abgerufen wurden, jeweils über fünf Modellfamilien hinweg; Cache-Tests mit gesalzenen Präfixen und aufgeschlüsselten Cache-Positionen pro Aufruf; Agent-Auslastung aus den Suite-Datensätzen hinter unseren Studien zu Agentenkosten. Die Caching-Faktoren für GPT-5.6 stammen aus den Messungen unseres Kostenleitfadens vom ersten Tag. Die Dollarbeträge sind Differenzen der abgerechneten Kosten, ausgelesen aus dem Gateway-Zähler, der den Listenpreis für Input zugrunde legt. Preise und Rendering-Verhalten können sich ändern; gleichen Sie die Werte mit Ihren eigenen Nutzungsdaten ab.

← Zurück zum Blog