MCP-Server sind die brandneue Infrastruktur für Claude Code. Installieren Sie einen GitHub-Server, und Ihr Agent kann Pull Requests erstellen. Fügen Sie einen Filesystem-Server hinzu, und er liest Ihre Repository-Struktur. Die Demos wirken magisch. Was niemand demonstriert, ist die Rechnung.

Die Kosten liegen nicht in den API-Aufrufen, die die Tools tätigen. Sie liegen in den Tools selbst.

Jedes Mal, wenn Sie einen MCP-Server registrieren, fügen Sie nicht nur eine Fähigkeit hinzu. Sie fügen einen Textblock zu Ihrem Kontextfenster hinzu, und dieser Block wird bei jedem einzelnen Turn abgerechnet. Unabhängig davon, ob der Agent das Tool nutzt oder nicht, bezahlen Sie für dessen Existenz. Der Zähler läuft in dem Moment, in dem der Server die Verbindung herstellt.

Miete zahlen für Tools, die man nie benutzt

Hier ist der Mechanismus, der oft übersehen wird. Jede Tool-Definition in einem MCP-Server wird mit einem Namen, einer Beschreibung und einem JSON-Schema ausgeliefert, das dem Modell mitteilt, welche Argumente das Tool erwartet. Diese gesamte Payload wird zu Beginn jedes Turns in den Systemkontext injiziert. Das Modell muss den vollständigen Katalog sehen, um entscheiden zu können, ob es ein Tool aufrufen soll, aber Sie sind derjenige, der für diese Sichtbarkeit aufkommt.

Der Overhead pro Tool ist nicht trivial. In der Praxis verbraucht eine einzige Tool-Definition zwischen 80 und 150 Token. Das bedeutet, dass ein bescheidener Server, der zehn Tools bereitstellt, still und leise 800 bis 1.500 Token verbraucht, noch bevor Sie einen einzigen Satz getippt haben. Sie bezahlen nicht für Rechenleistung. Sie bezahlen für das Privileg, die Option zu haben.

Ich habe die Zahlen über eine Standard-Session von 20 Turns hinweg berechnet, um zu sehen, wie sich dies genau aufsummiert.

Ohne geladene MCP-Server liegt der Overhead bei Null. Das Kontextfenster enthält nur Ihre Konversation.

Laden Sie einen benutzerdefinierten Minimal-Server mit drei eng gefassten Tools, und die „Steuer“ beträgt 180 Token pro Turn. Über 20 Turns hinweg sind das 3.600 Token. Kein Desaster, aber echtes Geld.

Der beliebte Filesystem-Server, der sieben Tools bereitstellt, treibt diesen Wert auf 640 Token pro Turn. In derselben Session haben Sie 12.800 Token verbraucht, nur um die Verbindung aufrechtzuerhalten. Sie haben noch keine Datei gelesen. Sie haben noch kein Verzeichnis aufgelistet. Sie haben den Server lediglich „auf der Speisekarte“ behalten.

Dann ist da noch der GitHub-Server. Mit 26 registrierten Tools wirft er 3.100 Token in jeden Turn. Nach 20 Hin-und-Her-Nachrichten beläuft sich der Overhead auf insgesamt 62.000 Token. Bei den Preisen von Sonnet 4 entspricht das 0,19 $ an reiner Kontext-Steuer. Sie haben neunzehn Cent für den Overhead bezahlt, noch bevor der Agent überhaupt in Erwägung gezogen hat, ein Issue zu erstellen.

Diese Zahl wirkt isoliert betrachtet klein. Das ist sie nicht.

Das Problem der Agenten über Nacht

Wo es wirklich wehtut, sind langlaufende autonome Schleifen. Wenn Sie Claude Code als Agenten verwenden, der eigenständig iteriert, multipliziert sich diese Steuer pro Turn brutal. Ein Agent, der über Nacht 2.000 Turns lang mit geladenem GitHub-Server läuft, zahlt nicht 62.000 Token an Overhead. Er zahlt 6,2 Millionen.

Das sind 18,60 $ für buchstäblich nichts Produktives. Der Agent hätte die Nacht durchschlafen können, ohne ein einziges GitHub-Tool zu berühren. Er hätte ausschließlich mit lokalen Dateien gearbeitet. Sie werden dennoch für alle 26 GitHub-Tool-Definitionen in jedem dieser 2.000 Turns belastet, weil sie in der Session registriert waren.

Der entscheidende Punkt, den man verinnerlichen muss, ist: Sie bezahlen für registrierte Tools, nicht für aufgerufene Tools. Das Modell prüft nicht, welche Tools es tatsächlich nutzt, um dann Ihre Rechnung zu reduzieren. Wenn der Server verbunden ist, wird sein vollständiges Manifest in jedem Zyklus erneut in den Kontext eingeführt. Dies ist eine Steuer pro Turn auf das Potenzial, nicht auf die Aktion.

