Installation überspringen. In unter 2 Minuten einsatzbereit.
Starte eine kostenlose Testphase auf cloud.anythingmcp.com, füge PagerDuty mit einem Klick hinzu und richte deinen KI-Client (Claude, ChatGPT, Copilot oder Cursor) auf den erzeugten MCP-Endpoint. Kein Docker, kein git clone, keinerlei Entwicklungserfahrung nötig.
Zusammenfassung
Lass deine KI mit PagerDuty arbeiten: offene Incidents mit Zeitverlauf, Alerts und Notizen ansehen, herausfinden, wer Bereitschaft hat, Services, Eskalationsrichtlinien, Dienstpläne und Teams lesen, Incidents nach Rückfrage bei dir quittieren, lösen, neu zuweisen oder eskalieren und Incident-Analysen abrufen.
Frag einfach
Beispiel-Prompts für PagerDuty
Klick auf einen Prompt, um ihn zu kopieren. In Claude, ChatGPT, Cursor, Gemini, Copilot oder OpenClaw einfügen — und gegen diesen Connector laufen lassen.
Claude ist KI und kann Fehler machen. Bitte Antworten gegenprüfen.
💡 Keine Installation? Nutze cloud.anythingmcp.com direkt. Einloggen, Connectors → PagerDuty klicken, Zugangsdaten einfügen, MCP-API-Key erzeugen, fertig. Kein Docker, kein
git clone, kein lokaler Server.
PagerDuty
Lass deine KI mit PagerDuty arbeiten: offene Incidents mit Zeitverlauf, Alerts und Notizen ansehen, herausfinden, wer Bereitschaft hat, Services, Eskalationsrichtlinien, Dienstpläne und Teams lesen, Incidents nach Rückfrage bei dir quittieren, lösen, neu zuweisen oder eskalieren und Incident-Analysen abrufen.
Einrichtung
- Melde dich bei PagerDuty an und wähle den Schlüsseltyp. Ein User Token handelt als du und sieht, was du siehst: Öffne deinen Avatar, dann My Profile → User Settings → Create API User Token. Ein General Access Key handelt für das ganze Konto und braucht einen Admin: Integrations → API Access Keys → Create New API Key. Setze dort ein Häkchen bei Read-only für einen Connector, der nur liest.
- Füge den Schlüssel allein in
PAGERDUTY_API_KEYein, ohneToken token=davor. - Setze
PAGERDUTY_API_HOSTaufapi.pagerduty.comfür die US-Service-Region oder aufapi.eu.pagerduty.comfür die EU-Service-Region (deine Region steht unter Account Settings). Ein Schlüssel funktioniert nur auf dem Host seiner eigenen Region. - Optional: Mit einem General Access Key setzt du
PAGERDUTY_FROM_EMAILauf die E-Mail-Adresse eines PagerDuty-Benutzers. PagerDuty braucht sie für jede Änderung und verbucht die Änderung unter diesem Benutzer. Mit einem User Token bleibt das Feld leer. - Prüfe die Einrichtung mit
pagerduty_list_services.pagerduty_get_current_userfunktioniert nur mit einem User Token; mit einem General Access Key antwortet PagerDuty mit 400, weil dieser Schlüssel zu keinem Benutzer gehört.
Wer was sieht: Ein User Token sieht und ändert nur, was sein Besitzer in PagerDuty darf. Ein General Access Key deckt das ganze Konto ab; ein Read-only-Schlüssel kann nichts ändern. Teile den MCP-Server nur mit Personen, die an euren Incidents handeln dürfen.
Änderungen alarmieren Menschen und schließen Incidents, deshalb fragt die KI vorher: Vor jedem dieser Aufrufe zeigt dir die KI den Incident (Nummer und Titel) und die Änderung und wartet auf dein Ja. pagerduty_acknowledge_incident stoppt die Alarmierung, der Incident bleibt aber offen. pagerduty_resolve_incident schließt ihn. pagerduty_reassign_incident alarmiert den neuen Benutzer und entfernt die bisherigen Zuständigen. pagerduty_escalate_incident alarmiert die Bereitschaft der gewählten Stufe. pagerduty_update_incident ändert Titel, Dringlichkeit oder Priorität (per Name, etwa P1); eine neue Dringlichkeit kann ändern, wer wie alarmiert wird. pagerduty_add_incident_note fügt eine Notiz hinzu, die alle am Incident sehen und die sich später nicht bearbeiten lässt. pagerduty_create_incident eröffnet einen Incident auf einem Service und alarmiert sofort dessen Bereitschaft. Bei der Installation ist nichts deaktiviert, und kein Tool löscht etwas; für ein reines Lese-Setup nimm einen Read-only General Access Key oder schalte diese Tools ab.
So arbeitest du: Offene Incidents liefert pagerduty_list_incidents, gefiltert auf die Status triggered und acknowledged; danach pagerduty_get_incident, pagerduty_list_incident_log_entries (der Zeitverlauf), pagerduty_list_incident_alerts (was das Monitoring-Tool geschickt hat) und pagerduty_list_incident_notes. Wer gerade Bereitschaft hat: pagerduty_list_oncalls. Schichten eines Dienstplans: pagerduty_list_schedules, dann pagerduty_get_schedule. Eskalationsstufen: pagerduty_list_escalation_policies und pagerduty_get_escalation_policy. Verzeichnis: pagerduty_list_services, pagerduty_get_service, pagerduty_list_users (die Benutzer-ID für eine Neuzuweisung), pagerduty_get_user, pagerduty_list_teams und pagerduty_list_priorities.
IDs und Datumsangaben: IDs sind kurze Zeichenfolgen wie PT4KHLK; die Incident-Nummer (#1234) ist keine ID. Datumsangaben sind ISO 8601. pagerduty_list_incidents umfasst die letzten 30 Tage, außer du gibst Beginn und Ende an (höchstens 6 Monate auseinander) oder fragst nach allen Incidents.
Analysen: pagerduty_get_incident_analytics (pro Incident: Zeit bis zur Quittierung und zur Lösung, Eskalationen, Unterbrechungen) und pagerduty_get_incident_metrics (Summen für einen Zeitraum oder pro Tag, Woche oder Monat) brauchen einen PagerDuty-Tarif mit Analytics. Mit einem User Token müssen sie nach service_ids oder team_ids gefiltert werden. Die Daten hinken der Echtzeit einige Stunden hinterher.
Häufige Fehler: 401: Der Schlüssel ist falsch, wurde gelöscht oder gehört zum Host der anderen Region. 400 zum From-Header: Ein General Access Key hat etwas geändert, ohne dass PAGERDUTY_FROM_EMAIL gesetzt ist, oder diese E-Mail gehört zu keinem Benutzer des Kontos. 400 bei pagerduty_get_current_user: Der Schlüssel ist ein General Access Key. 403: Ein Read-only-Schlüssel wollte etwas ändern, die Rolle des Benutzers erlaubt es nicht, oder dem Tarif fehlt die Funktion (Teams, Analytics). 404: Diese ID gibt es in diesem Konto nicht. 429: zu viele Anfragen; warte kurz und versuche es erneut.
Nicht abgedeckt sind die Events API (Alerts, die mit dem Routing Key einer Integration gesendet werden), das Anlegen oder Ändern von Services, Dienstplänen, Eskalationsrichtlinien und Benutzern, Statusseiten, Incident Workflows, Webhooks sowie jedes Löschen.
Voraussetzungen: PAGERDUTY_API_KEY, PAGERDUTY_API_HOST
Connector lokal installieren
curl -fsSL https://raw.githubusercontent.com/HelpCode-ai/anythingmcp/main/docker-compose.quickstart.yml -o docker-compose.yml
printf 'JWT_SECRET=%s\nENCRYPTION_KEY=%s\n' "$(openssl rand -hex 32)" "$(openssl rand -hex 32)" > .env
docker compose up -d
Öffne http://localhost:3000/connectors/store, wähle PagerDuty und trage die unter Voraussetzungen aufgelisteten Variablen ein.
Verfügbare Tools
| Tool | What it does |
|---|---|
pagerduty_get_current_user | Read the PagerDuty user behind the API key: id, name, email, role, time zone and teams |
pagerduty_list_incidents | List incidents, newest first by default: id, number, title, status, urgency, priority, service, escalation policy, who it is assigned to… |
pagerduty_get_incident | Read one incident: number, title, status, urgency, priority, service, escalation policy, assignees, acknowledgements, teams, alert counts… |
pagerduty_list_incident_notes | List the notes on an incident, oldest first: id, text, who wrote it and when |
pagerduty_list_incident_log_entries | Read the timeline of an incident: triggers, notifications, acknowledgements, escalations, reassignments, notes and resolution, each with… |
pagerduty_list_incident_alerts | List the alerts grouped into an incident: id, summary, status, severity, alert key, service, created time and the event details the… |
pagerduty_acknowledge_incident | Acknowledge an incident: it stops escalating and the responders are no longer paged for it, but it stays open |
pagerduty_resolve_incident | Resolve an incident: it is closed, its alerts are resolved and nobody is paged for it any more |
pagerduty_reassign_incident | Reassign an incident to one user: PagerDuty pages that user and removes the current assignees |
pagerduty_escalate_incident | Escalate an incident to a level of its escalation policy: PagerDuty pages the on-call responders of that level |
pagerduty_update_incident | Change an incident's title, urgency or priority |
pagerduty_add_incident_note | Add a note to an incident's timeline |
pagerduty_create_incident | Open a new incident on a service: PagerDuty pages the on-call responders of the service's escalation policy right away |
pagerduty_list_services | List services (the things PagerDuty raises incidents for): id, name, description, status (active, warning, critical, maintenance… |
pagerduty_get_service | Read one service: name, description, status, escalation policy, teams, urgency rule, acknowledgement and auto-resolve timeouts, alert… |
pagerduty_list_escalation_policies | List escalation policies: id, name, description, how many times they repeat, the levels with their delay and targets (users or schedules)… |
pagerduty_get_escalation_policy | Read one escalation policy: levels in order with their delay in minutes and targets (users and schedules), repeat count, services and teams |
pagerduty_list_oncalls | Who is on call: one entry per user, escalation policy and level, with the schedule behind it and the shift start and end |
pagerduty_list_schedules | List on-call schedules: id, name, description, time zone, the users in them and the escalation policies that use them |
pagerduty_get_schedule | Read one schedule with its final rotation for a time window: who is on call from when to when, after overrides |
pagerduty_list_users | List users: id, name, email, role, job title, time zone and teams |
pagerduty_get_user | Read one user: name, email, role, job title, time zone, teams and the type of each contact method (email, phone, push) without the addresses |
pagerduty_list_teams | List teams: id, name and description |
pagerduty_list_priorities | List the incident priorities of the account in order (for example P1 to P5): id, name and description |
pagerduty_get_incident_analytics | Analytics per incident: seconds to first acknowledgement, to engage, to mobilise and to resolve, escalations, reassignments, interruptions… |
pagerduty_get_incident_metrics | Aggregated incident metrics for a period: incident count, mean and percentile times to acknowledge and resolve, escalations, interruptions… |
Beispiel-Prompts
- „Welche PagerDuty-Incidents sind gerade offen? Sortiere sie nach Dringlichkeit und zeig mir, wem jeder zugewiesen ist.“
- „Wer hat gerade Bereitschaft für die Checkout-API, und wer kommt laut Eskalationsrichtlinie als Nächstes?“
- „Quittiere Incident #4821 und füge eine Notiz hinzu, dass ich mir das Datenbank-Failover ansehe. Zeig mir beides vorher und frag mich, bevor du etwas änderst.“
- „Weise den offenen Incident zum Payment-Gateway Jonas Weber zu. Nenn mir Incident und Person, bevor du es tust.“
- „Wie haben sich die mittlere Zeit bis zur Quittierung und bis zur Lösung im letzten Monat pro Woche für das Platform-Team entwickelt?“
Nächste Schritte
War dieser Guide hilfreich?
