MCP für Agenten

Richten Sie einen MCP-Client auf Perstat, beantwortet er aus Ihren Live-Daten, was ausgefallen ist und wer sich darum kümmert, und handelt innerhalb seiner Berechtigung. Der am 26. August 2026 geprüfte Quellkatalog definiert fünfzehn Werkzeuge: sieben lesen, zwei handeln an einem Vorfall, sechs verwalten Projekte und Monitore. Maßgeblich für den verbundenen Server ist tools/list; create_project ist nicht separat in Produktion verifiziert. Kein definiertes Werkzeug löscht eine Aufzeichnung.

Anschluss

Adresse	https://api.perstat.io/mcp
Transport	Streamable HTTP, zustandslos
Protokollfassungen	2025-06-18 (bevorzugt), 2025-03-26, 2024-11-05

Eine JSON-RPC-Nachricht per POST hinein, eine JSON-Antwort heraus. GET /mcp antwortet mit 405: Dieser Server öffnet keinen Ereignisstrom von sich aus. Sammelanfragen gibt es seit 2025-06-18 nicht mehr, sie werden mit einem klaren Hinweis abgelehnt.

In Claude Code:

claude mcp add --transport http perstat https://api.perstat.io/mcp \
  --header "Authorization: Bearer pst_…"

Diese Form funktioniert in Clients, die einen eigenen HTTP-Autorisierungsheader annehmen. Beachten Sie, dass der Schlüssel auf diesem Weg in Ihrer Shell-Historie landet.

Oder das Plugin installieren

Für Claude Code gibt es ein Plugin. Es hängt denselben Server ein und bringt vier Skills mit, die aus den Werkzeugen Abläufe machen: einen Vorfall bearbeiten, Monitore verwalten und die Lage lesen.

claude plugin marketplace add datargo/perstat-plugin
claude plugin install perstat@datargo

Beim ersten Perstat-Werkzeugaufruf öffnet Claude die OAuth-Anmeldung im Browser. Wählen Sie die Organisation für die Verbindung; es gibt keinen Schlüssel zu kopieren und kein Shell-Profil zu bearbeiten. Die Verbindung ist an diese Organisation und Ihre aktuelle Rolle gebunden. Mit claude mcp list prüfen Sie, dass Perstat Connected meldet.

Den API-Schlüssel-Einzeiler oben verwenden Sie für CI, Cron oder bewusst auf Projekte begrenzte Zugänge. Das Plugin ist der interaktive, browsergestützte Weg.

Anmeldung

Perstat akzeptiert einen mit Scopes begrenzten Organisations-API-Schlüssel als Bearer:

Authorization: Bearer pst_…

OAuth-fähige Clients können stattdessen den veröffentlichten Authorization-Code-Ablauf mit PKCE verwenden. Die Discovery-Dokumente liegen unter https://api.perstat.io/.well-known/oauth-protected-resource/mcp und https://api.perstat.io/.well-known/oauth-authorization-server; dort stehen auch Refresh- und Widerrufs-Endpunkte. Ein Sitzungs-Cookie allein meldet nicht bei MCP an: Der OAuth-Ablauf endet in einem Bearer-Token.

OAuth-Clients werden von Claude, Claude Code und ChatGPT angenommen, erkannt an ihren Client-Dokumenten unter https://claude.ai/oauth/ und https://chatgpt.com/oauth/. Der Zustimmungsbildschirm nennt den Host, von dem der Client kommt, nicht nur den Namen, den er sich selbst gibt, und ein Client erhält nur die Rechte, die seine Werkzeuge brauchen: monitors und incidents, jeweils lesend oder schreibend.

Ein Organisationsschlüssel hängt an genau einer Organisation und trägt Scopes. Dadurch kann er nie mehr, als im Schlüssel steht.

Schlüssel legen Eigentümer und Administratoren in der App unter Integrationen, API-Schlüssel an.

Die Werkzeuge

tools/list zeigt nur, was die aktuelle Berechtigung erlaubt. tools/call prüft denselben Scope noch einmal, denn eine Liste ist keine Absicherung.

Der vollständige Quellkatalog umfasst fünfzehn Werkzeuge. Browser-OAuth vergibt derzeit Monitor- und Incident-Scopes; Plugin-Nutzer erhalten deshalb list_status_pages nicht. Mit einem API-Schlüssel samt status-pages:read ist das Werkzeug verfügbar. Maßgeblich für den konkreten Zugang bleibt die Antwort des verbundenen Servers auf tools/list.

