MCP-Server Fallen Lautlos Aus. Dein Dashboard Sagt Nichts.

Dein MCP-Server gibt bei jeder Anfrage 200 OK zurück. Dein Dashboard ist grün. Deine Nutzer sind frustriert.

HTTP-Statuscodes messen hier nicht, was zählt. Das Tool hat Daten zurückgegeben. War es das richtige Tool? War die Antwort nützlich? Hat das Modell sie tatsächlich verwendet?

Eine öffentliche Anthropic-Auswertung zur agentischen Tool-Nutzung (MCP Bench, Ende 2025) hat Fehlerraten bei der Tool-Auswahl zwischen 28% und 46% auf populären MCP-Servern mit mehr als sechs Tools gemessen. Dasselbe Muster zeigt sich in Produktion: Server mit perfekter Uptime, unter 200ms Latenz, null 5xx-Fehler — während das Modell fast die Hälfte der Zeit das falsche Tool aufruft.

Der Server weiß es nicht. Das Team weiß es nicht. Die Nutzer sagen einfach, die KI sei schlecht.

Das ist der stille Ausfall. Ein MCP-Server kann jeden traditionellen Health-Check bestehen und trotzdem bei jedem Aufruf die falsche Frage beantworten.

Für eine REST-API heißt funktionieren: gültige Anfragen akzeptieren und korrekte Antworten zurückgeben. Jahrzehnte an Tooling existieren, um das zu verifizieren.

Für einen MCP-Server ist funktionieren eine Kette aus vier Schritten. Das Modell wählt das richtige Tool. Es sendet korrekte Parameter. Es erhält eine nützliche Antwort. Es integriert sie in seine Antwort. Jeder Schritt schlägt unabhängig fehl. Keiner davon taucht im traditionellen Monitoring auf.

Falsches Tool? 200. Parameter, die die Schema-Validierung bestehen, aber die Nutzerabsicht verfehlen? 200. Antwort ignoriert? 200.

Du kannst 100% Erfolgsrate im Dashboard und 40% Erfolgsrate in Produktion haben. In dieser Lücke sagen Nutzer „die KI funktioniert nicht" — und sie haben recht, auch wenn jede SRE-Metrik das Gegenteil sagt.

Sobald du akzeptierst, dass traditionelle Metriken unzureichend sind, wird die Frage, was du stattdessen messen solltest. Fünf Dinge.

**Tool-Auswahlgenauigkeit.** Wenn du `search_invoices` und `list_documents` hast und ein Nutzer nach „Rechnungen vom letzten Monat" fragt — welches wird aufgerufen? Tracke die Lücke zwischen beabsichtigter und tatsächlicher Auswahl. Das ist die aufschlussreichste Metrik in der MCP-Observability.

**Parameter-Validität.** Nicht, ob Parameter die Schema-Validierung bestanden — das ist Grundvoraussetzung. Hat die Datumsspanne zur Nutzerfrage gepasst? Hat die Suchanfrage die Intention erfasst?

**Antwort-Nutzung.** Hat das Modell die Antwort tatsächlich verwendet? Wenn du 50 Zeilen zurückgibst und das Modell keine davon referenziert, stimmt die Tool-Beschreibung nicht, das Format nicht, oder die Daten sind irrelevant.

**Fehler-Wiederherstellungsrate.** Wenn ein Aufruf fehlschlägt, versucht das Modell es mit korrigierten Parametern erneut, wechselt das Tool, oder gibt auf? Das Recovery-Muster zeigt, ob deine Fehlermeldungen nützlich sind.

**Kosten pro erfolgreicher Invokation.** Nicht Kosten pro Aufruf. Kosten pro Aufruf, der eine nützliche Antwort produziert hat. Verschwendete Retries und Aufrufe des falschen Tools treiben reale Kosten oft auf 3-5x der rohen API-Kosten.

Diese fünf sagen dir mehr über MCP-Server-Gesundheit als alle traditionellen Metriken zusammen.

Datadog, New Relic und Grafana sind exzellent in dem, was sie tun. Sie tracken Latenzverteilungen, Fehlerraten, Durchsatz und Ressourcenauslastung. Das ist die richtige Form für eine API, deren Aufrufer ein Browser oder eine Mobile-App ist, der deterministische Anfragen schickt.

Der Aufrufer eines MCP-Servers ist nicht deterministisch. Es ist ein Modell, das zur Inferenzzeit eine Entscheidung trifft. Der Fehlermodus ist nicht „Anfrage-Timeout". Er ist „das Modell hat entschieden, das wäre das richtige Tool, und war es nicht". Das ist ein Problem der Entscheidungsqualität, und traditionelles APM ist nicht dafür gebaut.

Konkret: Wenn dein Agent `get_customer` und `search_customers` hat und das Modell immer `get_customer` mit einer geratenen ID wählt, bleibt dein p99 flach, deine Fehlerrate flach, und jede einzelne Nutzerinteraktion endet im Fehlschlag. Das existierende Tooling hat kein Signal, das es emittieren kann.

Du brauchst eine Observability-Schicht zwischen Modell und Tools — eine, die Nutzerabsicht, Tool-Auswahl, Parameter und Antwort-Nutzung korrelieren kann. Traditionelles APM ist der Boden. Für MCP-Server ist es nicht mal die Hälfte des Bildes.

Drei konkrete Dinge zum Anfangen. Du musst nicht alles auf einmal lösen.

**1. Logge jede Invokation mit vollständigem Prompt-Kontext.** Nicht nur Tool-Name und Parameter. Das Gespräch, das zum Aufruf geführt hat, der System-Prompt, die letzte Nachricht des Nutzers. Ohne Kontext kannst du nicht bewerten, ob die Auswahl korrekt war.

**2. Tracke beabsichtigtes Tool versus ausgewähltes Tool.** Du brauchst Ground Truth — manuelle Labels auf einem Sample, Daumen-hoch/runter-Signale der Nutzer, oder heuristische Regeln (eine Nutzerfrage, die zu „Rechnung|Abrechnung|Zahlung" passt und in einem `list_contacts`-Aufruf endet, ist ein Defekt). Selbst grobe Heuristiken schlagen nichts.

**3. Miss die Antwort-Nutzung.** Vergleiche, was das Tool zurückgegeben hat, mit dem, was in der finalen Antwort des Modells erschienen ist. Eine große Lücke bedeutet schlechtes Antwortformat, irrelevante Daten, oder eine Tool-Beschreibung, die dem Modell nicht hilft, das Ergebnis zu nutzen.

Diese drei Signale — Invokationskontext, Auswahlgenauigkeit, Antwort-Nutzung — sagen dir, ob dein MCP-Server den Nutzern tatsächlich hilft. Five-Nines-Uptime-Dashboards sagen dir, ob der Prozess lebt. Das sind zwei verschiedene Fragen.