opsgenie-mcp

Opsgenie（Atlassian のインシデント/アラート管理およびオンコールプラットフォーム）用の MCP サーバー — 公開されている Opsgenie REST API 全体を MCP ツールとして公開します。

⚠️ ベンダー注記: Atlassian は Opsgenie が サポート終了 に近づいていることを発表し、Jira Service Management または Compass への移行を推奨しています。ここに記載されている公開 API（docs.opsgenie.com）はこのビルド時点ではまだ稼働しており変更されていませんが、最終的には非推奨になることが予想されます。

概要

• ステートレスな HTTP サービス。認証情報は一切永続化されません。各リクエストはヘッダーを介して独自の API キーを提供し、その単一リクエストの期間のみ使用されます。

• 同時リクエストをサポート。リクエストごとの認証情報の分離は、グローバル/共有クライアントインスタンスではなく、Python の contextvars を介して行われます。

• エントリポイント: POST /mcp（MCP プロトコル）と GET /health（ヘルスチェック）。

• デフォルトポート: 8080（MCP_HTTP_PORT で設定可能）。

Related MCP server: MCP Setup Server

スコープ

22 ツール。元の 213 ツールのフル API ビルド（2026-08-04）から削減され、すべて単一の alert カテゴリに含まれています。MSPbots がこのベンダー用に保存している統合設定は、正確に 1 つのエンドポイント（GET /v2/alerts、読み取り専用、→ opsgenie_alert_list_alerts）を呼び出します。「実際の使用状況 + 同カテゴリのコア CRUD」というスコープ判断に基づき、他のすべてのカテゴリ（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 カテゴリ、約 178 ツール）は完全に削除されました。MSPbots はそれらに一切触れないためです。alert カテゴリ自体では、35 の元のツールが 22 のコアなアラートライフサイクル操作（list/get/create/close/delete/acknowledge/unacknowledge/note/tags/assign/responder/team/escalate/snooze/update message-description-priority/count/logs/request-status）に削減されました。削除されたのは、保存済み検索サブ機能（5 ツール）、添付ファイルサブ機能（4 ツール）、カスタムプロパティの追加/削除（2 ツール）、execute_custom_action（1）、list_alert_recipients（1）で、いずれもコアなアラート CRUD ではありません。

保持されたツールのソースデータは、元々 docs.opsgenie.com/docs/alert-api を取得し、文書化された各操作（メソッド、パス、パス/クエリパラメータ、JSON ボディフィールド）を機械可読形式に構造化して抽出されました。これは、このプログラムの他の大規模 API ベンダー（ConnectSecure、Dynu、Jira Data Center）で使用されている構造化仕様からのコード生成と同じアプローチであり、Opsgenie にはダウンロード可能な OpenAPI/Postman 仕様がなく、散文のドキュメントしかないため、ここに適用されました。削除されたカテゴリが後で必要になった場合は、同じソースページ（docs.opsgenie.com/docs/*-api）を同じ方法で再解析できます。

認証

Opsgenie は、特定の Opsgenie 統合に紐付けられた静的 API キー を使用します（Opsgenie の Settings → Integrations → API で作成）。MSPbots の統合規約では、このキーを Authorization: GenieKey <apiKey> として送信します。これは Opsgenie 自身の文書化された形式と一致しており、このサーバーはそのまま転送します。

HEADER 認証パラメータ説明

必須ヘッダーが欠落している場合は 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"]
}

環境変数

MCP エンドポイント

• POST /mcp — MCP プロトコル（ストリーミング可能な HTTP トランスポート）

• GET /health — ヘルスチェック。{"status": "ok"} を返します（純粋なローカル liveness プローブであり、Opsgenie を呼び出しません）

ツール一覧

ツール名は opsgenie_<カテゴリ>_<操作> で、公式ドキュメントの各操作の見出しから派生しています（例: alert カテゴリの "List Alerts" → opsgenie_alert_list_alerts）。body パラメータは汎用の dict として受け入れられます。各ツールの正確なフィールドリストは、そのツール自身の docstring（ソースドキュメントから抽出）に記載されており、完全なフィールドスキーマは Opsgenie 自身の API リファレンス（下記リンク）で確認できます。

テスト例

# 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}
    }
  }'

ライブ検証済み (2026-07-30): opsgenie_alert_list_alerts (MSPbots自身が呼び出すのと同じエンドポイント) が、この実行中のサーバーを通じて実際のテストAPIキーでエンドツーエンドに呼び出され、アカウントから実際のアラートデータ (メッセージ、ステータス、優先度、レスポンダー、インテグレーションなど) が返されました。別のカテゴリの2つのツール (opsgenie_team_list_teams、opsgenie_account_get_account_info) も同じキーで呼び出され、Opsgenie自身の 403 API Key is not granted with configuration access が正しく返されました — これは、リクエスト/認証ヘッダーの配管が alert カテゴリの外でも正しく機能することを確認するものです。この特定のテストキーはアラートレベルのアクセスのみにスコープされているだけです (通常のOpsgenieインテグレーションキーの制限であり、バグではありません)。

APIリファレンス

• 概要: https://docs.opsgenie.com/docs/api-overview

• 認証: https://docs.opsgenie.com/docs/authentication

• カテゴリ別のドキュメントは、https://docs.opsgenie.com/docs/alert-api のサイドバーからリンクされています

既知のギャップ

• 2026-08-04に213ツールから22ツールに削減。 当初のビルドは、以前のスコープ決定に基づき、28カテゴリにわたる完全な公開APIをカバーしていました。その後のスコープ決定により、MSPbotsが実際に使用するカテゴリ (alert) とそのコアCRUDのみに削減されました — alert 内で保持/削除された内容の詳細と、削除された27カテゴリ (~178ツール) の完全なリストについては、上記のスコープセクションを参照してください。削除されたカテゴリが後で必要になった場合は、保持されたツールが生成されたのと同じ方法で、同じ docs.opsgenie.com/docs/*-api ページを再解析できます。

• 保持されているツールのいくつかは、実際のOpsgenieアラート状態を変更します (opsgenie_alert_delete_alert、opsgenie_alert_close_alert、opsgenie_alert_create_alert など) — これらは不可逆/状態変更として扱い、呼び出す前に人間に確認してください。

• body パラメータは完全にモデル化されておらず、型指定なし (dict) です — 各ツールのdocstringにはOpsgenieのドキュメントから抽出されたフィールド名がリストされていますが、それらすべてを型指定されたPythonパラメータとして再現することは、機械的に生成されたサーバーのスコープ外でした。

• ソースデータは機械仕様ではなく、散文ドキュメントから抽出されました — Opsgenieにはダウンロード可能なOpenAPI/Postmanコレクションがないため、すべての操作のメソッド/パス/パラメータは docs.opsgenie.com のHTMLから解析されました。

• 実際のデータが返された状態でライブ検証されたのは opsgenie_alert_list_alerts (MSPbots自身のエンドポイント) のみです。残りの21ツールは構造的に正しい (スキーマ検証済み、MCPプロトコルの tools/list 確認済み、すべて compile() に合格) ものの、個別のスモークテストは行われていません — そのうちのいくつかは、実際のアラートを作成、変更、または閉じる書き込み/破壊的操作であるため、ライブテストアカウントに対して実行されませんでした。

• ベンダーはサポート終了に近づいています (このREADMEの上部にある警告バナーを参照) — AtlassianはJira Service ManagementまたはCompassへの移行を推奨しています。このMCPは、このビルド時点でまだ稼働中のOpsgenie公開APIを対象としています。