Zurück zum Blog
Blog

Wie MCP-Server still und leise dein Claude-Token-Budget aufzehren – und wie du es verhinderst

Aug 7, 2026·7 min read·Jigar Mehta
#MCP#Claude Code#Token#Budget#Servers
Wie MCP-Server still und leise dein Claude-Token-Budget aufzehren – und wie du es verhinderst

Verbinden Sie fünf MCP-Server mit Claude Code, geben Sie nichts ein, und Sie haben bereits 50.000 Token verbraucht, bevor das Modell auch nur eine Zeile Ihres Prompts gelesen hat. Kein Fehler. Keine Warnung. Nur eine langsamere, teurere und unauffällig dümmere Sitzung, und die meisten Teams finden nie heraus, warum.

Wir verbringen viel Zeit mit Ingenieuren, die täglich mit Claude Code arbeiten, und dieses Kostenproblem überrascht fast jeden. Nicht, weil es obscur ist. Weil es von Natur aus unsichtbar ist. MCP-Server tun genau das, wofür sie gedacht sind. Niemand hat dir gesagt, was das kostet.

Was MCP tatsächlich in den Kontext lädt

Model Context Protocol (MCP) ist Anthropics offener Standard zum Verbinden von Claude mit externen Tools: GitHub, Slack, Datenbanken, interne APIs, was immer dein Stack braucht. Jeder Server, den du verbindest, registriert seine Tools, und jedes Tool bringt einen Namen, eine Beschreibung und ein Parameterschema mit. Das ist der Teil, den niemand zweimal liest, bevor er auf Verbinden klickt.

Hier kommt der wichtige Teil: Diese Definitionen werden in den Kontext geladen, und je nach Konfiguration kann dieses Laden bei jedem einzelnen Zug stattfinden, nicht nur einmal zu Beginn der Sitzung. Ein Server mit zwei sauberen Tools kostet fast nichts. Ein Server mit neunzig kostet echtes Geld und echte Aufmerksamkeit, unabhängig davon, ob du ihn in dieser Sitzung verwendest oder nicht.

Der Unterschied zwischen den Servern ist enorm. Ein minimaler SQLite-Server kann unter 500 Token laufen. Der vollständige GitHub-MCP-Server wurde dagegen unabhängig gemessen auf etwa 26.000 bis 55.000 Token nur für Tool-Definitionen, irgendwo zwischen 13 und 27 Prozent eines 200.000-Token-Kontextfensters, bevor du ihn überhaupt etwas tun lässt.

Die zwei verschiedenen Rechnungen, die du bezahlst

Es hilft, dies in zwei Kosten zu unterteilen, weil die Lösungen für jeden unterschiedlich sind.

  • Fixkosten: die Tool-Definitionen selbst. Jeder verbundene Server injiziert Namen, Beschreibungen und Schemata beim Sitzungsstart. Dies ist der Teil, der die Leute überrascht, weil er bezahlt wird, unabhängig davon, ob die Tools jemals verwendet werden.

  • Variable Kosten: die Ergebnisse. Jeder Tool-Aufruf gibt seine vollständige Ausgabe in den Kontext zurück, nicht eine Zusammenfassung. Eine Datenbankabfrage mit 10.000 Zeilen, eine ausgedehnte Protokolldatei, eine aufgeblasene JSON-Antwort – alles bleibt im Fenster für den Rest der Sitzung, und Claude liest das gesamte Gespräch bei jeder nachfolgenden Nachricht erneut. Nachricht 50 kostet mehr als Nachricht 5, rein wegen dem, was davor kam.

Verbinde drei oder vier Server, ohne die beiden Kosten zu bedenken, und es ist realistisch, dass du über die Hälfte deines Kontextfensters für Overhead verbrauchst, bevor die eigentliche Arbeit beginnt.

Warum dies nicht nur ein Kostenproblem ist

Token-Ausgaben sind die Beträge, die auf einer Rechnung erscheinen, also ist dies der Teil, den die Leute zuerst bemerken. Es ist nicht der schädlichste Teil.

