devops-status-mcp-server

---

概要

53 社のベンダー（AWS、Google Cloud、Azure、Slack など）のステータスページを、統一された形式で確認できます。障害が発生しているサービスの確認、インシデントのタイムラインの取得、スタックの監視、インシデント対応プレイブックの取得が可能です。さらに、任意のドメインの TLS 証明書と DNS も確認できます。API キーは不要です。

ツール

ツール	説明
devops_list_vendors	組み込みレジストリのベンダーを一覧表示します。名前またはカテゴリで絞り込むこともできます。スラッグ、表示名、カテゴリ、ステータスページの URL を返します。
devops_status_check	1 つ以上のベンダーの現在の稼働状況を確認します。ベンダーごとのステータス（none／minor／major／critical／maintenance）、機能が低下しているコンポーネント、有効なインシデントの概要を返します。
devops_get_incidents	ベンダーのインシデント履歴（有効、解決済み、または予定されているメンテナンス）を取得します。各更新の本文と影響を受けたコンポーネントを含む、インシデントの全タイムラインを返します。
devops_watch_stack	名前を指定したベンダースタックの稼働状況を確認します。サーバーが呼び出し元を識別できる場合（stdio、または jwt／oauth 認証を使う HTTP）、vendors を一度渡せばリストが保存され、以降の呼び出しで再利用されます。HTTP で MCP_AUTH_MODE=none の場合は保存されないため、呼び出しのたびに vendors が必要です。全体的な稼働状況の概要とベンダーごとの詳細を返します。
devops_check_certs	実際の TLS ハンドシェイクを通じて、1 つ以上のドメインの SSL/TLS 証明書の状態を確認します。有効期限、チェーンの深さ、プロトコルバージョン、暗号スイート、HTTP ポートでの HSTS の有無を報告します。純粋な TypeScript で実装されており、外部 API は使用しません。
devops_check_dns	Google（8.8.8.8）、Cloudflare（1.1.1.1）、Quad9（9.9.9.9）を通じて、1 つ以上のドメインの DNS レコードを解決し、伝播状況を確認します。リゾルバーごとのレイテンシと、リゾルバー間の差異を報告します。純粋な TypeScript で実装されており、外部 API は使用しません。
devops_suggest_action	指示ツールです。ベンダー名と任意のインシデントコンテキストに基づき、状況に合わせたインシデント対応プレイブックと、事前入力済みの後続ツール呼び出しを返します。外部呼び出しは行わず、完全に決定的です。

リソース

リソース	説明
devops-status://vendors/{name}	スラッグで指定したベンダーのレジストリエントリー全体です。ステータスページの URL、カテゴリ、API タイプを含みます。

すべてのリソースデータはツール経由でも取得できます。ツールのみを使うエージェントにも完全に対応しています。

---

機能リファレンス

devops_list_vendors _ツール

• 任意のフリーテキスト query（名前とスラッグ。大文字・小文字は区別しません）と、任意の category：cloud、cdn-edge、dev-platform、data、comms、auth、monitoring、ai
• スラッグ（他のツールに渡す値）、表示名、カテゴリ、ステータスページの URL を返します。該当結果がない場合は、見つからなかった内容を示す notice を含みます
• 組み込みエントリーは 53 件で、その大半は Atlassian Statuspage を利用しています。aws、gcp、azure、azure-devops、gitlab、neon、slack、redis-cloud はネイティブ API アダプターを使用します。レジストリにない Statuspage 互換ページも、他のツールにベース URL を直接渡して利用できます

組み込みベンダーレジストリ：

カテゴリ	ベンダー
cloud	digitalocean, linode, aws, gcp, azure
cdn-edge	cloudflare, akamai
dev-platform	gitlab, github, azure-devops, npm, vercel, netlify, render, fly-io, circleci, travis-ci, snyk, atlassian, figma, launchdarkly
data	mongodb-atlas, planetscale, supabase, neon, redis-cloud, elastic, influxdb, upstash, cloudinary, segment
comms	slack, discord, twilio, sendgrid, mailgun, hubspot, brevo, courier, loops
auth	auth0, clerk, workos
monitoring	datadog, sentry, new-relic, grafana-cloud, honeycomb
ai	openai, anthropic, elevenlabs, pinecone, cohere

