Die Context Tax: Was jedes verbundene Tool deinen Agenten kostet

Die Context Tax ist die fixe Token-Gebühr, die dein Agent für jedes verbundene Tool zahlt, bei jedem einzelnen Schritt, ob das Tool benutzt wird oder nicht. Verbinde einen MCP-Server, und seine Tool-Schemas (Namen, Beschreibungen, JSON-Parameter-Definitionen) laden in den Kontext des Modells, damit es weiß, was es aufrufen kann. Diese Ladung wiederholt sich jeden Schritt. Es ist eine Steuer im präzisen Sinn: vorab erhoben, immer erhoben, unabhängig von der Nutzung.

Der Begriff geistert 2026 durch die MCP-Welt, meist als Klage. Definieren wir ihn sauber, messen ihn und sortieren die Fixes.

Wie die Steuer mechanisch funktioniert

Ein Sprachmodell kann nur Tools aufrufen, die es sieht. Bevor dein Prompt gelesen wird, schickt der Client also die Definitionen jedes verfügbaren Tools mit. Ein gut dokumentiertes Tool mit ein paar Parametern landet zwischen 200 und 500 Tokens; 350 ist ein fairer Arbeitsmittelwert.

Niemand verbindet ein Tool. Ein typischer Server liefert 10 bis 30, und ein Arbeits-Setup verbindet mehrere Server. Da beißt die Multiplikation:

Und jetzt der Teil, der sie zur Steuer statt zur Gebühr macht: Agenten laufen in Schleifen. Eine 25-Schritte-Session mit 150 verbundenen Tools zahlt 52.500 Tokens Schema bei jedem dieser Schritte. Das sind über 1,3 Millionen Input-Tokens pro Session für Beschreibungen von Tools, von denen die meisten nie aufgerufen wurden. Die Aufgabe brauchte vielleicht acht davon.

Prompt-Caching rabattiert die Wiederholung, wo verfügbar, und du solltest es nutzen. Aber gecachte Schemas belegen weiter das Kontextfenster (52.500 Tokens sind ein Viertel eines 200k-Fensters, weg, bevor die Arbeit beginnt), und der Cache resettet, sobald sich die Tool-Liste ändert. Die Steuer wird billiger. Sie verschwindet nicht.

Die zweite Rechnung: schlechtere Auswahl

Die Token-Rechnung ist die sichtbare Hälfte. Die unsichtbare ist, was ein 150-Tool-Menü mit der Entscheidungsqualität macht. Jeder Server bringt sein eigenes search, sein eigenes list, sein eigenes get. Das Modell wählt jetzt aus einer Menge Fast-Duplikate, und falsche Tool-Aufrufe und Zöger-Schleifen steigen mit der Katalog-Größe. Jeder falsche Aufruf ist ein voller Schritt Kontext, bezahlt, plus ein Retry. Die Steuer verzinst sich selbst.

Miss deine eigene Steuer in fünf Minuten

Kein Benchmark nötig, nur dein eigenes Setup. Starte eine Session, stell eine triviale Anfrage und schau auf die Input-Token-Zahl dieses ersten Schritts. Zieh System-Prompt und deine Nachricht ab. Was bleibt, ist fast vollständig deine Context Tax. Dann stell die einzige Frage, die zählt: Wie verhält sie sich zu den Tokens, die deine eigentliche Arbeit verbraucht hat? Kostet die Speisekarte mehr als das Essen, bist du der Gast, von dem Restaurants träumen.

Die drei Fixes, sortiert

Fix 1: pro Projekt ausdünnen. Der billigste Fix und der unbefriedigendste: Verbinde nur die Server, die ein Projekt braucht, deaktiviere den Rest. Wirkt sofort, kostet Reichweite. Du wirst falsch vorhersagen, was die Aufgabe von morgen braucht, und diese Projektlisten für immer pflegen. Wo die praktische Decke liegt, steht in [Wie viele MCP-Server sind zu viele?](/de/blog/how-many-mcp-servers-is-too-many).

Fix 2: beschneiden, was lädt. Manche Clients lassen dich einzelne Tools deaktivieren; manche Server bieten schlanke Profile; geschwätzige Beschreibungen zu kürzen hilft am Rand. Echte Ersparnis, echtes Gefummel. Das breitere Taktik-Set steht in [MCP-Token-Verbrauch senken](/de/blog/reduce-mcp-token-usage).

Fix 3: hinter einem Gateway bündeln. Der strukturelle Fix. Ein [MCP Gateway](/de/blog/what-is-an-mcp-gateway) verschmilzt deine Server hinter einem Endpunkt, und damit entscheidet eine Stelle, wie der Katalog des Agenten aussieht. Statt dass jeder Server bei jedem Schritt sein volles Menü abkippt, können Tools bereitgestellt werden, wenn Aufgaben sie brauchen. Ein elfter Server heißt nicht mehr ein elfter permanenter Katalog im Kontext. Diesen Ansatz bauen wir bei Tulimoa (Gateway in früher Beta, noch nicht self-serve), und er paart sich mit der anderen strukturellen Ersparnis: einer Memory-Schicht, damit abgerufener Kontext neu geholten ersetzt. Dieser zweite Hebel ist ein eigenes Thema: [Woher deine LLM-Token-Rechnung wirklich kommt](/de/blog/where-your-llm-token-bill-comes-from) schlüsselt beide auf.

Die ehrliche Reihung: Mach Fix 1 heute, Fix 2, wo er leicht ist, und betrachte Fix 3 als den Weg, die Fixes 1 und 2 nie wieder von Hand zu machen.

Häufige Fragen

Was ist die Context Tax in einem Satz?

Die stehende Token-Gebühr für Tool-Definitionen, die jeder verbundene MCP-Server bei jedem Schritt in den Kontext deines Agenten lädt, unabhängig davon, ob diese Tools benutzt werden.

Gilt die Context Tax auch, wenn mein Agent gar keine Tools aufruft?

Ja. Schemas laden, damit das Modell seine Optionen kennt; die Ladung passiert vor jeder Aufruf-Entscheidung. Eine Session, die nie ein Tool anfasst, zahlt trotzdem die volle Steuer bei jedem Schritt.

Ist die Context Tax ein Argument gegen MCP?

Nein, sie ist ein Argument gegen naive MCP-Topologie. Das Protokoll ist überhaupt erst der Grund, warum Tools portabel sind. Die Steuer entsteht durch alles-überall-immer-verbinden, und sie hat Fixes, vom Ausdünnen pro Projekt bis zur Föderation am Gateway.