Die Ausgabequalität verschlechtert sich, wenn zu viele Tool-Definitionen um die Aufmerksamkeit des Modells konkurrieren. Teams mit schwereren MCP-Setups haben berichtet, dass das Modell mitten in einer Aufgabe anfängt, irrelevante Tools zu verfolgen und selbstbewusst etwas wie das Erstellen eines GitHub-Issues als Lösung für ein Datenbank-Timeout vorschlägt. Mehr Tools geladen bedeutet nicht mehr Fähigkeit. Ab einem bestimmten Punkt bedeutet es, dass das Modell über eine verstopfte Oberfläche nachdenkt, statt über dein eigentliches Problem.

Für einen Gründer oder technischen Leiter stellt sich die Frage neu. Es geht nicht darum, „können wir uns die zusätzlichen Token leisten?" Es geht darum, „machen wir jede Sitzung unauffällig schlechter, indem wir acht MCP-Server verbunden lassen, die wir zweimal im Monat nutzen?"

Die Lösung, die Anthropic bereits geliefert hat, und die, die noch in deiner Hand liegen

Die gute Nachricht ist, dass sich das Protokoll selbst weiterentwickelt hat. Anthropic hat eine Tool-Suchfunktion ausgeliefert, die das Laden vollständiger Schemata aufschiebt, bis ein Tool tatsächlich benötigt wird, anstatt jede Definition auf einmal auszugeben. Frühe Ergebnisse zeigen, dass die Startup-Token-Kosten um etwa 83 Prozent sinken, wenn diese aktiv ist, und eine weit verbreitete Produktionsmessung ging von etwa 51.000 Token Overhead auf 8.500 nach ihrer Aktivierung zurück, eine Reduzierung von etwa 83 Prozent, ohne einen einzigen Prompt umzuschreiben.

Das ist die Infrastruktur-Lösung. Sie ist nicht überall standardmäßig aktiviert, und sie ersetzt gute Gewohnheiten nicht.

Vier Dinge, die sich diese Woche zu tun lohnen

  1. Führe /context aus. Sehe genau, wo deine Token hingehen, bevor du es errätst. Das dauert dreißig Sekunden und überrascht meist die Leute.

  2. Überprüfe deine verbundenen Server. Die meisten Entwickler haben drei oder vier MCP-Server geladen, die sie einmal pro Woche anfassen. Trenne sie. Verbinde sie wieder, wenn die Aufgabe sie wirklich braucht.

  3. Whitelist Tools; lade nicht ganze Server. Wenn du fünf Operationen von fünfzig auf einem Server nutzt, exponiere nur die fünf. Dies allein kann den Overhead eines Servers um etwa 80 bis 90 Prozent reduzieren.

  4. Vorverarbeitung, bevor es in den Kontext geht. Ein Hook, der eine 10.000-Zeilen-Datei nach dem Wort „error" durchsucht und nur Treffer zurückgibt. Dies verwandelt Zehntausende Token in ein paar hundert. Claude braucht nicht den Heuhaufen, nur die Nadel.

FAQ: MCP, Token-Kosten und der Aufbau eines Teams, das das richtig macht

F. Kostet das Verbinden eines MCP-Servers Token, auch wenn ich ihn in dieser Sitzung nie verwende?

Ja, in einer Standardkonfiguration. Die Tool-Definitionen werden beim Sitzungsstart geladen, unabhängig davon, ob du das Tool aufrufst. Aufgeschobenes Laden ändert dies, aber nur wo es aktiv konfiguriert ist.

F. Ist ein größeres Kontextfenster die Lösung für MCP-Overhead?

Nein. Ein größeres Fenster gibt dem Overhead nur mehr Platz zum Verstecken. Der Overhead ist immer noch ein echter Kostenfaktor, und die Verständlichkeit bei großen Kontextgrößen variiert zwischen Modellen erheblich, also führt ein vollgestopftes Fenster selten zu besserer Leistung als ein schlankes.

