Du hast deinen KI-Agenten — ein Programm, das eigenständig handelt und externe Tools aufruft, um Aufgaben zu erledigen — an ein Dutzend MCP-Server (Model Context Protocol — ein universeller Anschlussstandard für KI-Tools, wie USB, aber für Daten) angeschlossen. Getestet. Demo lief super. Ab in die Produktion, wo echte Systeme auf echte Art kaputtgehen.
Dann kam der erste Tool-Timeout. Dein Agent hat denselben fehlgeschlagenen Aufruf neunmal wiederholt, $12 an Tokens (Wort-Häppchen, die die KI verarbeitet, abgerechnet pro Nutzung) verbrannt und ein Fake-Ergebnis halluziniert. Weil nichts — buchstäblich nichts im Protokoll — ihm gesagt hat, dass der Fehler permanent war.
Vier Prioritäten, null davon betreffen Fehler
Am 19. April veröffentlichte das MCP-Projekt seine 2026-Roadmap. Vier Prioritäten: Transport-Weiterentwicklung, Agenten-Kommunikation, Governance, Enterprise-Reife. Error Taxonomy — genau das, was jeden Produktiv-Agenten zerlegt — hat es nicht auf die Liste geschafft. Nicht erwähnt. Nicht geplant. Auf niemandes Radar.
Das ist kein Versäumnis, das man einfach wegwischen kann. Die offizielle MCP-Spezifikation (aktuelle Revision: 25. November 2025) definiert Tool-Execution-Fehler als isError: true plus einen Freitext-String auf Englisch — dieselbe Struktur wie eine erfolgreiche Antwort, nur mit einem umgeklappten Boolean. Kein Error-Code-Feld. Kein Retry-After-Header. Kein Severity-Level. Die Spec sagt wortwörtlich, Tool-Fehler enthalten "actionable feedback that language models can use to self-correct." Dieses "actionable Feedback" ist ein unstrukturierter englischer Satz, den das LLM selbst lesen und interpretieren muss.
HTTP — das Protokoll, das dein Browser benutzt — hat das vor über dreißig Jahren gelöst. 404 heißt "gibt's nicht." 429 heißt "mach mal langsam." 503 heißt "versuch's später nochmal." Drei Ziffern. Eine Lookup-Tabelle. MCP verlangt von einem probabilistischen Sprachmodell, das zu tun, was ein simples If-Statement erledigen sollte.
Jeder bastelt seinen eigenen Workaround
Alexey Tyurin veröffentlichte am 9. März 2026 ein MCP Reliability Playbook über die Google Cloud Community. Er musste seine eigene Error-Taxonomie erfinden — CircuitOpenError, TimeoutError, RateLimitError — als Custom Typed Errors, weil das Protokoll keine bereitstellt. Circuit Breaker mit 50%-Fehlerschwelle, Exponential Backoff mit Jitter. 317 Tests, nur damit die Tools seinen Agenten nicht zum Absturz bringen. Alles Custom. Alles pro Server. Alles inkompatibel mit dem Klebeband aller anderen.
Während dessen haben Forscher der Polytechnique Montreal 407 MCP-spezifische Bugs in 385 Repositories analysiert (veröffentlicht am 5. März 2026) und festgestellt, dass Tool-Response-Handling die häufigste Fehlerkategorie war — 66,7% der befragten Entwickler waren darauf gestoßen. Und ein Claude-Code-Bug vom 11. März zeigte, dass das Protokoll auf noch grundlegendere Art versagt: Wenn MCP-Tools Daten im content-Feld ohne structuredContent zurückgaben, erkannte Claude Code eine leere Antwort und wiederholte endlos. Der Agent wusste nicht, dass er bereits die richtige Antwort bekam.
Die Zahlen lügen nicht
AWS-Heroes-Research vom 18. März bezifferte den Schaden: 97,1% der MCP-Tools haben mindestens ein Problem mit der Beschreibungsqualität, und verkettete Tool-Aufrufe mit jeweils 95% individueller Erfolgsrate liefern nur 85,7% Gesamtzuverlässigkeit. Pack noch unstrukturiertes Error-Handling auf diese Kette drauf, und du würfelst mit deinem Produktiv-Traffic.
Der AAIF MCP Summit am 19. April in New York zog 1.200 Teilnehmer an, und Linux-Foundation-CEO Jim Zemlin nannte MCP "das Linux der Agenten." Mutiger Vergleich — Linux hatte von Tag eins ordentliche Error-Codes.
Was du jetzt sofort tun solltest
Bis Anthropic — der Protokoll-Eigentümer — eine MCP-Spec-Revision mit maschinenlesbaren Fehlertypen liefert, wrap deine MCP-Tools mit strukturierten Error-Envelopes: ein String error_type, ein Boolean is_retryable und ein numerisches retry_delay_seconds. Setz ein hartes Per-Tool-Retry-Budget auf der Client-Seite. Maximal drei Versuche. Dann laut scheitern.
Das Agent-Tool-Ökosystem wiederholt das Error-Handling-Chaos des frühen Webs mit zehnfacher Geschwindigkeit. Irgendwo zwischen "Tool Error" und "$12 verbrannte Tokens" wartet ein dreistelliger Statuscode darauf, erfunden zu werden. Die Plattform, die ihn zuerst ausliefert, wird den Reliability-Layer besitzen, von dem alle anderen abhängen — so wie 200 OK zur unsichtbaren Infrastruktur wurde, über die niemand mehr nachdenkt.
Bis dahin rät dein Agent. Und er ist nicht besonders gut im Raten.
