MCP hat ein echtes Problem gelöst: Wie bekommt ein AI-Agent Zugriff auf externe Tools? Aber es hat ein neues geschaffen. Denn mehr Tools bedeutet nicht mehr Fähigkeit. Ab einem bestimmten Punkt bedeutet es weniger.
Das Problem in Zahlen
Ein einzelner MCP-Server mit 135 Tools verbraucht rund 126.000 Tokens — allein für die Tool-Beschreibungen, bevor der Agent irgendetwas tut. Bei einem Context Window von 200K bleiben danach nicht mal 40% für die eigentliche Arbeit.
Das wäre akzeptabel, wenn die Agents mit mehr Tools bessere Ergebnisse liefern würden. Tun sie aber nicht. Redis hat das gemessen: Bei 50+ verfügbaren Tools lag die Auswahlgenauigkeit bei 42%. Gefiltert auf die 3-5 relevanten Tools sprang sie auf 85%. Token-Verbrauch runter von 23.000 auf 400. Latenz von 3,4 Sekunden auf 0,4.
Und das ist kein Einzelfall. Chroma Research hat 18 LLMs getestet und bei allen dasselbe Muster gefunden: Je mehr Context, desto schlechter die Ergebnisse. Ein vollgepacktes Context Window mit ~113K Tokens drückt die Accuracy um rund 30% gegenüber einer fokussierten Variante mit 300 Tokens. Das Modell wird nicht klüger, wenn du ihm mehr gibst. Es wird abgelenkter.
Was MCP nicht löst
MCP definiert, wie Tools bereitgestellt und aufgerufen werden. Das ist eine Infrastruktur-Schicht, vergleichbar mit einer REST-API-Spezifikation. Aber MCP kennt keine Workflows. Es weiß nicht, dass Tool B erst nach Tool A aufgerufen werden sollte. Es kennt keine Abhängigkeiten, keine Reihenfolgen, keine Fallback-Strategien.
Stell dir ein typisches API-Management-Szenario vor. Du hast einen MCP-Server, der eine API-Management-Plattform wie Gravitee anbindet. Jede API-Operation wird zu einem MCP-Tool. Bei einer Plattform mit 80+ Endpunkten sind das 80+ Tool-Beschreibungen im Context. Der Agent sieht: createApi, updateApi, deployApi, createPlan, publishPlan, createApplication, subscribeApplication und 73 weitere. Alles flach, alles gleichwertig.
Wenn ein Entwickler jetzt sagt “Erstell mir eine neue API mit Rate-Limiting”, muss der Agent aus 80 Tools die richtige Sequenz zusammenbauen: API anlegen, Plan erstellen, Plan publizieren, API deployen. In dieser Reihenfolge. Ohne Orchestrierung rät er. Und rät meistens falsch, weil 80 gleichwertige Tool-Beschreibungen keine Sequenz kommunizieren.
Das Pattern: Progressive Disclosure
Mehrere Tools sind unabhängig voneinander auf dieselbe Lösung gekommen.
Claude Code hat ein Skills-System eingeführt. Skills laden nur ihre Metadaten (~30-50 Tokens), der Rest kommt erst bei Bedarf. Statt alle Tools permanent im Context zu halten, werden sie nach Intent gefiltert.
Cursor ist von monolithischen .cursorrules auf modulare .mdc-Dateien migriert. Regeln werden per Glob-Pattern nur geladen, wenn sie zum aktuellen File passen. Wer an app/models/ arbeitet, bekommt die Datenbank-Konventionen. Wer im Frontend ist, nicht.
GitHub Copilot nutzt pfadspezifische .instructions.md-Dateien mit YAML-Frontmatter. Eine applyTo-Property steuert, welche Instructions für welche Verzeichnisse gelten.
Das Muster ist immer dasselbe: Nicht alles laden, sondern das Richtige zur richtigen Zeit. Der Agent bekommt zuerst nur eine kompakte Übersicht (welche Skills gibt es?), erkennt den Intent der Anfrage und lädt dann gezielt den passenden Skill — inklusive der nötigen Workflow-Schritte und Referenzdaten.
Zurück zum API-Management-Beispiel: Statt 80 Tool-Beschreibungen permanent im Context zu haben, definiert ein Skill “API-Management” eine Routing-Tabelle. “Erstell eine API” matcht auf einen Workflow, der die 4-5 relevanten Tools in der richtigen Reihenfolge beschreibt und die nötigen Referenzdaten (Ziel-Umgebung, Naming-Konventionen, Default-Rate-Limits) mitliefert. Der Context schrumpft von ~80.000 Tokens auf ~5.000. Der Agent weiß, was er tun soll.
Warum das jetzt relevant wird
Context Windows werden größer. Gemini und Claude bieten mittlerweile 1M Tokens. Man könnte meinen, das Problem löst sich von selbst. Tut es nicht. Die Chroma-Studie zeigt: Mehr Context hilft nur, wenn er relevant ist. Irrelevanter Context schadet aktiv, egal wie groß das Window ist. Oder wie Anthropic es formuliert: Context ist eine endliche Ressource mit abnehmenden Erträgen.
Jenova AI setzt die praktische Grenze bei 5-7 Tools pro Interaktion. Darüber steigen Auswahlfehler exponentiell.
Dazu kommt ein zweiter Trend: Agentische Architekturen setzen zunehmend auf spezialisierte Agents für einzelne Aufgaben statt auf einen General-Purpose-Agent, der alles kann. Und spezialisierte Agents laufen oft auf kleineren, schnelleren Modellen, die keine 1M-Token-Fenster mitbringen. Ein Agent auf Haiku oder einem vergleichbar schlanken Modell hat vielleicht 32K-128K Context. Da zählt jeder Token, den Tool-Beschreibungen verbrauchen.
Was das für die Praxis heißt
Wer AI-Agents baut oder MCP-Server betreibt, sollte genauso viel über Tool-Routing nachdenken wie über Tool-Verfügbarkeit. Ein MCP-Server, der 100 Tools anbietet, ist kein Feature. Er ist ein Performance-Problem, das darauf wartet, aufzufallen.
Die Faustregel: Wenn dein Agent bei einer Anfrage mehr als 10 Tools sieht, brauchst du eine Orchestrierungs-Schicht. Nicht weil MCP schlecht ist — MCP ist die richtige Infrastruktur. Aber Infrastruktur allein reicht nicht. Du brauchst Intelligenz darüber.