---

devops_status_check _ツール

• ベンダーのスラッグ（例：github、aws）または Atlassian Statuspage のベース URL を受け付け、自由に混在させられます。1 回の呼び出しでチェックするのは最大 20 件です。残りは deferred_vendors に返され、再送するよう notice で通知されます。100 件を超えると拒否されます（invalid_arguments）
• mode: "summary"（デフォルト）では、インジケーター、劣化したコンポーネント、進行中のインシデントを返します。mode: "detailed" では、コンポーネントの完全な一覧（component_limit、デフォルトは 50、上限は 500）と予定メンテナンス時間帯も返します。component_filter はコンポーネント名またはグループ名に一致します
• 1 つのベンダーでエラーが発生しても、ほかのベンダーの処理は妨げられません（ベンダーごとの error フィールド）。結果は 60 秒間キャッシュされ（cached: true）、summary は operational／degraded／down／maintenance／unavailable の件数を示します
• nextToolSuggestions は、問題が発生している各ベンダーについて、devops_suggest_action の呼び出しを事前入力して提示します

---

devops_get_incidents _ツール

• filter：all（デフォルト）、active、resolved、または scheduled（メンテナンス時間帯のみ）。ページ分割には limit（デフォルトは 20、最大 50）と offset を指定します
• 更新ごとの本文を時系列順のプレーンテキストで返します。影響を受けたコンポーネント名、解決済みインシデントの継続時間（分）、短縮リンクも含まれます。各インシデントには source が付与され、api またはアーカイブレコードを示す history になります（タイトル、影響、時刻、最終メッセージのみ）
• since と until（YYYY-MM-DD、UTC）で開始日を指定でき、filter: "all" または "resolved" と併用できます。since を指定すると、API の最新 50 件という制限を超えて、Statuspage の履歴アーカイブを最大 24 か月前まで検索します。match は、指定したすべての単語（最大 200 文字）をタイトルまたはコンポーネント名に含むインシデントに絞り込みます
• 応答は各サーフェスにつき 64,000 バイトに制限されます。ページが途中で切り詰められると truncated: true と nextOffset が設定されます。full_updates: true を指定すると、1 件のサイズが上限を超えるインシデントのすべての更新を保持します
• エラー：invalid_since、invalid_until（filter: "active" または "scheduled" の場合、あるいは until が since より前の場合）
• フィルターに該当するデータがないフィードは空を返します：Azure の resolved、AWS、Azure、Azure DevOps、Google Cloud、Slack の scheduled

---

devops_watch_stack _ツール

• vendors（最大 20 件）を 1 回指定すると、スタックが stack_name（1～64 文字。例："production"。複数のスタックを共存させられます）で保存され、後続の呼び出しでは vendors を省略できます。20 件を超えると拒否されます（stack_too_large）。stdio と、MCP_AUTH_MODE=jwt|oauth を設定した HTTP で保存できます。デフォルトの in-memory ストレージでは、保存したスタックは再起動後に保持されません
• MCP_AUTH_MODE=none の HTTP では何も保存されません。vendors を指定した呼び出しは一括チェックを実行し、stack_persisted: false を返します。vendors を指定しない呼び出しは vendors_required で失敗します
• 集計結果の health：all_operational／maintenance／degraded／partial_outage／major_outage／unknown（ベンダーに到達できなかった場合）。component_limit と nextToolSuggestions の動作は devops_status_check と同じです

---

devops_check_certs _ツール