Für Entwickler, die iterative Coding-Agenten, Test-Harnesses oder Batch-Review-Jobs ausführen, ist dies ein stiller Budgetkiller. Eine menschliche Konversation von 20 Turns ist unbedenklich. Eine agentische Schleife von 200 oder 2.000 Turns ist der Punkt, an dem die Mathematik bestrafend wird.

So halten Sie die Kosten unter Kontrolle

MCP ist wirklich nützlich. Sie sollten es verwenden. Aber behandeln Sie es wie ein Werkzeug, das Sie nur für die anstehende Aufgabe einschalten, und nicht wie eine permanente Einrichtung, die Sie an jede Session anschrauben.

Konfigurationen auf Projekt und Aufgabe beschränken

Laden Sie nicht standardmäßig jeden Server in Ihre globale Claude Code-Konfiguration. Erstellen Sie projektbezogene MCP-Konfigurationen, die zu der Arbeit passen, die Sie tatsächlich leisten. Wenn Sie ein lokales Modul refactoren, benötigen Sie wahrscheinlich nur den Filesystem-Server und sonst nichts. Wenn Sie Issues triagieren, laden Sie den GitHub-Server für diese spezifische Aufgabe und trennen Sie die Verbindung wieder, wenn Sie zur lokalen Entwicklung zurückkehren.

Denken Sie daran wie beim Offenlassen von Apps auf Ihrem Smartphone. Eins oder zwei sind völlig in Ordnung. Zwanzig, die im Hintergrund laufen, ziehen ohne Grund den Akku leer.

Bevorzugen Sie Server mit weniger Tools

Nicht alle MCP-Server werden mit der gleichen Sorgfalt entwickelt. Einige bieten eine schlanke Schnittstelle mit zwei oder drei fokussierten Aktionen an. Andere liefern einen ausufernden Katalog von 25 oder 30 Tools mit, von denen Sie viele nie aufrufen werden. Ein Server mit drei Tools kostet Sie vielleicht 180 Token pro Turn. Einer mit 26 Tools kann 3.100 kosten. Das ist ein 17-facher Anstieg des Overheads für eine Funktionslücke, die für Sie vielleicht gar nicht relevant ist.

Bevor Sie einen Server installieren, werfen Sie einen Blick auf sein Tool-Manifest. Wenn es ein Dutzend sich überschneidender Operationen registriert, Sie aber nur eine benötigen, überlegen Sie, ob Sie es reduzieren, forken oder einen schlankeren Wrapper schreiben können. Jede Tool-Definition, die Sie entfernen können, ist eine direkte und dauerhafte Token-Ersparnis bei jedem zukünftigen Turn.

Tool-Beschreibungen kürzen

Der Bereich von 80 bis 150 Token pro Tool ist kein Naturgesetz. Er ist eine Funktion davon, wie wortreich die Beschreibungen und Schemata sind. Eine aufgeblähte 400-Token-Beschreibung verbraucht fünfmal so viel Kontext wie eine 80-Token-Beschreibung, und diese fünffache Belastung fällt bei jedem einzelnen Turn an.

Auditieren Sie die Server, auf die Sie sich verlassen. Wenn sich eine Tool-Beschreibung wie ein Werbetext liest, schreiben Sie sie um. Streichen Sie Adjektive. Streichen Sie Beispiele, die das Schema nicht verdeutlichen. Straffen Sie das JSON. Das Modell muss verstehen, was das Tool tut, aber es benötigt keinen Absatz voller Einleitung. Behandeln Sie Tool-Definitionen wie Code: Je kürzer und klarer, desto besser.

Das eigentliche Fazit

MCP erweitert, was Claude Code erreichen kann. Es erweitert Ihr Kontextfenster nicht kostenlos. Der Overhead ist deterministisch, wiederkehrend und völlig unabhängig davon, ob die Tools tatsächlich genutzt werden.

Laden Sie nur die Server, die Ihre aktuelle Aufgabe erfordert. Trennen Sie diese, wenn Sie fertig sind. Auditieren Sie die Anzahl der Tools und die Länge der Beschreibungen so, wie Sie jede andere Abhängigkeit auditieren würden. Die Regel ist einfach: Wenn das Tool in dieser spezifischen Sitzung keinen Mehrwert bietet, sollte es auch keine Token auf Ihrer Rechnung erhöhen.

Messungen und Methodik der Quelle: I added MCP servers to Claude Code — here’s what they cost in tokens

Werden Sie Teil der GyaanSetu AI-Lerncommunity für weitere Engineering-Analysen: t.me/GyaanSetuAi