arXiv:2604.21816: 'Tool Attention Is All You Need' eliminiert MCP Tax — 95 % Token-Reduktion pro Runde im agentischen Workflow

Die Forscher Anuj Sadani und Deepak Kumar veröffentlichten am 23. April 2026 auf ArXiv eine Arbeit mit dem Titel „Tool Attention Is All You Need” (arXiv:2604.21816), in der sie ein ernstes strukturelles Problem des Model Context Protocol (MCP) identifizieren und lösen — die sogenannte MCP Tax. Dabei handelt es sich um versteckte Kosten von 10 bis 60 Tausend Token pro Runde, die in typischen Multi-Server-MCP-Deployments schlicht für das Einfügen von Tool-Schemata in jeden Modellaufruf „verbraucht” werden.

Die Arbeit erscheint zu einem Zeitpunkt explosionsartiger MCP-Integration in Enterprise-Umgebungen, in denen ein einzelnes agentisches System oft über Dutzende von Tools auf mehreren Servern gleichzeitig verfügt. Solche Konfigurationen hatten bisher versteckte Kosten, die sowohl Geschwindigkeit als auch Reasoning-Qualität sabotierten.

Was genau ist MCP Tax?

Die Autoren identifizieren das Problem als Eager Schema Injection — das Standard-MCP-Muster, bei dem die vollständige JSON-Schema-Beschreibung jedes registrierten Tools bei jedem Modellaufruf in den Kontext eingefügt wird, auch wenn das Modell 95 % davon nicht verwenden wird. Der Token-Overhead liegt zwischen 10.000 und 60.000 Token pro Runde, abhängig von der Anzahl der Server und der Komplexität der Schemata.

Die Folgen sind zweifach: Erstens bläht sich der KV-Cache auf, und die Inferenz wird langsamer und teurer. Zweitens fällt die Reasoning-Qualität signifikant ab, wenn die Kontextnutzung den kritischen Schwellwert von etwa 70 % überschreitet — gut dokumentiert in der Literatur zum „Context Rot”-Phänomen.

Wie löst Tool Attention das Problem?

Der vorgeschlagene Ansatz ist eine Middleware-Schicht, die zwischen Agent und MCP-Servern sitzt und drei komplementäre Komponenten kombiniert:

1. Intent Schema Overlap (ISO) Score — nutzt Sentence-Embedding-Modelle, um die semantische Ähnlichkeit zwischen der Nutzeranfrage und der Beschreibung jedes Tools zu messen, und rankt Tools nach Relevanz.
2. State-Aware Gating Function — prüft Vorbedingungen und Zugriffsrechte, bevor ein Tool in den Kontext eingefügt wird, sodass Tools, die Authentifizierung oder einen bestimmten Zustand erfordern, gar nicht erscheinen, bis diese Bedingungen erfüllt sind.
3. Two-Phase Lazy Schema Loader — hält im Kontext nur einen kompakten Summary-Pool aller verfügbaren Tools; vollständige JSON-Schema-Beschreibungen werden erst für die Top-k-Tools mit dem höchsten ISO-Score geladen.

Dieser Ansatz entspricht dem Verhalten eines erfahrenen Entwicklers, der nur eine mentale Liste von „was ich tun kann” führt und die API-Details erst liest, wenn er weiß, dass er das Tool aufrufen wird.

Wie viel wird in der Praxis eingespart?

Die Autoren führten eine Evaluierung in einer simulierten Umgebung mit 120 Tools, verteilt auf sechs MCP-Server, durch, kalibriert nach realen Produktions-Deployments. Die Ergebnisse sind dramatisch: Der Token-Verbrauch pro Runde sank von 47.300 auf 2.400 Token, was einer Reduktion von 95 % entspricht. Die Kontextnutzung stieg von 24 auf 91 %, sodass der Agent nun komplexere Gesprächshistorien verarbeiten kann, ohne an Reasoning-Qualität zu verlieren.

Die Autoren betonen ausdrücklich, dass die projizierten Metriken aus gemessenen Token-Zahlen in Kombination mit veröffentlichter Telemetrie abgeleitet wurden, nicht aus Live-LLM-Agent-Tests. Das ist eine wichtige Einschränkung — die tatsächliche Reduktion in der Produktion hängt von der Qualität des Embedding-Modells für den ISO-Score und der Realitätsnähe der Kalibrierung ab.

Was bedeutet das für Multi-Agenten-Systeme?

Die zentrale Schlussfolgerung der Arbeit ist, dass „Effizienz auf Protokollebene, nicht die rohe Kontextlänge, die bindende Einschränkung” skalierbarer agentischer Systeme ist. Mit anderen Worten: Modelle mit einem Millionen-Token-Kontext lösen das Problem nicht, wenn 60.000 Token pro Runde verschwendet werden.

Für Teams, die Multi-Agenten-Systeme auf Claude, GPT oder Open-Source-Modellen aufbauen, schlägt diese Arbeit konkrete architektonische Änderungen vor: Einführung einer Middleware-Schicht mit Lazy-Schema-Loading, Implementierung von KV-Cache-Sharing zwischen aufeinanderfolgenden Aufrufen desselben Agenten und Messung der tatsächlichen Kontextnutzung als primäre Metrik, statt sich auf die Kontextfenstergröße zu konzentrieren. Der Code ist auf GitHub im in der Arbeit referenzierten Repository verfügbar.