Du hast deinen KI-Agenten an fünfzehn MCP-Server angeschlossen — Slack, GitHub, Jira, eine Datenbank — und alles getestet, bis es wie geschmiert lief. MCP (Model Context Protocol) ist der universelle Stecker-Standard, mit dem KI-Agenten mit externen Tools reden können, quasi USB für Daten. Deine Demo sah großartig aus. Dein Chef hat zufrieden genickt. Ab in Produktion.

Hier ist der Teil, vor dem dich niemand gewarnt hat: MCP-Server sind keine statischen Pakete, die auf deiner Festplatte rumliegen. Es sind laufende Prozesse und Remote-Endpunkte. Und Stand 25. April 2026 gibt es keine einzige Agenten-Plattform, die dir Bescheid sagt, wenn einer davon ausfällt, unerträglich langsam wird oder anfängt, Müll zurückzuliefern.

Die Hälfte deiner Tools ist vermutlich schon tot

Am 20. April hat RapidClaw 1.847 öffentliche MCP-Server in sieben Registries geprüft. Das Ergebnis: 52 % sind tot oder aufgegeben. Nur 17 % — 315 Server — waren produktionsreif. Der durchschnittliche MCP-Server hat sechs Commits insgesamt, einen Maintainer, null Tests und wurde seit 142 Tagen nicht mehr angefasst.

Das ist das Ökosystem, von dem dein Agent abhängt. Ein Münzwurf entscheidet, ob das Tool, das er aufruft, überhaupt noch funktioniert.

Und das MCP-Protokoll selbst hilft kein Stück. Es gibt keinen eingebauten Health-Check-Endpunkt — keine standardisierte Möglichkeit für einen Server zu sagen: 'Ich lebe und funktioniere." Die SDKs implementieren einen simplen ping, aber es gibt kein /health, kein /ready, keine Liveness Probe. Jedes Team baut sich was Eigenes — oder, was deutlich häufiger vorkommt, gar nichts.

Das protokollförmige Loch

Die Lücke liegt nicht nur bei den Plattformen — sie steckt in der Spezifikation selbst. HTTP hat Statuscodes. gRPC hat Health-Checking-Services. Kubernetes hat Liveness- und Readiness-Probes. MCP hat... eine ping-Methode, die bestätigt, dass die Transportschicht lebt, nicht dass der Server seinen Job tatsächlich erledigen kann.

Ein Datenbank-MCP-Server kann auf ping antworten, während sein Connection Pool erschöpft ist. Ein GitHub-MCP-Server kann brav pong zurückschicken, während sein Auth-Token seit drei Wochen abgelaufen ist. Das Protokoll unterscheidet nicht zwischen 'Transport funktioniert" und 'Tool funktioniert." Diese Unterscheidung ist relevant, wenn dein Agent Tokens verbrennt, weil er ein Tool erneut aufruft, das technisch antwortet, aber funktional lügt.

Googles Agent Observability, am 22. April als Teil der Gemini Enterprise Agent Platform veröffentlicht, trackt Request-Anzahl und p95-Latenz für MCP-Server. Zwei Metriken. Wir haben die breiteren Plattform-Lücken bereits behandelt — die Kurzversion: Google hat Agent-Level-Tracing gebaut, kein Tool-Level-Monitoring. AWS hat am 17. April mit der Agent Registry einen ähnlichen Katalog-Ansatz vorgestellt — ein Telefonbuch für Agenten, kein Gesundheitsmonitor. Beide erkennen an, dass Tools eine Infrastruktur-Behandlung brauchen. Keiner prüft tatsächlich, ob deine Tools noch am Leben sind.

Zum Vergleich: Jeder halbwegs ordentliche Microservice — ein kleiner, eigenständiger Baustein deines Backends — bekommt Health Checks, Fehlerraten, Analyse der Antwortqualität und automatische Alerts. Dein MCP-Server bekommt einen Request-Zähler und eine Stoppuhr.

Was passiert, wenn ein Tool kaputtgeht

Wenn ein MCP-Server leise degradiert, merkt dein Agent nichts. Er halluziniert entweder eine Antwort (erfindet etwas), versucht es still erneut und verbrennt dabei Tokens — die Wort-Einheiten, die KI verarbeitet, jede kostet Geld — oder scheitert, ohne dir zu verraten, welches Tool schuld war. Agent-Observability-Traces zeigen dir, was der Agent entschieden hat. Sie zeigen nicht, ob das Tool gesund war, als es geantwortet hat. Du siehst das Symptom. Die Ursache kannst du nicht diagnostizieren.

Das ist, als würdest du deine Web-App überwachen, aber nicht ihre Datenbank. Das Dashboard bleibt grün, bis alles in Flammen steht.

Was du jetzt sofort tun solltest

Wenn du Agenten in Produktion betreibst, behandle jeden MCP-Server wie eine Microservice-Abhängigkeit:

  • Setze Timeouts. Das MCP-Protokoll macht das nicht für dich.
  • Definiere Fallbacks. Wenn ein Tool ausfällt, braucht dein Agent einen Plan B, keine improvisierte Halluzination.
  • Überwache die Antwortqualität. Ein 200 OK, das Unsinn zurückgibt, ist schlimmer als ein sauberer Fehler.
  • Wickle Verbindungen in Circuit Breaker ein — ein Muster, das einen fehlerhaften Service abschaltet, bevor er alles andere mit runterzieht.
  • Akzeptiere die Obergrenze. Dein Agent ist genau so zuverlässig wie sein unzuverlässigstes Tool.

Die meisten Teams haben für diese Klempnerarbeit kein Budget eingeplant. Die meisten Teams werden lernen, warum sie es hätten tun sollen.

Die fehlende Schicht

Der Agent-Stack im April 2026 hat schlauere Modelle, größere Registries und schickere Gateways. Was er nicht hat, ist Tool-SRE — Site Reliability Engineering, angewandt auf die Tools, von denen Agenten abhängen. Frühere Artikel auf diesem Kanal haben argumentiert, dass Agent Reliability Engineering noch nicht existiert. Das RapidClaw-Audit beweist, dass das Problem eine Ebene tiefer liegt: Du kannst keine zuverlässigen Agenten haben, wenn das Protokoll, das sie sprechen, nicht einmal definiert, was 'gesund" für ein Tool bedeutet.

Die erste Plattform, die Tool-Level Health Monitoring mit /health- und /ready-Endpunkten direkt in die MCP-Spezifikation einbaut — nicht von jedem Anbieter einzeln drangeschraubt — erobert die Zuverlässigkeitsschicht, die dem gesamten Ökosystem fehlt.

Du hast mit fünfzehn MCP-Servern angefangen, die in der Entwicklung perfekt liefen. In Produktion sind ungefähr acht davon einen Münzwurf vom Tod entfernt. Niemand schaut hin. Fang vielleicht dort an.