AlertOps

AlertOps MCP サーバー

AlertOps のインシデントアラート／オンコール API（アラート、メッセージトピック、ユーザーとその連絡方法、グループ、設定済みの受信インテグレーション、オンコールスケジュール）を、AI アシスタントと WYRE Conduit ゲートウェイ向けに提供する MCP サーバーです。

認証

AlertOps の REST API（https://api.alertops.com/api/...。公開されている OpenAPI 仕様は api.alertops.com/swagger/v1/swagger.json）は、API キーによるアカウント単位の静的認証を使用します。このキーは Account Settings -> Configurations -> Integrations -> API で生成します。ほとんどの WYRE Conduit サイドカーとは異なり、このキーはベアラートークンやカスタム認証ヘッダーとして送信されません。AlertOps では、GET と POST の両方を含むすべてのリクエストで、APIKey クエリ文字列パラメーターとして送信する必要があります（2026-09-20 に実環境で検証済み。このコネクターが呼び出すすべてのエンドポイントで、無効なキーを指定すると {"reason":"Invalid API Key"} が HTTP 401 として正常に返されます）。このコネクターはカスタムヘッダー経由でリクエストごとにキーを受け取り（OAuth は使用せず、ほかの WYRE Conduit 静的キーサイドカーと同じ形式です）、AlertOps API の呼び出し時に自ら ?APIKey=<key> を付加します。ゲートウェイモードでは X-AlertOps-Api-Key ヘッダー経由でリクエストごとにキーを受け取ります。ローカル／stdio モードでは ALERTOPS_API_KEY から一度だけ読み込みます。HTTP /mcp には X-Gateway-S2S 署名も必要です（下記の HTTP 認証を参照）。HTTP サーバーは、有効な CONDUIT_S2S_SECRET が設定されていないと起動しません。

ここには、意図的に確信度を分けた別個の主張が2つあります。「読み取り専用」という1つの主張にまとめないでください。

• 構造上検証済み（直接確認済み。確信を持って述べています）： このコネクターのコードは、書き込みを行う AlertOps エンドポイントを一切呼び出しません。client.ts のすべての関数が、下記の「ツール」に記載された11個の GET 操作のいずれかを呼び出します。src/ に POST 呼び出しは存在しません。
• ベンダーのドキュメントに記載（独自には未検証。意図的に断定を避けています）： AlertOps は、個別に付与できる読み取り専用の権限（例：Messages_View_GlobalAccess、User_View_GlobalAccess、Groups_View_GlobalAccess）を組み合わせて組み立てる、組み込みロールとカスタムロールを備えたロールベースのアクセス制御を提供しています。AlertOps のドキュメントでは、この方法で作成したカスタムロールにより、ユーザーは「インシデント、レポート、ユーザー、グループを閲覧できるが、作成、変更、削除はできない」と説明されています（help.alertops.com、Role Based Access Control）。ユーザー自身のプロフィールページに表示される、別個のユーザー API キーについては、AlertOps の別のドキュメントで UserAPIKey_Add 権限が必要と説明されており、この方法で発行された API キーは、発行したユーザーのロール／権限を継承することが示唆されています。ただし、これが、このコネクターが使用する APIKey クエリパラメーターや特定の書き込みエンドポイントに対して、サーバー側で実際に強制されるかどうか、つまり読み取り専用の範囲で権限を設定されたユーザーのキーを使った書き込み呼び出し（アラートの作成、アラートのクローズ、割り当てなど）を AlertOps のバックエンドが拒否するのか、それともその制限が AlertOps の独自 UI でのみ表示されるのかについては、WYRE はテストしていません。 実際のオンコール担当者に本物のページ通知を送ったり通知を発生させたりするリスクがあり、同意なしに実施すべきではないため、誰も実際のキーで書き込み呼び出しを送って確認していません。このコネクター、またはこの README を、読み取り専用で発行された AlertOps API キーでは技術的に書き込みができないことを実証したものとして解釈しないでください。 実証しているのは、このコネクターのコードが書き込みを試みないことと、AlertOps が文書化しているロールシステムでそのようなキーを発行できることだけです。

設定

.env.example をコピーします。このファイル内の CONDUIT_S2S_SECRET は空のままにしてください。