• ホスト名、IP アドレス、host:port、または URL を受け付けます。エントリーにポートが含まれる場合は port（デフォルトは 443）より優先されます。最初の 10 件を検査し、最大 100 件まで受け付けます。残りは deferred_domains に返され、再送するよう通知されます
• 有効期限までの日数（30 日未満は warning、7 日未満は critical）、サブジェクトと SAN、発行者、チェーンの深さ、TLS バージョン（1.0 と 1.1 は安全でないものとしてフラグ付け）、暗号スイート、HTTP ポートでの HSTS を報告します
• status: "critical" では、ホスト名の不一致（hostname_verification_error）と信頼されていないチェーン（authorization_error）を区別します。ドメインごとの失敗は status: "error" としてインラインで返され、理由は error に示されます
• timeout_ms はドメインごとのタイムアウト時間です（最大 15000）

---

devops_check_dns _ツール

• ドメイン名、URL、または host:port を受け付けます。最初の10件のドメインを照会します（最大100件まで受け付けます）。残りは deferred_domains に返されます。IPアドレスには独立した error 行が返されます
• Google（8.8.8.8）、Cloudflare（1.1.1.1）、Quad9（9.9.9.9）に対して、A、AAAA、CNAME、MX、TXT、NS、CAA、SOAを並列で照会します（デフォルトはA、AAAA、MX、TXT）
• リゾルバーごとのレイテンシーと、種類別の不一致を報告します。partial_resolution（一部のリゾルバーから応答がない）は実際の問題です。value_variation（値が異なる）は、エニーキャストまたは地理的な振り分けを行うドメインでは通常の動作です
• カスタムの resolvers にはパブリックIPリテラルを指定します。最初の5件を照会し、残りは deferred_resolvers に返されます。プライベートアドレスおよびループバックアドレスには DEVOPS_STATUS_ALLOW_PRIVATE_TARGETS=true が必要です。timeout_ms はドメインとリゾルバーごとに適用されます（最大10000）

---

devops_suggest_action _ツール

• ベンダーのスラッグまたは表示名を受け取り、カテゴリに合わせたMarkdownの手順書を返します。認識されないベンダーには一般的なガイダンスを返します
• 任意の incident_summary、affected_components、vendor_indicator を指定すると、サブシステムのセクションと、重大度に応じた緊急度が追加されます
• nextToolSuggestions には、後続の呼び出し用の引数が事前入力されます。your_domain が指定されている場合は、証明書とDNSの確認も含まれます。DEVOPS_STATUS_DISABLE_ACTIVE_PROBES=true の場合、ガイダンスでは代わりに手動コマンド（dig、openssl s_client）を使用します

---

devops-status://vendors/{name} _リソース

• ベンダーのスラッグに対応する完全なレジストリエントリーを返します。ステータスページのURL、カテゴリ、APIの種類（statuspage、statusio、slack、aws、gcp、azure、azure-devops、firehydrant）、およびベンダーが共有ページの一部を担当する場合の component_scope_prefix（sendgrid）が含まれます
• 1時間、公開キャッシュされます。同じデータは devops_list_vendors からも取得できます

---

機能

@cyanheads/mcp-ts-core を基盤としています。stdioおよびStreamable HTTPトランスポート、プラグイン可能な認証（none / jwt / oauth）、切り替え可能なストレージ（in-memory、filesystem、Supabase、Cloudflare KV/R2/D1）、および任意でOpenTelemetryトレーシングを利用できる構造化ログに対応しています。

DevOps-status固有の機能：

• APIキーは不要です — すべてのステータスバックエンドは公開APIです。TLSとDNSにはNode.jsの標準ライブラリを使用します
• 8つのカテゴリにわたる53ベンダーの組み込みレジストリを備えています。ネイティブアダプターにより、Status.io、Slack、AWS Health、Google Cloud、Azure、Azure DevOps、FirehydrantをStatuspage形式に正規化します
• ベンダーが作成したテキスト、DNSレコードの値、証明書名はエスケープされ、マークアップではなくデータとして扱われます
• ステータスの読み取り結果は、テナント間で共有される60秒間のインメモリキャッシュに保存されます
• devops_watch_stack は、繰り返しの確認やデプロイ前の一括確認に使う名前付きベンダーリストを保存します
• devops_suggest_action は決定論的に動作し、LLMのサンプリングに依存しません

