Neuer Messwert für die MCP-Token-Steuer: Zwei Tool-Beschreibungen waren für den Anstieg verantwortlich.
Neun MCP-Server wurden 13 Tage später erneut gemessen: Die Tool-Definitionen stiegen von 36.320 auf 38.738 Tokens an, wobei dies fast ausschließlich dadurch geschah, dass ein Server seine Beschreibungen neu schrieb.
Quellen: We Re-Ran the Same 9 MCP Servers 13 Days Later. They Cost You 2,418 More Tokens.
Zwischen dem 9. und 22. September 2026 stiegen die kombinierten Tool-Definitionen von neun beliebten MCP-Servern von 36.320 auf 38.738 Tokens an. Das entspricht einem Anstieg von 2.418, also 6,7 Prozent, wovon allein ein Server 2.094 Tokens beitrug. Die Anzahl der Tools blieb nahezu unverändert und stieg von 108 auf 109. Zunehmen hingegen tat die Länge der Beschreibungen der bereits vorhandenen Tools.
Die wichtigsten Zahlen
Eine erneute Messung mit dem identischen Skript, durchgeführt dreizehn Tage nach der ersten Messung, ergab folgende Ergebnisse:
- Der Tool-Block aller neun Server stieg um 2.418 Tokens an, was einem Anstieg von 6,7 Prozent entspricht.
- firecrawl-mcp wechselte von Version 3.24.0 auf 3.25.2 und behielt genau 27 Tools bei, trug jedoch weiterhin 2.094 Tokens bei.
Warum diese Frage jetzt wichtig ist
In letzter Zeit gab es laute Kritiken am MCP, wobei ein zentrales Problem darin besteht, dass Server den Kontext, den ein Agent mit sich trägt, stillschweigend vergrößern. Es existierte bereits eine Basisdatenlage vom 9. September, die neun Server, 108 Tools sowie 36.320 Tokens umfasste, sodass derselbe Test am 22. September wiederholt werden konnte. Der aktuelle Bedarf beträgt nun 38.738 Tokens, wobei der größte Anstieg von einem Server ausgeht, dessen Anzahl an Tools unverändert blieb, da seine bestehenden Beschreibungen länger wurden. Das ist die Behauptung der Kritiker, gestützt auf Zahlen und eine veröffentlichte Methode.
Was die Token-Steuer ist
Die Token-Steuer ist der vom Kontextbudget verbrauchte Teil durch die Tool-Definitionen, bevor der Benutzer etwas eingibt. Jeder verbundene Server beantwortet einen Aufruf von tools/list, und diese Antwort wird in den Modell-Auftrag geschrieben. Bei den neun am häufigsten genutzten Servern betrug die Gesamtzahl am 22. September 2026 38.738 Token, im Vergleich zu 36.320 Token am 9. September. Bei einem Zeitfenster von 200.000 Token sind bereits vor der ersten Nachricht etwa 19 % verbraucht – ein Wert, den ein Entwickler leicht erreichen könnte, indem er bestimmte Tools installiert.
Snapshot vom 22. September 2026 um 18:29 UTC: 9 Server, 109 Tools und 38.738 Token. Um dieses Ergebnis nachzuvollziehen, sollte man jede npm-Paket-Spezifikation überprüfen und anschließend die strengen Angaben zu Name, Beschreibung sowie InputSchema mithilfe des o200k_base-Tokenizers zählen.
Wie die Messung funktioniert
Jeder Server wurde über stdio mittels npx gestartet. Dabei wird zunächst „initialize“ gesendet, anschließend „tools/list“, und die rohe Antwort wird gespeichert. Von jedem Tool werden nur die drei Felder aufbewahrt, die tatsächlich von der API für die Tool-Nutzung empfangen werden: Name, Beschreibung und inputSchema. Das Objekt wird mit sortierten Schlüsseln kanonisiert, die Tools werden nach Name sortiert, und das serialisierte Ergebnis wird mit o200k_base gezählt. Der frühere Ablauf am 9. September verwendete diese gleiche strenge Definition, und jeder Server wurde in seiner neuesten veröffentlichten Version vom 22. September 2026 getestet.
Der laufende Server wird überprüft, anstatt sein Quellcode gelesen zu werden, und der Unterschied ist tatsächlich vorhanden. Mehrere Server erstellen ihre Tool-Liste zur Laufzeit, verbergen Tools hinter einem Flag oder erstellen eine Beschreibung aus einem Template. Die Liste, die ein Modell erhält, kann daher von der im Repository enthaltenen abweichen, und ein Lesen des Quellcodes würde eine glaubwürdige Zahl liefern, die kein Modell jemals zu sehen bekommt. Die Überprüfung hat ihre eigenen Einschränkungen: Ein Server, der Anmeldeinformationen benötigt, kann einem nicht authentifizierten Client eine kürzere Liste anzeigen als einem angemeldeten Benutzer. Alle neun zeigten dieses Mal eine vollständige Liste an, doch die Methode kann das im Allgemeinen nicht ausschließen.
Warum ein dreizehntägiger Unterschied glaubwürdig ist
Fünf Server veröffentlichten in diesem Zeitraum nichts, wodurch sie als eingebaute Kontrollmechanismen dienen. Es handelte sich um die Server-Dateisysteme, den Server-Speicher, den exa-mcp-Server, den tavily-mcp sowie den Server für sequenzielles Denken; sie kehrten jeweils genau zu ihren Ausgangswerten zurück: 1.668, 907, 415, 1.666 bzw. 867 Tokens. Keine Abweichung, genau die ursprünglichen Werte. Ein schwankender Sensor oder Tokenisierer hätte alle fünf Werte verändert, sodass der gesamte Anstieg von 2.418 auf die vier freigesetzten Server zurückzuführen ist.
Der verantwortliche Server
firecrawl-mcp, mit drei Veröffentlichungen vom 12. August bis zum 22. September, ist die Quelle für 2.094 hinzugefügte Tokens. @playwright/mcp trug durch zwei Veröffentlichungen sowie ein neues Tool 324 Tokens bei. Zwei weitere Server wurden veröffentlicht, @upstash/context7-mcp (zwei Veröffentlichungen) und @notionhq/notion-mcp-server (eine), und ihre Tool-Blöcke blieben in ihrer Größe genau gleich. Code zu veröffentlichen und zu ändern, was über das Netzwerk übertragen wird, sind nicht dasselbe – letzteres geschieht nur gelegentlich.
Fähiger oder nur aufwändiger?
Im Wesentlichen nur schwerer – ein Aspekt, der in weiten Teilen der Debatte fehlt. firecrawl-mcp hatte vorher 27 Tools und danach ebenfalls 27. Es wurden zwei Tools durch zwei andere ersetzt, was zu einem Rückgang von 131 Tokens führte. Die zusätzlichen 2.225 Tokens stammten davon, dass bereits vorhandene Tools längere Beschreibungen sowie größere Eingabeschemata für dieselben Funktionen erhielten. Die Nutzer zahlten somit 2.225 Tokens mehr für genau die gleichen fünfundzwanzig Funktionen, die sie bereits besaßen.
Die beiden größten Veränderungen erfordern genaue Zahlen: firecrawl_scrape gewann 721 Beschreibungs-Token und 462 Schema-Token. firecrawl_search gewann 691 bzw. 234 Token. Insgesamt entspricht das 2.108 der 2.225 Token. Sieben weitere verbleibende Tools wechselten insgesamt nur um 117 Token, und sechzehn änderten sich überhaupt nicht. Es handelt sich also nicht um ein allmählich verbessertes Ökosystem, sondern um zwei ausführlich überarbeitete Tool-Definitionen.
Ob dies als Verschwendung gilt, hängt von etwas ab, das nicht gemessen wurde. Eine längere Beschreibung ist oft eine legitime Reparatur: Ein Werkzeug, das das Modell weiterhin falsch verwendet, wird geklärt, und die Tokens sichern die Zuverlässigkeit. Dennoch entspricht 4.458 Zeichen in etwa der Länge eines vollständigen Prosaabschnitts, der einer Funktion zugeordnet ist und mit jeder Anfrage übertragen wird. Die Kostenseite wurde ordnungsgemäß gemessen. Die Vorteilsseite bleibt unbekannt.
Wohin die Tokens tatsächlich gehen
Das Muster ist Konzentration und nicht Breite. Nach Anteil am Gesamtbestand von 38.738:
- Der Notion-Server führt mit einem großen Vorsprung mit 17.409 Tokens, 44,9 % des Gesamts, verteilt auf 24 Werkzeuge.
- Firecrawl ist mit 27 Werkzeugen und 11.088 Tokens (28,6 %) auf dem zweiten Platz.
- Playwright folgt mit 3.734 Tokens, 9,6 %, für 25 Werkzeuge.
- Der Referenz-Dateisystem-Server verwendet 1.668 Token (4,3 %) für 14 Tools, während Tavily 1.666 Token (ebenfalls 4,3 %) für nur 5 Tools benötigt.
- Context7 verbraucht 984 Token (2,5 %) für 2 Tools, der Memory-Server 907 Token (2,3 %) für 9 Tools und sequential-thinking 867 Token (2,2 %) für ein einziges Tool.
- Exa ist am leichtesten, mit 415 Token oder 1,1 % bei 2 Tools.
Die Anzahl der Tools sagt nur ungenau etwas über die Kosten aus. @playwright/mcp bietet 25 Tools für 3.734 Token, während notion-mcp-server 24 Tools für 17.409 Token bereitstellt. Die Anzahl der Tools ist fast gleich, doch die Rechnung ist 4,7 Mal höher.
Für alle, die mehr als zwei oder drei Server betreiben, ist die wichtige Frage, welche davon die Notion-ähnlichen sind.
Ist die Kritik richtig?
Was diese Behauptung in diesem Beispiel und in diesem Kontext angeht, so stimmt sie zwar, doch der Mechanismus ist enger gefasst, als die Debatte üblicherweise nahelegt. Die Kosten steigen – und zwar ohne neue Funktionalitäten – und konzentrieren sich auf eine Handvoll Server, anstatt im gesamten Ökosystem verteilt zu sein. Die gängige Kritik, dass MCP als Protokoll an sich überdimensioniert sei, wird von den Daten nicht bestätigt. Stattdessen zeigen die Daten, dass der Großteil der Kosten auf die Dokumentation zweier Anbieter entfällt.
Beschränkungen der Belege
- Es zeigt sich kein Trend. Zwei Werte, die dreizehn Tage auseinanderliegen, bilden lediglich einen Unterschied, keine Entwicklungslinie – und einer der beiden Werte wird durch die Veröffentlichung eines einzigen Anbieters dominiert. Ein ruhiger Monat würde zu einem konstanten oder negativen Wert führen, ohne dass das Problem dadurch beseitigt würde.
- Die Stichprobe repräsentiert MCP nicht als Ganzes. Diese neun Server wurden in einer früheren Runde ausgewählt, weil sie weit verbreitet installiert sind und ohne Anmeldeinformationen überprüft werden können. Es existieren Tausende von Servern, und niemand besitzt eine zuverlässige Liste davon.
- Echte Agenten werden nicht modelliert. Niemand verbindet sich genau mit diesen neun Servern, sodass 38.738 eine für das Experiment definierte Konfiguration beschreibt und nicht eine Rechnung, die jemand bezahlen muss. Der wiederverwendbare Teil ist die Methode, die auf jeder persönlichen Servergruppe ausgeführt werden kann.
- Der Wert ist nicht messbar. Die Beschreibung von firecrawl_scrape hat sich in der Länge vervierfacht, doch ob das Modell sie nun häufiger korrekt aufruft, erfordert ein Evaluationswerkzeug – was ein separates Experiment darstellt.
Prüfung des ersten Entwurfs der Zahl
Der erste Versuch nutzte eine naive Serialisierung, bei der das gesamte Tool-Objekt so zurückgegeben wurde. Für das Korpus vom 9. September ergab dies 40.480 Token, im Vergleich zu den bereits veröffentlichten 36.320 Token. Der Unterschied lag nicht an einer Änderung auf den Servern, sondern an zusätzlichen Feldern, die die veröffentlichte Methode absichtlich weglässt.
Durch Wiederholung des Vorgangs mit der archivierten, strengen Definition erhielt man 108 Tools sowie 36.320 Token pro Einheit, was zu dem oben genannten Vergleich führte. Der Vergleich zweier unterschiedlicher Methoden ergibt ein Artefakt und keine echte Messung; in diesem Fall hätte das Artefakt die Veränderung um 6,5 Prozent in eine auffälligere Richtung aufgebläht.
Dieselbe Vorsicht gilt auch für frühere Arbeiten zum Thema. Ein früherer Bericht gab 38.900 Tokens für neun MCP-Server an, doch diese Zahl stammte von einem anderen Durchlauf, dessen Methode nicht erneut überprüft wurde, weshalb sie hier nicht als Grundwert herangezogen werden kann. Der Wert 38.738 stellt keinen Rückgang gegenüber 38.900 dar. Das einzige Paar, das ehrlich subtrahiert werden kann, sind 36.320 und 38.738, da ein und derselbe Script beide Werte erzeugt hat.
Häufige Fragen
Was zählt als Token-Steuer? Alles, was der Client dem Modell vor Beginn jeder Konversation über Tools mitteilt: In der Praxis werden die Tools/Listenantworten jedes Servers auf Name, Beschreibung und Eingabeschema gekürzt. Jeder Anfrage in einer Sitzung liegt dies bei, es sei denn, der Client speichert das Präfix im Cache – und es wird auch dann berechnet, wenn kein Tool aufgerufen wird.
Macht das Caching von Prompts es kostenlos? Billiger, aber nicht kostenlos – und nur solange sich das Präfix nicht ändert. Bei 96 Veröffentlichungen auf diesen neun Servern haben 48 % der Versionswechsel den Tool-Block verändert, der ein gekachtes Präfix öffnet. Häufige Veröffentlichungen bedeuten häufige Cache-Invalidierung.
Warum ist notion-mcp-server so teuer? Seine 24 Tools enthalten Eingabeschemata, die eine große API-Oberfläche beschreiben, und der Tool-Block wurde seit Juli unverändert gelassen. Es gibt keinen Wachstumsschub. Er war von Anfang an hoch und blieb es – das ist ein anderes Problem als billige, aber stark genutzte Server und erfordert eine andere Lösung.
Können ungenutzte Tools deaktiviert werden? Einige Kunden ermöglichen das Filtern der Tools eines Servers, und angesichts dieser Zahlen ist das die effektivste Option, denn das Entfernen der beiden teuersten Server würde den Stack um 73,5 % verkleinern. Die Kundensupport-Leistungen variieren, daher ist es klug, dies vor dem Installieren eines weiteren Servers zu überprüfen.
Zählt 6,7 % in weniger als zwei Wochen als viel? Wenn man das auf ein Jahr hochrechnet, klingt das beunruhigend, doch die Prognose auf Basis von nur zwei Datenpunkten ist irreführend. Es handelte sich dabei um einen Zeitraum von zwei Wochen, in dem eine einzige Version eines Anbieters 2.094 zusätzliche Tokens in einen Neun-Server-Stack einführte, ohne neue Funktionen zu bieten.
Eine Überprüfung, die man heute durchführen sollte
Öffnen Sie die MCP-Konfiguration des Agents, zählen Sie die Server und finden Sie den größten. Sind die Beschreibungen seiner Tools beim letzten Update länger geworden, und wäre diese Veränderung bemerkt worden? Es bleibt auch eine offene Frage: Wie viele Tokens sendet ein Client tatsächlich, wenn er behauptet, die Tools eines Servers filtern zu wollen – eine Zahl, die hier nur angenommen, aber nie überprüft wird.