Werkzeug	Scope	Wirkung
get_organization_summary	monitors:read	Die Lage in einem Aufruf: Dienste je Zustand, offene Vorfälle
list_projects	monitors:read	Projekte samt Monitor-Zahl. Der Einstieg für create_monitor
list_monitors	monitors:read	Dienste mit zuletzt bestätigtem Zustand, filterbar. Mit archived: true das Archiv
get_monitor	monitors:read	Ein Dienst mit Konfiguration, Regionen und jüngsten Vorfällen. Werte eigener Request-Header kommen als [redacted] zurück
list_incidents	incidents:read	Offene und gelöste Vorfälle, neueste zuerst
get_incident	incidents:read	Ein Vorfall im Detail
acknowledge_incident	incidents:write	Vorfall übernehmen, das stoppt Alarm und Eskalation
resolve_incident	incidents:write	Einen offenen Vorfall von Hand schließen
list_status_pages	status-pages:read	Die Statusseiten der Organisation
create_project	monitors:write	Den Ordner anlegen, in dem Monitore liegen. Nur mit org-weiten Schlüsseln
create_monitor	monitors:write	Einen neuen Dienst überwachen. Nur mit org-weiten Schlüsseln
update_monitor	monitors:write	Name, Einstellungen, Prüfabstand oder Regionen ändern
set_monitor_enabled	monitors:write	Einen Monitor pausieren oder wieder in Betrieb nehmen
archive_monitor	monitors:write	Einen Dienst außer Betrieb nehmen und seinen Platz im Tarif freigeben
restore_monitor	monitors:write	Einen archivierten Dienst zurückholen. Er kommt pausiert zurück und braucht einen freien Platz im Tarif

write schließt read derselben Ressource ein, nie über Ressourcen hinweg.

Alles, was der Agent zu sehen bekommt, ist englisch: Werkzeugnamen, Beschreibungen, Schema-Texte und Fehlergründe. Das Aktivitätsprotokoll in der Anwendung bleibt davon unberührt, denn das lesen Menschen.

create_project und create_monitor sind die beiden Werkzeuge, die nicht idempotent sind, und melden das dem Client. Ein wiederholter Aufruf kann eine zweite Ressource anlegen oder am Namen scheitern. Vorher mit list_projects oder list_monitors nachsehen.

Werkzeuge, die bestehenden Zustand ändern oder beenden (acknowledge_incident, resolve_incident, update_monitor, set_monitor_enabled, archive_monitor), sind als destruktiv gekennzeichnet, damit ein Client vor dem Aufruf nachfragen kann. Anlegen und Wiederherstellen fügen nur hinzu.

Eigene Request-Header eines Monitors sind Zugangsdaten und werden über einen Schlüssel oder einen Agenten nie zurückgelesen: get_monitor zeigt ihre Namen mit dem Wert [redacted]. Schicken Sie eine Konfiguration mit dem Platzhalter über update_monitor zurück, bleibt der gespeicherte Wert erhalten, solange URL und Methode exakt gleich bleiben. Nach jeder Änderung an einer von beiden wird der Platzhalter abgewiesen, damit ein Zugangsdatum nie einer Anfrage folgt, die sein Urheber nicht eingerichtet hat. Angemeldete Mitglieder sehen die Werte in der Web-App weiterhin.

Über MCP archiviert, über MCP nicht gelöscht

Ein Agent darf einen Dienst archivieren. Löschen darf er nie, und der Grund ist nicht Vorsicht.

Einen Monitor zu löschen kaskadiert durch elf Tabellen und nimmt die Incident-Historie, die täglichen SLA-Rollups und die Ausschlussfenster mit. Bei einem Produkt, dessen ganzer Zweck die Aufzeichnung ist, darf ein Agentenaufruf da nicht hinreichen. Also gibt es das Werkzeug dafür gar nicht erst.

archive_monitor stoppt den Dienst, nimmt ihn aus den aktiven Listen und gibt seinen Platz im Tarif frei, während die Ressource wiederherstellbar bleibt. Das Archivieren selbst löscht die Historie nicht; normale objektbezogene Aufbewahrungsregeln gelten dennoch. Ein dauerhafter Speicher ist das nicht. restore_monitor holt ihn pausiert zurück und belegt wieder einen Platz im Tarif: Ist der Tarif voll, wird das Zurückholen mit demselben Hinweis abgelehnt wie create_monitor, bis ein anderer Monitor archiviert oder der Tarif gewechselt ist. Der Name wird beim Archivieren frei, ein neuer Monitor kann ihn also tragen.