F. Wie können wir feststellen, ob ein Kandidat dies wirklich versteht, anstatt nur zu wissen, wie man einen Server verbindet?

Bitte ihn, einen Claude-Code-Kostenaudit, den er tatsächlich durchgeführt hat, vorzustellen und zu erklären, was er getrennt hat. Ingenieure, die ein aufgeblasenes Kontextfenster in Produktion getroffen haben, sprechen spezifisch darüber, was sie entfernt haben. Ingenieure, die es nicht getan haben, sprechen meist abstrakt über MCP.

F. Wo finden wir Ingenieure, die bereits mit dieser Disziplin arbeiten?

Dies ist eines der praktischen Signale, die wir bei der Überprüfung von Entwicklern für MyNextDeveloper-Kunden berücksichtigen, weil kostenbewusste Kontext-Engineering mehr darüber aussagt, wie jemand tatsächlich mit KI-Tools Tag für Tag arbeitet, als eine Resume-Zeile über „KI-Erfahrung" je sagen könnte.

Hauptaussagen

  • MCP-Server laden vollständige Tool-Schemata in den Kontext, manchmal bei jedem Zug, unabhängig davon, ob die Tools verwendet werden oder nicht.

  • Der GitHub-MCP-Server allein wurde auf zwischen etwa 26.000 und 55.000 Token Overhead vor deinem ersten Prompt gemessen.

  • Überladener Kontext kostet nicht nur Geld. Er verschlechtert die Ausgabequalität, manchmal sichtbar.

  • Aufgeschobenes Tool-Laden, Whitelisting und Preprocessing-Hooks sind die praktischen, verfügbaren Lösungen heute.

  • Führe /context aus, bevor du annimmst, zu wissen, wohin deine Token gehen. Die meisten Leute tun das nicht.

Warum es wichtig ist

MCP-Server sind wirklich nützlich, und keine davon ist ein Argument gegen ihre Verbindung. Es ist ein Argument gegen ihre Verbindung und dann Vergessen. Der Overhead ist messbar, die Lösungen sind verfügbar, und die Teams, die vorankommen, sind die, die Kontext wie ein Budget behandeln anstatt wie eine Nachgedanken.

Diese Art von Disziplin erscheint nicht auf einem Resume, aber sie zeigt sich schnell darin, wie jemand tatsächlich arbeitet. Es ist genau die Art von Urteilsvermögen, die wir bei MyNextDeveloper berücksichtigen, wenn wir Gründer mit Ingenieuren zusammenbringen, die bereits auf diese Weise arbeiten, nicht solche, die es noch auf deine Kosten lernen.

TL;DR

Jeder MCP-Server, der mit Claude Code verbunden ist, lädt sein vollständiges Tool-Schema in den Kontext, manchmal bei jedem Zug, unabhängig davon, ob du ihn verwendest oder nicht. Der GitHub-MCP-Server allein wurde auf etwa 26.000 bis 55.000 Token Overhead vor deinem ersten Prompt gemessen. Dies ist nicht nur ein Kostenproblem: Überladener Kontext verschlechtert auch die Ausgabequalität und verursacht manchmal, dass das Modell mitten in einer Aufgabe irrelevante Tools verfolgt. Anthropics aufgeschobene Tool-Loading-Funktion hilft, aber Tool-Whitelisting, das Trennen ungenutzter Server und die Vorverarbeitung lauter Tool-Ausgabe liegen noch in deiner Hand. Führe /context aus, bevor du annimmst, zu wissen, wohin deine Token wirklich gehen.

Möchtest du ein leistungsstarkes Remote-Tech-Team aufbauen?

Schau dir MyNextDeveloper an, eine Plattform, auf der du die besten 3% der Softwareingenieure findest, die sich tiefgreifend für Innovation begeistern. Unsere On-Demand-, Dedicated- und gründlichen Softwaretalent-Lösungen bieten eine umfassende Lösung für alle deine Softwareanforderungen.

Besuche unsere Website, um zu erkunden, wie wir dir helfen können, dein perfektes Team zusammenzustellen.