Du hast ein Dutzend MCP-Server an deinen AI-Agent gehängt. GitHub, Slack, Linear, Postgres, S3, Websuche — das volle Büffet. Dein Agent kann theoretisch deinen gesamten Stack anfassen. Du fühlst dich mächtig. Der Agent nicht.

Er hat angefangen, Tasks zu vermasseln, die er vorher im Schlaf konnte. Falsches Tool gewählt. Parameter halluziniert, die gar nicht existieren. Kontext vergessen, den du gerade eben eingetippt hast. Du hast nichts kaputt gemacht — du hast ihm nur zu viele Speisekarten zum Lesen gegeben, bevor er überhaupt anfangen konnte zu kochen.

Die Mathematik, vor der dich keiner gewarnt hat

Am 14. April veröffentlichte Cloudflare eine Enterprise MCP Reference Architecture, die dem Problem echte Zahlen verpasste. MCP (Model Context Protocol) ist ein universeller Steckstandard für AI-Tools — wie USB, nur für die Verbindung von Agents mit externen Services. Jedes MCP-Tool liefert ein Schema, das dem Modell sagt, was es tut und welche Parameter es braucht. Bei jedem einzelnen Turn liest das Modell alle davon.

Wie wir gestern in Tool-Calling Is Dead aufgeschlüsselt haben, verbrannte allein Cloudflares eigenes Portal ~9.400 Tokens nur für Tool-Beschreibungen — bevor der Agent dein eigentliches Problem auch nur angefasst hat. GitHubs MCP-Server (94 Tools) fraß ~42.000 Tokens. Die Zahlen lohnen sich nur deshalb zu wiederholen, weil sich zwischendurch nichts geändert hat. Die Leute haben einfach weiter Server angestöpselt.

Ein Benchmark vom 6. März hatte den Genauigkeitskollaps bereits dokumentiert: Die Tool-Auswahl fiel von ~95% mit 4 fokussierten Tools auf ~71% mit 46 Tools. Sechs Wochen später bestätigte Cloudflare dasselbe Problem im Enterprise-Maßstab. Das Protokoll hat sich nicht geändert. Die Anzahl der Server schon.

Alle fixen es, keiner ist sich einig wie

Cloudflare lieferte am 16. April Code Mode — das Tool-Telefonbuch wird gekillt und durch eine typisierte API ersetzt. Zwei Einstiegspunkte statt 2.500+. Token-Verbrauch um 99,9% gesunken. Brillant. Und ausschließlich auf Cloudflare Workers lauffähig. Sie haben das Open-Standard-Problem mit einer proprietären Lösung gelöst. Klassiker.

Atlassian ging den Komprimierungsweg. Ihr Open-Source-Tool mcp-compressor, veröffentlicht am 29. März, quetscht GitHubs 94 MCP-Tools von 17.600 Tokens auf 500 bei maximaler Komprimierung (97% Reduktion). Stell dir vor, du minifizierst deine API-Docs, bis selbst du sie nicht mehr lesen kannst. Das Modell kann es irgendwie trotzdem — aber der Tradeoff ist real. Atlassians eigene Benchmarks zeigen, dass maximale Komprimierung die Parameter-Constraint-Treue verschlechtert: Komplexe Tools mit verschachtelten Objekt-Schemata verlieren die Validierungshinweise, die Modelle für korrekte Aufrufe brauchen. Ihre Docs empfehlen mittlere Komprimierung (80% Reduktion, ~3.500 Tokens) für Produktion und reservieren das Maximum für "Exploration only". Die ehrliche Version: Du tauschst Genauigkeit gegen Spielraum und hoffst, dass das Modell die Lücken selbst füllt.

Anthropic ging einen komplett anderen Weg. Am 8. April launchten sie Managed Agents für 0,08$/Stunde — spezialisierte Sub-Agents mit schlanken 5–10 Tool-Kits statt eines Generalisten, der in 50 Tools ertrinkt. Jeder Sub-Agent lädt pro Turn nur seine eigenen Tools, was den Overhead pro Agent um rund 85% reduziert. Die Lösung für zu viele Tools? Mehr Agents mit weniger Tools. Rekursion as a Service.