エージェントに適した出力：

• バッチツールでは、1つのターゲットでの失敗がほかの処理を妨げません。エラーはインラインの error フィールドで返されます
• 各ステータス結果の cached と checked_at に、データの取得時刻が示されます
• 固定のインジケーターおよびステータスの列挙値（none / minor / major / critical / maintenance）により、呼び出し元はデータに応じた分岐を行えます
• nextToolSuggestions には、インシデントのコンテキストに基づいて、後続ツールの引数が事前入力されます

---

はじめに

公開ホストインスタンス

公開インスタンスは https://devops-status.caseyjhand.com/mcp で利用できます。インストールは不要です。任意のMCPクライアントからStreamable HTTP経由で接続してください。

{
  "mcpServers": {
    "devops-status-mcp-server": {
      "type": "streamable-http",
      "url": "https://devops-status.caseyjhand.com/mcp"
    }
  }
}

セルフホスト／ローカル

APIキーは不要です。MCPクライアントの設定ファイルに以下を追加してください。

{
  "mcpServers": {
    "devops-status-mcp-server": {
      "type": "stdio",
      "command": "bunx",
      "args": ["@cyanheads/devops-status-mcp-server@latest"],
      "env": {
        "MCP_TRANSPORT_TYPE": "stdio",
        "MCP_LOG_LEVEL": "info"
      }
    }
  }
}

または、npxを使用します（Bunは不要です）。

{
  "mcpServers": {
    "devops-status-mcp-server": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@cyanheads/devops-status-mcp-server@latest"],
      "env": {
        "MCP_TRANSPORT_TYPE": "stdio",
        "MCP_LOG_LEVEL": "info"
      }
    }
  }
}

または、Dockerを使用します。

{
  "mcpServers": {
    "devops-status-mcp-server": {
      "type": "stdio",
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "MCP_TRANSPORT_TYPE=stdio",
        "ghcr.io/cyanheads/devops-status-mcp-server:latest"
      ]
    }
  }
}

Streamable HTTPを使用する場合は、トランスポートを設定してサーバーを起動します。

MCP_TRANSPORT_TYPE=http MCP_HTTP_PORT=3010 bun run start:http
# Server listens at http://localhost:3010/mcp

前提条件

• Bun v1.4.0 以上（またはNode.js v24以降）。
• APIキーや外部アカウントは不要です。

インストール

1. リポジトリをクローンします：

git clone https://github.com/cyanheads/devops-status-mcp-server.git

2. ディレクトリに移動します：

cd devops-status-mcp-server

3. 依存関係をインストールします：

bun install

4. 環境を設定します：

cp .env.example .env
# edit .env if you want to override defaults

---

設定

API キーは不要です。すべての環境変数は任意です。

変数	説明	デフォルト
DEVOPS_STATUS_CACHE_TTL_MS	すべてのバックエンドにおいて、ベンダーのステータス読み取りに使用するインメモリーキャッシュの TTL（ミリ秒）。	60000
DEVOPS_STATUS_FETCH_TIMEOUT_MS	すべてのバックエンドにおいて、ベンダーのステータス API 呼び出しごとに適用されるタイムアウト（ミリ秒）。	8000
DEVOPS_STATUS_CERT_TIMEOUT_MS	devops_check_certs のデフォルトの timeout_ms（1000～15000）。	5000
DEVOPS_STATUS_DNS_TIMEOUT_MS	devops_check_dns のデフォルトの timeout_ms（1000～10000）。	3000
DEVOPS_STATUS_ALLOW_PRIVATE_TARGETS	true の場合、ユーザー指定の URL とドメインに対する SSRF ガードを無効にします。信頼できるローカルデプロイメントでのみ使用してください。	false
DEVOPS_STATUS_DISABLE_ACTIVE_PROBES	true の場合、devops_check_dns と devops_check_certs を無効にします。複数のユーザーが利用するパブリックインスタンス向けです。	false
MCP_TRANSPORT_TYPE	トランスポート：stdio または http。	stdio
MCP_HTTP_PORT	HTTP サーバーのポート。	3010
MCP_SESSION_MODE	HTTP セッションの処理方式：stateless、stateful、または auto。	stateless
MCP_AUTH_MODE	認証モード：none、jwt、または oauth。	none
MCP_LOG_LEVEL	ログレベル（RFC 5424）。	info
LOGS_DIR	ログファイルのディレクトリ（Node.js のみ）。	<project-root>/logs
OTEL_ENABLED	OpenTelemetry のインストゥルメンテーションを有効にします。	false

