Die Versteckten Kosten, Wenn Man Seine MCP-Server Nicht Überwacht

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

Diese Diskrepanz ist häufiger als irgendjemand zugibt. HTTP-Statuscodes messen nicht, was zählt. Das Tool hat Daten zurückgegeben — aber war es das richtige Tool? War die Antwort nützlich? Hat das LLM sie tatsächlich verwendet?

Ich habe MCP-Deployments gesehen, wo 40% der Tool-Aufrufe komplett das falsche Tool waren. Der Server war nach jeder traditionellen Metrik gesund. Latenz unter 200ms. Null 5xx-Fehler. 99,99% Uptime. Und fast die Hälfte der Zeit rief das LLM ein Tool auf, das die Frage des Nutzers unmöglich beantworten konnte.

Der Server wusste es nicht. Das Team wusste es nicht. Die Nutzer dachten einfach, die KI sei schlecht.

Das ist das Problem der stillen Ausfälle. Dein MCP-Server kann gleichzeitig „perfekt funktionieren" und „komplett kaputt sein" — je nachdem, was du misst. Und gerade messen die meisten Teams die falschen Dinge.

Für eine REST-API bedeutet „funktionieren": „akzeptiert gültige Anfragen und gibt korrekte Antworten zurück." Einfach. Jahrzehnte an Tooling existieren dafür.

Für einen MCP-Server ist „funktionieren" eine Kette aus mindestens vier Dingen, die richtig laufen müssen: Das LLM wählt das richtige Tool, sendet korrekte Parameter, erhält eine nützliche Antwort und integriert sie korrekt in seine Antwort. Jeder Schritt kann unabhängig fehlschlagen. Und keiner dieser Fehler taucht im traditionellen Monitoring auf.

Das LLM wählt das falsche Tool? Dein Server gibt trotzdem 200 zurück. Die Parameter sind technisch gültig aber semantisch falsch? Trotzdem 200. Die Antwort ist akkurat aber das LLM ignoriert sie? Trotzdem 200.

Du kannst 100% Erfolgsrate auf deinem Dashboard und 40% tatsächliche Erfolgsrate in Produktion haben. Diese Lücke ist, wo die Nutzer-Frustration lebt. Diese Lücke ist der Grund, warum Leute sagen „die KI funktioniert nicht", wenn sie eigentlich meinen „die Tools sind nicht instrumentiert, um die Fehler zu erkennen, die zählen."

Sobald du akzeptierst, dass traditionelle Metriken unzureichend sind, wird die Frage: Was solltest du stattdessen messen?

Tool-Auswahlgenauigkeit. Wenn ein Nutzer eine Frage stellt, wählt das LLM das Tool, das du erwarten würdest? Wenn du ein search_invoices-Tool und ein list_documents-Tool hast und der Nutzer nach „Rechnungen vom letzten Monat" fragt — welches wird aufgerufen? Tracke das. Die Lücke zwischen beabsichtigter und tatsächlicher Tool-Auswahl ist die aufschlussreichste Metrik in der MCP-Observability.

Parameter-Validitätsrate. Nicht „haben die Parameter die Schema-Validierung bestanden" — das ist Grundvoraussetzung. Hatten die Parameter semantisch Sinn?

Antwort-Nutzung. Die, die niemand trackt, und die wohl wichtigste. Hat das LLM die Antwort tatsächlich verwendet? Wenn du 50 Zeilen Daten zurückgibst und das LLM alles ignoriert, stimmt etwas nicht.

Fehler-Wiederherstellungsrate. Wenn ein Tool-Aufruf fehlschlägt — versucht das LLM es mit korrigierten Parametern erneut, probiert ein anderes Tool, oder gibt einfach auf?

Kosten pro erfolgreicher Invokation. Nicht Kosten pro Invokation — Kosten pro erfolgreicher Invokation. Wenn du die verschwendeten Aufrufe einrechnest, sind die realen Kosten oft 3-5x so hoch wie die Roh-API-Kosten suggerieren.

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

Ich weiß, was du denkst. „Ich habe schon Datadog. Ich habe schon Observability." Wahrscheinlich. Und es ist wahrscheinlich nutzlos dafür.

Datadog, New Relic, Grafana — sie sind hervorragend in dem, was sie tun. Sie tracken Latenzverteilungen, Fehlerraten, Durchsatz, Ressourcenauslastung. Perfekt für APIs, wo der Aufrufer ein Webbrowser ist, der deterministische Anfragen stellt.

Aber das LLM, das dein Tool aufruft, ist kein Webbrowser. Es ist eine Reasoning-Engine, die Entscheidungen trifft. Der Fehlermodus ist nicht „Anfrage hat einen Timeout" — sondern „das Modell hat entschieden, das wäre das richtige Tool, und war es nicht." Das ist kein Latenzproblem. Das ist ein Problem der Entscheidungsqualität. Und kein traditionelles APM-Tool ist dafür gebaut, Entscheidungsqualität zu messen.

Es ist wie einen Tacho zu benutzen, um herauszufinden, warum ein Auto immer zum falschen Ziel fährt. Der Tacho funktioniert einwandfrei. Er misst nur nicht, was wirklich kaputt ist.

Du brauchst eine neue Observability-Schicht zwischen dem LLM und deinen Tools. Eine, die die semantische Beziehung zwischen Nutzerabsicht, Tool-Auswahl, Parametern und Antwort versteht. Traditionelles APM ist das Fundament. Aber für MCP-Server ist es nicht mal die Hälfte des Bildes.

Was tust du also konkret? Du musst nicht alles auf einmal revolutionieren. Fang mit drei Dingen an.

Erstens: Logge jede Tool-Invokation mit dem vollständigen Prompt-Kontext. Nicht nur den Tool-Namen und die Parameter — das Gespräch, das zum Aufruf geführt hat. Ohne diesen Kontext kannst du nicht bewerten, ob die Auswahl korrekt war.

Zweitens: Tracke, welches Tool ausgewählt wurde versus welches beabsichtigt war. Das erfordert etwas Ground Truth — manuelles Labeling, Nutzer-Feedback-Signale oder heuristische Regeln. Selbst grobe Heuristiken sind besser als nichts. Wenn ein Nutzer nach Rechnungen fragt und das LLM ein Kontakte-Tool aufruft, ist das ein automatisch erkennbarer Auswahlfehler.

Drittens: Miss die Antwort-Nutzung. Vergleiche, was dein Tool zurückgegeben hat, mit dem, was tatsächlich in der Antwort des LLM erschien. Wenn die Lücke groß ist — viele Daten zurückgegeben, wenig genutzt — hast du ein Signal gefunden.

Diese drei Signale — Invokationskontext, Auswahlgenauigkeit und Antwort-Nutzung — sagen dir mehr über die reale Performance deines MCP-Servers als alle traditionellen Metriken zusammen. Sie sind der Unterschied zwischen wissen, dass dein Server läuft, und wissen, dass er den Nutzern tatsächlich hilft.

Die Teams, die diese Observability-Schicht jetzt aufbauen, werden einen massiven Vorteil haben. Nicht weil die Technologie schwer ist — ist sie nicht. Sondern weil die Einsichten, die sie liefert, so viel reichhaltiger sind als das, was alle anderen betrachten. Während deine Wettbewerber Latenz-Dashboards anschauen und sich zu Five-Nines-Uptime beglückwünschen, wirst du tatsächlich wissen, ob deine Tools funktionieren.