opsgenie-mcp

MCP-Server für Opsgenie (Atlassians Incident-/Alert-Management- und On-Call-Plattform) – stellt die vollständige öffentliche Opsgenie-REST-API als MCP-Tools bereit.

⚠️ Hinweis zum Anbieter: Atlassian hat angekündigt, dass Opsgenie das Ende des Supports erreicht, und empfiehlt die Migration zu Jira Service Management oder Compass. Die hier dokumentierte öffentliche API (docs.opsgenie.com) ist weiterhin live und unverändert zum Zeitpunkt dieses Builds, aber es ist zu erwarten, dass sie schließlich veraltet.

Übersicht

• Zustandsloser HTTP-Dienst. Es werden niemals Anmeldeinformationen gespeichert – jede Anfrage liefert ihren eigenen API-Schlüssel über einen Header, der nur für die Lebensdauer dieser einzelnen Anfrage verwendet wird.

• Unterstützt gleichzeitige Anfragen; die Isolierung der Anmeldeinformationen pro Anfrage erfolgt über Python-contextvars, nicht über eine globale/geteilte Client-Instanz.

• Einstiegspunkte: POST /mcp (MCP-Protokoll) und GET /health (Health-Check).

• Standardport: 8080 (konfigurierbar über MCP_HTTP_PORT).

Related MCP server: MCP Setup Server

Umfang

22 Tools, reduziert von einem ursprünglichen 213-Tool-Voll-API-Build (2026-08-04), alle in der einzigen Kategorie alert. Die eigene gespeicherte Integrationskonfiguration von MSPbots für diesen Anbieter ruft genau 1 Endpunkt auf (GET /v2/alerts, schreibgeschützt, → opsgenie_alert_list_alerts). Gemäß der Scope-Entscheidung „tatsächliche Nutzung + Core-CRUD derselben Kategorie“ wurde jede andere Kategorie (Incident, Incident Timeline, Integration, Heartbeat, Alert & Notification Policy, Policy (Legacy v1), Maintenance, Account, User, Custom User Role, Contact, Notification Rule (+ Step), Team (+ Member/Role/Routing Rule), Schedule (+ Rotation/Override), Escalation, Who Is On Call, Forwarding Rule, Service (+ Incident Rules/Templates), Incident Templates – 27 Kategorien, ~178 Tools) vollständig entfernt, da MSPbots keine davon berührt; innerhalb der Kategorie alert selbst wurden 35 ursprüngliche Tools auf die 22 Kernoperationen des Alert-Lebenszyklus reduziert (list/get/create/close/delete/acknowledge/unacknowledge/note/tags/assign/responder/team/escalate/snooze/update message-description-priority/count/logs/request-status) – entfernt wurden die Unterfunktion gespeicherte Suche (5 Tools), die Anhang-Unterfunktion (4 Tools), benutzerdefinierte Eigenschaften hinzufügen/entfernen (2 Tools), execute_custom_action (1) und list_alert_recipients (1), von denen keines zum Core-Alert-CRUD gehört.

