PagerDuty MCP サーバー
PagerDuty API機能をLLMに公開するサーバー。このサーバーは、構造化された入出力を用いてプログラム的に使用できるように設計されています。
概要
PagerDuty MCPサーバーは、PagerDuty APIと連携するためのツールセットを提供します。これらのツールは、LLMがインシデント、サービス、チーム、ユーザーなどのPagerDutyリソースに対してさまざまな操作を実行するために使用できるように設計されています。
Related MCP server: Lark MCP Server
インストール
PyPIから
ソースから
要件
Python 3.13以上
PagerDuty APIキー
構成
PagerDuty MCP サーバーでは、環境に PagerDuty API キーを設定する必要があります。
使用法
グースエクステンションとして
スタンドアロンサーバーとして
応答フォーマット
すべての API 応答は一貫した形式に従います。
エラー処理
エラーが発生すると、応答には次の構造のエラー オブジェクトが含まれます。
一般的なエラーのシナリオは次のとおりです。
無効なリソース ID (例: user_id、team_id、service_id)
必要なパラメータが不足しています
無効なパラメータ値
APIリクエストの失敗
応答処理エラー
パラメータ検証
すべてのIDパラメータは有効なPagerDutyリソースIDである必要があります
日付パラメータは有効なISO8601タイムスタンプである必要があります
リストパラメータ(例:
statuses、team_ids)には有効な値が含まれている必要がありますリストパラメータ内の無効な値は無視されます
必須パラメータは
Noneまたは空の文字列にすることはできませんlist_incidentsのstatusesの場合、有効な値はtriggered、acknowledged、resolvedのみです。インシデントの
urgencyについては、highとlowのみが有効値ですlimitパラメータはリスト操作によって返される結果の数を制限するために使用できます。
レート制限とページネーション
サーバーはPagerDutyのレート制限を尊重します
サーバーが自動的にページ区切りを処理します
limitパラメータはリスト操作によって返される結果の数を制御するために使用できます。制限が指定されていない場合、サーバーはデフォルトで最大{pagerduty_mcp_server.utils.RESPONSE_LIMIT}件の結果を返します。
使用例
ユーザーコンテキスト
多くの関数はcurrent_user_contextパラメータ(デフォルトはTrue )を受け付けます。このパラメータは、このコンテキストに基づいて結果を自動的にフィルタリングします。current_user_context がTrueの場合、自動フィルタリングと競合するため、特定のフィルタパラメータは使用current_user_contextません。
すべてのリソース タイプの場合:
user_ids``current_user_context=Trueでは使用できません
インシデントの場合:
team_idsとservice_ids``current_user_context=Trueでは使用できません
サービスの場合:
team_ids``current_user_context=Trueでは使用できません
エスカレーション ポリシーの場合:
team_ids``current_user_context=Trueでは使用できません
オンコールの場合:
user_ids``current_user_context=Trueでは使用できませんschedule_ids特定のスケジュールでフィルタリングするために引き続き使用できます。クエリは、現在のユーザーのチームに関連付けられているすべてのエスカレーション ポリシーのオンコールを表示します。
これは、「現在私のチームでオンコールになっているのは誰ですか?」などの質問に答えるのに役立ちます。
現在のユーザーのIDはフィルターとして使用されないため、オンコール中のチームメンバー全員が表示されます。
発達
テストの実行
ほとんどのテストでは PagerDuty API への実際の接続が必要なので、完全なテスト スイートを実行する前に環境でPAGERDUTY_API_KEYを設定する必要があることに注意してください。
ユニット テストのみ (つまり、環境でPAGERDUTY_API_KEY設定する必要のないテスト) を実行するには:
統合テストのみを実行するには:
パーサー テストのみを実行するには:
特定のサブモジュールに関連するテストのみを実行するには:
MCP Inspector を使用したデバッグサーバー
貢献
リリース
このプロジェクトでは、自動リリースにConventional Commitsを使用しています。コミットメッセージによってバージョンアップが決定されます。
feat:→ マイナーバージョンアップ (1.0.0 → 1.1.0)fix:→ パッチバージョン (1.0.0 → 1.0.1)BREAKING CHANGE:→ メジャーバージョン (1.0.0 → 2.0.0)
CHANGELOG.md、GitHub リリース、PyPI パッケージは自動的に更新されます。
ドキュメント
ツールドキュメント- パラメータ、戻り値の型、サンプルクエリなど、利用可能なツールに関する詳細情報
コンベンション
すべてのAPIレスポンスは、メタデータ、リソースリスト、およびオプションのエラーを含む標準形式に従います。
応答内のリソース名は一貫性を保つために常に複数形になります
単一の項目を返すすべての関数は、1つの要素を持つリストを返します。
エラー応答にはメッセージとコードの両方が含まれます
すべてのタイムスタンプはISO8601形式です
テストには、そのタイプ(ユニット/統合)、テスト対象のリソース(インシデント、チームなど)、解析機能をテストするかどうか(「パーサー」マーカー)を示す pytest マーカーが付けられます。