Und dann gibt es die Teams, die Optimierung komplett übersprungen und einfach angefangen haben, Dinge zu löschen. Am 12. März teilte GitHub Copilots Engineering-Team Ergebnisse vom Kürzen ihrer Tool-Anzahl von 40 auf 13 — 2–5 Punkte Benchmark-Verbesserung, 400ms weniger Latenz. Im Februar baute Block seinen Linear-MCP-Server dreimal um und schrumpfte von 30+ Tools auf 2. Am 3. April destillierte Phil Schmid (Hugging Face) das Pattern zu einer einzigen Regel: "Kuratiere gnadenlos. 5 bis 15 Tools pro Server. Ein Server, ein Job." Kein Komprimierungsalgorithmus. Keine Discovery-Schicht. Einfach nur Disziplin.

Das eigentliche Problem ist das Protokoll

Was keine dieser Lösungen fixt: Jede einzelne ist proprietär, plattformspezifisch oder ein Workaround für ein Loch in MCP selbst.

Cloudflare Code Mode läuft auf Workers. Managed Agents laufen mit Claude. Atlassians Compressor ist die portabelste Option — und trotzdem nur Gaffa-Tape auf einem Protokoll, das ohne Inhaltsverzeichnis ausgeliefert wurde.

Anthropic hat MCP als den universellen Standard angepriesen. Der eine Connector, sie alle zu beherrschen. Stattdessen bauen wir vendor-spezifische Discovery-Layer auf den universellen Standard drauf, damit er im großen Maßstab überhaupt funktioniert.

Wir haben genau diesen Film schon gesehen. CORBA in den 90ern — ein "universelles" Objekt-Protokoll, das eine ganze Industrie von herstellerspezifischen Bridges hervorgebracht hat, nur damit es benutzbar wurde. Das Interface Repository versprach dynamische Discovery; in der Praxis lieferte jeder ORB-Hersteller sein eigenes. SOAP in den 2000ern — der Enterprise-"Standard", den jeder still und leise mit REST umschifft hat, weil WSDL-Dateien zu unlesbaren Monstren angewachsen waren. JavaScript-Module — AMD, CommonJS, UMD, ein volles Jahrzehnt Fragmentierung, bevor ES Modules kamen. Das Muster ändert sich nie: Offener Standard kommt unfertig raus, Anbieter füllen die Lücken mit proprietären Schichten, das Ökosystem fragmentiert, bis jemand den Standard repariert oder ihn begräbt.

MCP ist in der Vendor-Gap-Filling-Phase. Cloudflare, Anthropic, Atlassian und ein Dutzend kleinerer Player — jeder baut seine eigene Antwort auf dasselbe fehlende Feature: dynamische Tool-Discovery. Das Protokoll muss das nativ können. Tut es aber nicht. Also bekommen wir sechs konkurrierende Lösungen und nennen das ein Ökosystem.

Die optimistische Lesart: Wettbewerb treibt Innovation, der beste Ansatz gewinnt, der Standard absorbiert ihn. Die realistische Lesart — auf die ich wetten würde — ist, dass die großen Modellanbieter ihre bevorzugte Discovery in die Standard-Agent-Frameworks einbacken, und "universell" leise anfängt zu bedeuten "funktioniert mit Claude" oder "funktioniert mit GPT", aber nicht beides. USB-C mit herstellerspezifischen Ladeprotokollen, von vorne. Und das in der EU, wo wir gerade erst gedacht haben, wir hätten das gelöst.

Was du heute konkret tun kannst

Prüfe deine MCP-Verbindungen. Entferne Server, die dein Agent seit einer Woche nicht aufgerufen hat. Gruppiere die verbleibenden Tools nach Aufgabenbereich. Miss den Token-Verbrauch vorher und nachher — du wirst überrascht sein, wie viel Spielraum du zurückgewinnst.

MCP braucht nicht mehr Server. Es braucht einen Package-Manager-Moment — dynamische Discovery und Lazy Loading, das Tools wie Imports behandelt, nicht wie globale Variablen, die in jeden Prompt gestopft werden. Bis dahin gilt: Weniger ist buchstäblich mehr. Und die Agents, die am besten performen, werden nicht die mit den meisten Tools sein — sondern die, die gelernt haben, Nein zu sagen.