Die Quelldaten für die behaltenen Tools wurden ursprünglich durch Abrufen von docs.opsgenie.com/docs/alert-api extrahiert und jede dokumentierte Operation (Methode, Pfad, Pfad-/Query-Parameter, JSON-Body-Felder) in ein maschinenlesbares Format strukturiert – derselbe Codegen-aus-strukturierter-Spezifikation-Ansatz, der auch für andere große API-Anbieter in diesem Programm verwendet wird (ConnectSecure, Dynu, Jira Data Center), hier angepasst, weil Opsgenie keine herunterladbare OpenAPI/Postman-Spezifikation hat, sondern nur Prosa-Dokumentation. Falls eine entfernte Kategorie später benötigt wird, können dieselben Quellseiten (docs.opsgenie.com/docs/*-api) auf dieselbe Weise neu geparst werden.

Authentifizierung

Opsgenie verwendet einen statischen API-Schlüssel, der an eine bestimmte Opsgenie-Integration gebunden ist (erstellt in Opsgenies Einstellungen → Integrationen → API). Die eigene Integrationskonvention von MSPbots sendet diesen Schlüssel als Authorization: GenieKey <apiKey>, was dem von Opsgenie dokumentierten Format entspricht, und dieser Server leitet ihn genau so weiter.

Header-Autorisierungsparameter

Fehlt der erforderliche Header, wird 401 zurückgegeben:

{
  "error": "Missing credentials",
  "message": "This server requires the X-Opsgenie-Api-Key header",
  "required_headers": ["X-Opsgenie-Api-Key"],
  "optional_headers": ["X-Opsgenie-Base-Url"]
}

Umgebungsvariablen

MCP-Endpunkt

• POST /mcp – MCP-Protokoll (streambarer HTTP-Transport)

• GET /health – Health-Check, gibt {"status": "ok"} zurück (reiner lokaler Liveness-Test, ruft Opsgenie nicht auf)

Tool-Liste

Tool-Namen sind opsgenie_<Kategorie>_<Operation>, abgeleitet von der Überschrift jeder Operation in der offiziellen Dokumentation (z. B. „List Alerts“ in der Kategorie alert → opsgenie_alert_list_alerts). body-Parameter werden als generisches dict akzeptiert – die genaue Feldliste für jedes Tool ist in dessen eigenem Docstring dokumentiert (aus den Quelldokumenten extrahiert), und das vollständige Feldschema ist in der eigenen API-Referenz von Opsgenie verfügbar (unten verlinkt).

Testbeispiel

# Health check
curl -s http://localhost:8080/health

# Call a tool via the MCP protocol (streamable HTTP) — requires an
# initialize handshake first per the MCP spec; abbreviated example below
# shows the tool-call request body only:
curl -s -X POST http://localhost:8080/mcp \
  -H "X-Opsgenie-Api-Key: <your-opsgenie-api-key>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "mcp-session-id: <session-id-from-initialize>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "opsgenie_alert_list_alerts",
      "arguments": {"limit": 5}
    }
  }'

Live-verifiziert (2026-07-30): opsgenie_alert_list_alerts (derselbe Endpunkt, den MSPbots selbst aufruft) wurde Ende-zu-Ende über diesen laufenden Server mit einem echten Test-API-Schlüssel aufgerufen und lieferte echte Alert-Daten (Nachricht, Status, Priorität, Responder, Integration usw.) vom Konto zurück. Zwei weitere Tools aus anderen Kategorien (opsgenie_team_list_teams, opsgenie_account_get_account_info) wurden ebenfalls mit demselben Schlüssel aufgerufen und gaben korrekt Opsgenies eigenen 403 API Key is not granted with configuration access zurück – was bestätigt, dass die Request-/Auth-Header-Verkabelung auch außerhalb der Kategorie alert korrekt funktioniert; dieser spezifische Testschlüssel ist nur auf Alert-Ebene beschränkt (eine normale Opsgenie-Integrationsschlüssel-Einschränkung, kein Fehler).

API-Referenz

• Übersicht: https://docs.opsgenie.com/docs/api-overview

• Authentifizierung: https://docs.opsgenie.com/docs/authentication

• Dokumentation pro Kategorie ist über die Seitenleiste unter https://docs.opsgenie.com/docs/alert-api verlinkt

Bekannte Lücken

• Am 2026-08-04 von 213 auf 22 Tools reduziert. Der ursprüngliche Build deckte die vollständige öffentliche API über 28 Kategorien gemäß einer früheren Scope-Entscheidung ab. Eine spätere Scope-Entscheidung reduzierte dies auf die tatsächlich von MSPbots genutzte Kategorie (alert) plus deren Kern-CRUD – siehe den Scope-Abschnitt oben für genau das, was innerhalb von alert behalten/entfernt wurde, sowie die vollständige Liste der 27 entfernten Kategorien (~178 Tools). Falls eine entfernte Kategorie später benötigt wird, können dieselben docs.opsgenie.com/docs/*-api-Seiten auf dieselbe Weise neu geparst werden, wie die behaltenen Tools generiert wurden.

• Mehrere behaltene Tools verändern weiterhin echten Opsgenie-Alert-Zustand (opsgenie_alert_delete_alert, opsgenie_alert_close_alert, opsgenie_alert_create_alert usw.) – behandeln Sie diese als irreversibel/zustandsändernd und bestätigen Sie vor dem Aufruf mit einem Menschen.

• body-Parameter sind untypisiert (dict) statt vollständig modelliert – die Docstrings jedes Tools listen die aus Opsgenies Dokumentation extrahierten Feldnamen auf, aber die vollständige Reproduktion als typisierte Python-Parameter war für einen mechanisch generierten Server außerhalb des Rahmens.

• Die Quelldaten wurden aus Prosa-Dokumentation extrahiert, nicht aus einer Maschinenspezifikation – Opsgenie hat keine herunterladbare OpenAPI/Postman-Sammlung, daher wurden Methode/Pfad/Parameter jeder Operation aus dem HTML von docs.opsgenie.com geparst.

• Nur opsgenie_alert_list_alerts (MSPbots' eigener Endpunkt) wurde live mit zurückgegebenen echten Daten verifiziert. Die übrigen 21 Tools sind strukturell korrekt (Schema validiert, MCP-Protokoll tools/list bestätigt, alle bestehen compile()), wurden aber nicht einzeln einem Smoke-Test unterzogen – mehrere sind Schreib-/destruktive Operationen, die echte Alerts erstellen, ändern oder schließen würden, daher wurden sie nicht gegen das Live-Testkonto ausgeführt.

• Der Anbieter nähert sich dem Ende des Supports (siehe das Warnbanner oben in dieser README) – Atlassian empfiehlt die Migration zu Jira Service Management oder Compass. Dieses MCP zielt auf die zum Zeitpunkt dieses Builds noch aktive öffentliche Opsgenie-API ab.