Produktionskontext für Ihren Coding Agent

Was ist ein MCP Server?

Das Model Context Protocol (MCP) ist ein offenes Protokoll, mit dem sich KI-Anwendungen einheitlich an externe Werkzeuge und Datenquellen anbinden lassen. Ein MCP Server stellt eine Reihe von Tools bereit, etwa „Fehler suchen“ oder „Abfrage ausführen“, die ein MCP-Client wie ein Coding Agent erkennen und aufrufen kann. Der Agent entscheidet, wann ein Tool hilfreich ist, ruft es auf und verwendet das Ergebnis für seine Antwort oder den nächsten Schritt.

Für Observability bedeutet das: Ein Coding Agent kann sehen, was in Produktion tatsächlich passiert, statt nur über den vorliegenden Quellcode zu schlussfolgern.

Warum Observability-Daten in die IDE gehören

Wer einen Fehler behebt, wechselt meist zwischen mehreren Werkzeugen: Editor, Error Tracking, Tracing-Ansicht, Log-Suche und Deployment-Historie. Coding Agents haben dasselbe Problem. Ohne Zugriff auf Laufzeitdaten können sie nur aus dem Code und aus dem, was Entwicklerinnen und Entwickler in den Chat kopieren, ableiten, was schiefläuft.

Ein Observability-MCP-Server schließt diese Lücke. Der Agent kann den Stack Trace des Fehlers abrufen, den er beheben soll, prüfen, welcher Endpunkt wie stark verlangsamt ist, oder herausfinden, ob das Problem mit einem bestimmten Release begann. So entstehen Fixes, die auf beobachtetem Verhalten beruhen, mit weniger Wechseln zwischen Werkzeugen.

So funktioniert der Obseria MCP Server

Der Obseria MCP Server ist Teil der Obseria-Plattform, neben der API und der CLI. Er funktioniert mit MCP-fähigen Clients wie Claude Code, Cursor, GitHub Copilot und Windsurf. Sie tragen ihn mit einem Obseria-API-Token in die Konfiguration Ihres Clients ein, und der Client erkennt die verfügbaren Tools automatisch.

Die Tools decken die Daten ab, die beim Programmieren am hilfreichsten sind:

• Fehler: aktuelle Fehler pro Service, Release oder Endpunkt mit Stack Traces und Häufigkeit.
• Traces: langsame oder fehlerhafte Traces und die Spans, die ihre Dauer bestimmen.
• Logs und Metriken: Abfragen in OQL, PromQL oder SQL auf Obseria Lake.
• Deployments: welche Version in welcher Umgebung läuft und was sich zuletzt geändert hat.
• Services: Zuständigkeiten und Abhängigkeiten aus TopoGraph.

Alle Daten stammen aus derselben OpenTelemetry-basierten Telemetrie, die Ihr Team ohnehin an Obseria sendet. Einen separaten Datenspeicher für den MCP Server gibt es nicht.

Beispiel-Prompts

Sobald der Server verbunden ist, können Sie Ihrem Coding Agent zum Beispiel diese Fragen stellen:

Welche Fehler treten im Checkout-Service seit dem letzten Deployment am häufigsten auf?
Zeig mir den Stack Trace der NullPointerException in OrderService und schlag einen Fix vor.
Warum ist GET /api/cart heute langsam? Welche Spans brauchen am längsten?
Hat sich die Fehlerrate im Payment-Service nach Release 2.14.0 verändert?
Schreib einen Test, der den häufigsten Fehler in dieser Datei reproduziert.

Der Agent entscheidet, welche Obseria-Tools er aufruft, holt die Daten und verbindet sie mit dem Code in Ihrem Workspace. Die Tool-Aufrufe sehen Sie in Ihrem Client und können sie prüfen.

Sicherheit und Zugriffskontrolle

Wer einem KI-Agenten Zugriff auf Produktionsdaten gibt, braucht klare Grenzen. Der Obseria MCP Server nutzt API-Tokens, die Sie in Obseria erstellen und widerrufen. Standardmäßig haben Tokens nur Lese-Scopes: Der Agent kann Daten abfragen, aber keine Alerts, Dashboards oder Konfigurationen ändern. Zusätzlich können Sie ein Token auf bestimmte Projekte, Umgebungen oder Datentypen beschränken.

Der Zugriff unterliegt der rollenbasierten Zugriffskontrolle Ihrer Organisation, sodass ein Agent nie mehr sieht, als Token und Eigentümer sehen dürfen. Jeder Tool-Aufruf wird mit Token, Nutzer, Zeitpunkt und Abfrage im Audit-Log festgehalten. Maskieren Sie personenbezogene Daten in Obseria Pipeline, bleiben diese Werte auch für den Agenten maskiert.

Best Practices

1. Ein Token pro Person oder Agent. So bleibt das Audit-Log aussagekräftig, und Sie können Zugriffe gezielt widerrufen.
2. Scopes eng halten. Beginnen Sie mit Lesezugriff auf die Projekte, an denen jemand arbeitet.
3. Sensible Daten beim Ingest maskieren. Die Pipeline ist die erste Schutzschicht für alles, was danach folgt.
4. Tool-Aufrufe prüfen. Sehen Sie sich an, welche Abfragen der Agent ausgeführt hat, bevor Sie sich auf seine Schlüsse verlassen.