Opsgenie

MCP server for Opsgenie (Atlassian's incident/alert management and on-call platform) — exposes the full public Opsgenie REST API as MCP tools.

⚠️ Vendor note: Atlassian has announced Opsgenie is reaching end of support and recommends migrating to Jira Service Management or Compass. The public API documented here (docs.opsgenie.com) is still live and unchanged as of this build, but expect it to eventually be deprecated.

Overview

• Stateless HTTP service. No credentials are ever persisted — each request supplies its own API key via a header, used only for the lifetime of that single request.
• Supports concurrent requests; per-request credential isolation is done via Python contextvars, not a global/shared client instance.
• Entry points: POST /mcp (MCP protocol) and GET /health (health check).
• Default port: 8080 (configurable via MCP_HTTP_PORT).

Scope

213 tools across 28 categories, generated from Opsgenie's official documentation at docs.opsgenie.com (Alert, 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).

MSPbots' own stored integration config for this vendor calls exactly 1 endpoint (GET /v2/alerts, read-only). Per explicit user decision, this build covers the full public API including write operations (create/ update/delete/enable/disable across every resource), not just that one read-only call — see Known Gaps for which tools mutate real data.

Source data was extracted by fetching all ~29 docs.opsgenie.com/docs/*-api pages and structuring each documented operation (method, path, path/query params, JSON body fields) into a machine-readable format, then generating all 213 tool functions from that structured data — the same codegen-from-structured-spec approach used for other large-API vendors in this program (ConnectSecure, Dynu, Jira Data Center), adapted here because Opsgenie has no downloadable OpenAPI/Postman spec, only prose documentation.

Authentication

Opsgenie uses a static API key tied to a specific Opsgenie integration (created in Opsgenie's Settings → Integrations → API). MSPbots' own integration convention sends this key as Authorization: GenieKey <apiKey>, matching Opsgenie's own documented format, and this server forwards it exactly that way.

HEADER 授权参数说明

Missing the required header returns 401:

{
  "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"]
}

Environment Variables

MCP Endpoint

• POST /mcp — MCP protocol (streamable HTTP transport)
• GET /health — health check, returns {"status": "ok", "service": "opsgenie-mcp", "transport": "http"}

Tool List

Tool names are opsgenie_<category>_<operation>, derived from each operation's heading in the official docs (e.g. "List Alerts" in the alert category → opsgenie_alert_list_alerts). body parameters are accepted as a generic dict — the exact field list for each is documented in that tool's own docstring (extracted from the source docs), and the full field schema is available in Opsgenie's own API reference (linked below).

测试示例

# 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-verified (2026-07-30): opsgenie_alert_list_alerts (the same endpoint MSPbots itself calls) was called end-to-end through this running server with a real test API key and returned real alert data (message, status, priority, responders, integration, etc.) from the account. Two other tools in different categories (opsgenie_team_list_teams, opsgenie_account_get_account_info) were also called with the same key and correctly returned Opsgenie's own 403 API Key is not granted with configuration access — confirming the request/auth-header plumbing works correctly outside the alert category too; this specific test key is just scoped to alert-level access only (a normal Opsgenie integration-key restriction, not a bug).

API Reference

• Overview: https://docs.opsgenie.com/docs/api-overview
• Authentication: https://docs.opsgenie.com/docs/authentication
• Per-category docs are linked from the sidebar at https://docs.opsgenie.com/docs/alert-api

Known Gaps

• Full API coverage was an explicit user decision, matching the pattern used for other large public APIs in this program (ConnectSecure, Cove Data Protection, Dynu, Jira Data Center). MSPbots itself only calls 1 endpoint (GET /v2/alerts); everything else — including destructive operations like opsgenie_team_delete_team, opsgenie_schedule_delete_schedule, opsgenie_integration_delete_integration, opsgenie_user_delete_user, and any close/delete/disable tool — mutates real Opsgenie configuration or alert/incident state. Treat these as destructive/irreversible and confirm with a human before invoking.
• body parameters are untyped (dict) rather than fully modeled — each tool's docstring lists the field names extracted from Opsgenie's docs, but reproducing all of them as typed Python parameters was out of scope for a 213-tool generation across 28 categories.
• Source data was extracted from prose documentation, not a machine spec — Opsgenie has no downloadable OpenAPI/Postman collection, so every operation's method/path/params was parsed from docs.opsgenie.com's HTML by multiple independent research passes (cross-checked against the actual page text, not summarized). A few pages intermittently served a Cloudflare bot-check to browser-based fetches; those categories were extracted via the plain HTTP fetch path instead.
• Only opsgenie_alert_list_alerts (MSPbots' own endpoint) was live-verified with real data returned; opsgenie_team_list_teams and opsgenie_account_get_account_info were verified to reach the real API and return a correctly-parsed error (the test key's permission scope, not a code issue). The remaining 210 tools are structurally correct (schema validated, MCP-protocol tools/list confirmed, all 213 pass compile()) but not individually smoke-tested — most are write/destructive operations that would create, modify, or delete real teams, schedules, escalations, integrations, or alerts, so they weren't exercised against the live test account.
• Vendor is reaching end-of-support (see the warning banner at the top of this README) — Atlassian recommends migrating to Jira Service Management or Compass. This MCP targets the still-live Opsgenie public API as of this build.