Für Ihr Kontingent ist der Unterschied wichtig, denn beides ist nicht dasselbe: Pausieren gibt den Platz nicht frei, der Monitor ist weiter da und weiter gemeint. Archivieren schon. Wer wirklich hart löschen will, tut das in der Anwendung, wo ein Mensch auf die Folgen schaut.

Der Weg zurück darf nicht am Gedächtnis hängen. list_monitors mit archived: true zeigt das Archiv, und get_monitor findet Archivierte ebenfalls, damit man vor dem Zurückholen nachsehen kann. Ohne das wäre ein archivierter Monitor über MCP unerreichbar, sobald jemand die ID verliert. Was an einem archivierten Monitor nicht geht, ist ihn zu ändern oder anzuschalten: update_monitor und set_monitor_enabled weisen ihn mit „is archived, call restore_monitor first“ ab, nicht mit „nicht gefunden“, denn er fehlt ja nicht.

Ebenfalls außer Schreibreichweite über MCP: Änderungen an Statusseiten, Connectoren, API-Schlüssel, Mitglieder und Ihr Tarif. list_status_pages ist eine reine Leseausnahme für API-Schlüssel mit status-pages:read; Browser-OAuth erhält diesen Scope derzeit nicht. Operative Writes bleiben auf Monitoring und Incidents begrenzt.

Jede Handlung trägt einen Namen

Eine Handlung über MCP wird der menschlichen Identität des Credentials zugeschrieben: dem API-Schlüsselersteller oder OAuth-Subject. So hat die Übernahme während eines Vorfalls einen Namen und war nicht bloß ein Token. Im Verlauf des Vorfalls steht zusätzlich, dass sie über MCP kam. Monitore, die ein Agent anlegt oder ändert, erscheinen genauso im Aktivitätsprotokoll Ihrer Organisation, unter dem Namen dieser Identität.

Weil diese Identität für die Zuschreibung geborgt wird, entscheidet sie auch über die Berechtigung. Bei jedem einzelnen schreibenden Aufruf prüft der Server neu, dass die Identität noch Mitglied der Organisation ist und noch die Rolle trägt, die zur Handlung gehört. Die Schwelle entspricht der in der Anwendung: Vorfälle bearbeiten darf, wer reagieren darf, bis hinunter zum Responder; Monitore verwalten darf, wer Projekte verwalten darf, also Owner, Admin oder Developer. Wird diese Identität herabgestuft oder entfernt, schreibt ihr Credential ab dem nächsten Aufruf nicht mehr. Lesen bleibt davon unberührt und hängt allein an den Scopes des Credentials. Ist das Konto dieser Person gelöscht, verweigert der Server das Schreiben ebenfalls und sagt warum.

Verengte Schlüssel

Ein auf bestimmte Projekte oder Monitore verengter Schlüssel sieht in list_monitors und list_incidents nur seine eigenen Ressourcen. Alles andere existiert für ihn schlicht nicht, und er kann auch nicht herausfinden, ob es existiert. Beim Schreiben gilt dasselbe: update_monitor und set_monitor_enabled melden für einen fremden Monitor, dass es keinen Monitor mit dieser ID gibt, nicht, dass es verboten wäre.

Org-weite Werkzeuge, get_organization_summary, list_status_pages, create_project und create_monitor, stehen ihm gar nicht erst zur Verfügung. Die beiden anlegenden Werkzeuge könnten sonst in Projekte schreiben, von denen der Schlüssel nichts weiß.

Fehler

Die Listen-Werkzeuge melden neben den Zeilen total_matching und truncated. Eine gekürzte Antwort ist damit als solche erkennbar, statt wie ein vollständiges Ergebnis auszusehen.

Ein Fehlschlag innerhalb eines Werkzeugs ist kein Protokollfehler. Er kommt als Ergebnis zurück, das als Fehler markiert ist und einen Grund im Klartext trägt. So sieht das Modell, was schiefging, und kann es anders versuchen. Protokollfehler bleiben echten Formfehlern vorbehalten.