無効な DEVOPS_STATUS_* の値があると、該当する変数名を示すエラーとともに起動が停止します。

任意で設定できる値の一覧については、.env.example を参照してください。

---

サーバーの実行

ローカル開発

• ビルドして実行：

  bun run rebuild
  bun run start:stdio
  # or
  bun run start:http
  

• チェックとテストを実行：

  bun run devcheck   # Lint, format, typecheck, security
  bun run test       # Vitest test suite
  bun run lint:mcp   # Validate MCP definitions against spec
  

Docker

docker build -t devops-status-mcp-server .
docker run --rm -p 3010:3010 devops-status-mcp-server

Dockerfile では、デフォルトで HTTP トランスポート、ステートレスセッションモードが設定され、ログは /var/log/devops-status-mcp-server に出力されます。OpenTelemetry のピア依存関係はデフォルトでインストールされます。これらを省略するには、--build-arg OTEL_ENABLED=false を指定してビルドしてください。

---

プロジェクト構成

パス	用途
src/index.ts	createApp() エントリーポイント。ツール、リソースを登録し、サービスを初期化します。
src/config/	サーバー固有の環境変数を Zod で解析、検証します。
src/mcp-server/tools/	ツール定義（*.tool.ts）。
src/mcp-server/resources/	リソース定義（*.resource.ts）。
src/services/cert/	node:tls — TLS ハンドシェイク、X.509 解析、有効期限とプロトコルのフラグ付け、レガシー TLS の再試行、HSTS の読み取り。
src/services/dns/	DNS ワイヤークライアント（node:dgram / node:net）：メッセージのエンコードと境界チェック付きデコード、UDP と TCP による再試行。複数リゾルバーへのファンアウトと伝播の不一致検出。
src/services/statuspage/	Statuspage の公開 API クライアント（src/utils/cached-fetch.ts の共有キャッシュを介して読み取ります）。
src/services/status-adapters/	ネイティブ API アダプター（Status.io、Slack、AWS Health、Google Cloud Service Health、Azure status、Azure DevOps status、Firehydrant）、共有 RSS 抽出機能、api_type によるディスパッチ。Statuspage の形式に正規化します。
src/services/vendor-registry/	src/data/vendor-registry.ts から読み込むインメモリーベンダーレジストリ。
src/data/	静的なベンダーレジストリデータファイル（vendor-registry.ts）。
src/utils/	共有ヘルパー — レスポンスのキャッシュと取得、SSRF ガード、ドメインエントリーの正規化、HTML からテキストへの変換、ベンダーテキストの Markdown エスケープ、入力境界の通知、単語の照合。
tests/	src/ の構成に対応する Vitest テスト。

---

開発ガイド

開発ガイドラインとアーキテクチャ上のルールについては、CLAUDE.md を参照してください。要点は次のとおりです。

• ハンドラーは例外をスローし、フレームワークがキャッチします。ツールのロジック内で try/catch は使用しないでください
• リクエスト単位のログには ctx.log を、テナント単位のストレージには ctx.state を使用してください
• src/mcp-server/*/definitions/index.ts のバレル経由で、新しいツールとリソースを登録してください
• devops_check_certs と devops_check_dns は Node.js の標準ライブラリのみを使用します。これらのパスに外部依存関係を追加しないでください

---

コントリビューション

Issue を歓迎します。提出前にチェックとテストを実行してください。

bun run devcheck
bun run test

---

ライセンス

Apache-2.0 — 詳細については LICENSE を参照してください。