環境変数	説明
ALERTOPS_API_KEY	Account Settings -> Configurations -> Integrations -> API で発行される API キーです。stdio と、AUTH_MODE=env の場合の HTTP で使用されます。
MCP_TRANSPORT	stdio（デフォルト）または http です。
AUTH_MODE	env（ローカル環境でのデフォルト。ALERTOPS_API_KEY を読み込みます）または gateway（Docker イメージと Compose でのデフォルト）です。Gateway モードでは、各 /mcp リクエストに X-AlertOps-Api-Key が必要です。
CONDUIT_S2S_SECRET	HTTP トランスポートの起動に必要です。空の値や既知のプレースホルダー（changeme、replace-with-a-real-secret、your-s2s-secret など）は拒否されます。プロセスはエラーをログに記録し、ゼロ以外の終了コードで終了します。この値がログに記録されることはありません。これが設定されていない場合、Compose は起動しません。
MCP_ALLOW_INSECURE_DEV	ローカル開発の場合に限り、CONDUIT_S2S_SECRET が空でも HTTP を起動するには、値を正確に 1 に設定します。警告がログに記録され、X-Gateway-S2S のチェックがスキップされ、127.0.0.1 のみでリッスンします。このモードでは、ループバック以外の MCP_HTTP_HOST は無視されます。既知のプレースホルダーシークレットは引き続き拒否されます。
MCP_HTTP_HOST	HTTP のバインドアドレスです。未設定の場合は 127.0.0.1 がデフォルトです。CONDUIT_S2S_SECRET が設定されている場合、この値が適用されます（コンテナーイメージでは 0.0.0.0 が設定されています）。
MCP_HTTP_PORT	HTTP ポートです。デフォルトは 8080 です。
LOG_LEVEL	debug | info（デフォルト）| warn | error です。

/health は認証不要のままで、認証情報を読み込みません。stdio トランスポートでは CONDUIT_S2S_SECRET を使用しません。

HTTP 認証

MCP_TRANSPORT=http かつ CONDUIT_S2S_SECRET が設定されている場合、すべての /mcp リクエストに X-Gateway-S2S を含める必要があります。その値は次のとおりです。

t=<unix seconds>,v1=<hex hmac-sha256>

v1 は、ASCII メッセージ t=<unix seconds>（ヘッダーに記載される同じ t= プレフィックス）に対する HMAC-SHA256 で、CONDUIT_S2S_SECRET をキーとして使用し、64 文字の小文字の 16 進数でエンコードされます。ヘッダーがない場合、または無効な場合は 401 を返します。シークレットがログに記録されることはありません。

AUTH_MODE=gateway の場合、/mcp には X-AlertOps-Api-Key も必要です。このヘッダーがないリクエストには 401 を返します。Gateway モードでは、このヘッダーをリクエストに対する唯一の AlertOps 認証情報として使用します。

リクエスト制限

• HTTP リクエストボディの上限は 256 KiB（262144 バイト）です。X-Gateway-S2S のチェックに合格した後、Content-Length が上限を超えている場合は、JSON-RPC エラーとともに 413 を返します。Content-Length がないボディには、MCP SDK トランスポートによって上限が適用されます。認証されていないリクエストには、先に 401 を返します。
• tools/call の引数の上限は 10,000 要素です（すべての配列項目と、あらゆる深さのオブジェクトキーが対象です）。上限を超える入力には isError ツール結果を返し、ディスパッチしません。

これらの制限は、CVE-2026-111768 / GHSA-46jr-4wx8-v453（検証中のメモリ枯渇）および GHSA-f897-62hf-6gxq（リクエストボディ／バッチ上限の欠如）に対処するものです。

ツール

読み取り専用ツールは 11 個です。AlertOps が公開している REST API 仕様の GET 操作（全 25 操作）の各操作に 1 つずつ対応しています（残り 14 個は POST／書き込み操作のため、意図的に除外しています。詳しくは下記の「範囲」を参照してください）。

アラート

• alertops_list_alerts - アラートを一覧表示します。ステータス／日付範囲／グループ／インテグレーション／エスカレーションで絞り込みでき、ページネーションに対応しています。
• alertops_get_alert_id_by_inbound_message_id - インバウンドインテグレーションの messageID が割り当てられた AlertID を特定します。
• alertops_get_alert_id_by_unique_inbound_id - インバウンドインテグレーションの uniqueInboundID が割り当てられた AlertID を特定します。

ユーザー

• alertops_list_users - ユーザー（ユーザー名、氏名、ユーザータイプ）を一覧表示します。
• alertops_get_user_contact_methods - ユーザーに設定されている連絡方法（メール、電話／SMS）を一覧表示します。連絡先の個人識別情報が含まれます。

グループ

• alertops_list_groups - グループ（グループ ID -> グループ名）を一覧表示します。

トピック

• alertops_list_topics - アラートのルーティング／エスカレーションに使用されるメッセージトピックを一覧表示します。

インテグレーション

• alertops_list_integrations - 設定済みのインバウンドインテグレーション（インテグレーションルール ID -> インテグレーションタイプ）を一覧表示します。

スケジュール

• alertops_get_oncall_now - 現在オンコール中の担当者を、すべてのグループまたは特定のグループについて一覧表示します。
• alertops_get_user_schedule - 指定した期間（最長3か月）におけるユーザーのオンコールスケジュールです。
• alertops_get_group_schedule - 指定した期間（最長3か月）におけるグループのオンコールスケジュールです。

対象範囲

これは意図的に範囲を絞った読み取り専用の v1 機能であり、AlertOps にドキュメント化された25の操作のうち、厳密に11の操作のみを対象としています。 AlertOps は稼働中のインシデントページングシステムです。除外した操作はすべて、状態を変更するか、人に実際のページ通知を送信する可能性があるため、見落としではなく意図的な設計として、ここでは一切実装していません。

明示的に除外（稼働中のアラートを作成または変更し、人にページ通知を送る可能性がある操作）— 実装しません：

• POST /api/alert/Create（Alert_Create）- 新しいアラートを作成し、宛先にページ通知を送信します。
• POST /api/alert/Close（Alert_Close）- 稼働中のアラートを終了します。
• POST /api/alert/Update（Alert_Update）- 稼働中のアラートのフィールドを更新します。
• POST /api/alert/Assign（Alert_Assign）- アラートにユーザーを割り当てます。
• POST /api/alert/Note（Alert_Note）- アラートにメモを追加します。
• POST /api/alert/AddRecipients（Alert_AddRecipients）- アラートに宛先を追加し、追加の人にページ通知を送ります。
• POST /api/alert/Reply（Alert_Reply）- アラートに返信します。

明示的に除外（プロビジョニング／変更 — ユーザー、グループ、スケジュール、インテグレーション）— 実装しません：

• POST /api/user/CreateUser（User_CreateUser）- 新しいユーザーを作成します。
• POST /api/user/CreateOutOfOffice（User_CreateOutOfOffice）- 不在記録を作成し、ページ通知の送信先を変更します。
• POST /api/group/CreateGroup（Group_CreateGroup）- 新しいグループを作成します。
• POST /api/group/AddGroupMember（Group_AddGroupMember）- グループにメンバーを追加し、ページ通知の送信先を変更します。
• POST /api/schedule/CreateFixedSchedule（Schedule_CreateFixedSchedule）- 固定オンコールスケジュールを作成します。
• POST /api/schedule/CreateRecurringSchedule（Schedule_CreateRecurringSchedule）- 繰り返しオンコールスケジュールを作成します。
• POST /api/integration/CreateMaintenanceWindows（Integration_CreateMaintenanceWindows）- アラートを抑制するメンテナンス期間を作成します。

必要であれば、対象範囲を慎重に検討したうえで、後続の対応として追加できます。デフォルトでは追加しません。

開発

npm install
npm run build
npm test
npm run lint   # tsc --noEmit

Docker

イメージはコンテナ内で 0.0.0.0（MCP_HTTP_HOST）をリッスンし、デフォルトで AUTH_MODE=gateway を使用します。ポートをループバックに公開し、生成した S2S シークレットを渡してください。起動時には空の CONDUIT_S2S_SECRET と、既知のプレースホルダー（your-s2s-secret、changeme など）が拒否されます。そのため、以下の各コマンドではシークレットを埋め込まず、openssl rand -hex 32 で値を生成します。ゲートウェイモードでは、AlertOps API キーは各リクエストの X-AlertOps-Api-Key として渡されます。

docker build -t alertops-mcp .
docker run \
  -e CONDUIT_S2S_SECRET="$(openssl rand -hex 32)" \
  -p 127.0.0.1:8080:8080 \
  alertops-mcp

CONDUIT_S2S_SECRET が設定されていない場合、Compose は起動を拒否します。Compose サービスはゲートウェイモードで、ALERTOPS_API_KEY を設定せず、127.0.0.1:8080:8080 を公開します。ゲートウェイがコンテナと同じ値でリクエストに署名する必要がある場合は、シークレットを1つエクスポートしてください。

export CONDUIT_S2S_SECRET="$(openssl rand -hex 32)"
docker compose up

単一テナントの HTTP（AUTH_MODE=env）でも S2S シークレットが必要です。そのうえで、環境変数の ALERTOPS_API_KEY を使用します。コマンドを実行する前に、そのキーをエクスポートしてください。

docker run \
  -e CONDUIT_S2S_SECRET="$(openssl rand -hex 32)" \
  -e AUTH_MODE=env \
  -e ALERTOPS_API_KEY \
  -p 127.0.0.1:8080:8080 \
  alertops-mcp

シークレットを指定しないローカル HTTP は、開発専用です。MCP_HTTP_HOST が 0.0.0.0 でも 127.0.0.1 にバインドし、警告をログに記録します。

MCP_TRANSPORT=http MCP_ALLOW_INSECURE_DEV=1 npm run start:http

ライセンス

Apache-2.0