observability-mcp

npx @thotischner/observability-mcp                                    # start (UI on :3000)
claude mcp add observability --transport http http://localhost:3000/mcp   # wire into Claude

12 個の読み取り専用ツール（すべてに readOnlyHint: true を設定） · サーバー側でフィルタリング／集計するため、 エージェントが得るのは 大量のデータではなく数値です · エージェント向けガイド

---

📖 ドキュメントサイト全文： https://thotischner.github.io/observability-mcp/

🔌 MCP Inspector で開く — 1 行で使えるインタラクティブなエクスプローラー：

npx --yes @modelcontextprotocol/inspector \
  --config <(npx --yes @thotischner/observability-mcp inspector-config)

重要な理由 — 主張ではなく、測定結果です

実際の Kubernetes プラットフォームチームからの質問（「ノードがダウンした場合に何が影響を受けるか把握するため、payment-service と同じノードを共有しているほかの Pod はどれですか？」）に対して、同じローカルモデルでも、渡すツールによって回答は大きく異なります。

エージェントが利用できるツール（llama3.1:8b、n=10）	名前空間をまたぐ影響範囲の正確性
汎用のメトリクス、ログ、サービスのツール	0 / 10  — 誤ったエンティティタイプ（prometheus、loki、kubernetes）を幻覚します
同じモデル + get_topology + get_blast_radius	10 / 10  — すべての試行で、同じノードを共有する対象の正確な一覧を返します

両方の条件の生の JSON に加え、さらに3つのシナリオ（単一サービスの RCA、同一名前空間内の影響範囲、トポロジーが役立たないシナリオ）を、docs/benchmark-astronomy-shop.mdで確認できます。ハーネスはscripts/benchmark-rca.mjsにあります。make benchmark-up && make benchmark-runで再実行できます。

万能な高速化を主張しているわけではありません。このドキュメントでは、トポロジーツールが役立つ場面（グラフ構造の質問）と、役立たない場面（単一メトリクスだけを掘り下げる場合）を具体的に説明しています。

---

10秒で試す

npx @thotischner/observability-mcp
# then open http://localhost:3000

CLI 呼び出しを1回実行して、Claude Code に接続します。

claude mcp add observability --transport http http://localhost:3000/mcp

…または、リポジトリに.mcp.jsonとしてコミットします（Claude Desktop / Cursor でも同様に動作します）。

{
  "mcpServers": {
    "observability": {
      "transport": { "type": "http", "url": "http://localhost:3000/mcp" }
    }
  }
}

サーバーはソースなしで起動します。Web UI またはPROMETHEUS_URL / LOKI_URL環境変数を使って、Prometheus / Loki を追加してください。

上記のスニペットを、カスタムホストやカスタムポートへの置き換えも含めて Make ターゲットから出力したい場合は、make connect-claude-codeまたはmake connect-cursorを使ってください。make doctorは稼働中のサーバーと実際の MCP ハンドシェイクを行い、現在のガバナンス状況（認証モード、秘匿化、監査ログの永続化、ID ごとのレート上限）を報告します。また、問題がある場合は修正方法を提示します。

複数ユーザーでの利用や本番環境での利用をお考えですか？ オプトイン方式のベーシックモードのログイン + RBAC + 監査ログ + ID ごとのレート制限の設定については、docs/access-control.mdを参照してください。すべてデフォルトではオフのため、上記のデモに変更はありません。

OIDC 経由の SSO をお使いですか？ make demo-oidcを実行すると、Keycloak と、OIDC 対応の mcp-server がポート3001で起動し、3人のユーザー（admin / operator / viewer、パスワードはユーザー名と同じ。本番利用禁止）が事前に設定されます。本番環境での Keycloak / Authentik / Auth0 / Azure AD の設定については、docs/auth-oidc.mdを参照してください。

OPA による外部 RBAC をお使いですか？ make demo-opaを実行すると、Open Policy Agent と、サンプルの Rego ポリシーを使う OPA 対応 mcp-server がポート3002で起動します。組み込み / ファイル / OPA バックエンドのトレードオフと移行方法については、docs/policy-engines.mdを参照してください。

厳選された MCP 製品をお使いですか？ OMCP_PRODUCTS_FILEに YAML カタログ（config/products.yaml.example）を指定し、「すべてを常に」ではなく、テナントごと / エージェントごとのツールバンドルを提供してください。RBAC で制御され、監査され、稼働中に編集できます。詳しくはdocs/products.mdを参照してください。

完全なカオスエンジニアリングのデモ（Prometheus + Loki + サンプルサービス3つ + 自律型エージェント）を試すには、クローンして実行してください。

make demo   # equivalent to: docker compose --profile demo up --build --wait

または、ソブリンクイックスタートを実行してください。コマンド1つで、完全オンプレミス、外部への呼び出しはゼロです。スタックを起動し、実際のインシデントを発生させ、分析レイヤーがない場合とある場合にエージェントが得られる情報を並べて表示します（生の数値が延々と並ぶ状態と、原因を特定するスコア付きの判定結果）。オプションのエージェントは、ローカルモデル（Ollama）を使って分析します。

make demo-sovereign

正式なワークフローの一覧はmake helpを参照してください。

なぜ？

すべてのオブザーバビリティベンダーが、それぞれ独自の MCP サーバーを提供しています。Prometheus、Grafana、Datadog、Elastic などはそれぞれサイロ化されています。システムをまたいでインシデントをトリアージする AI エージェントは、N 個の個別サーバーを使い分け、それぞれのクエリ言語（PromQL、LogQL など）を習得しなければなりません。統一された抽象化レイヤーはありません。

observability-mcp は、そのレイヤーです。すべてのバックエンドを正規化し、サービス／メトリクス／ログという平易な用語で応答する単一の MCP エンドポイントに加え、エージェントが生のクエリから自力で再構築しなければならない異常を検知する分析エンジンを備えています。

対象ユーザー： Prometheus + Loki を運用し、インシデントのトリアージに AI エージェント（Claude、ローカル LLM など）を利用する SRE／プラットフォームチームです。このゲートウェイの効果が最も大きいのは、エージェントが最先端モデルではない場合です。PromQL／LogQL を確実に自分で記述できない小型モデルやローカルモデルほど、正規化されたツールと事前計算済みの分析から大きな恩恵を受けます。優れた最先端モデルは、生のバックエンドに自力で適切にクエリできます。その場合の価値は、クエリの利便性ではなく、一貫性と分析エンジンにあります。普遍的な高速化をうたうのではなく、この点を正直に示しています。

機能

• 🔍 Inspect — エージェントの動作を可視化し、学習して、制御 — すべての MCP ツール呼び出しを可視化する、サービスメッシュ風のライブグラフ、実際のトラフィックから動作プロファイルを導き出す AppArmor 風の学習ワークフロー、そして承認済みのベースラインから外れた呼び出しをブロックする強制モードを備えています。Inspect へ移動 ↓
• 統合ゲートウェイ — すべてのオブザーバビリティバックエンドに対応する単一の MCP エンドポイントです。
• シグナル横断分析 — メトリクスとログを自動的に相関させます。堅牢な異常検知（中央値／MAD ベースライン、緩やかなランプアップのトレンド検知、フラッピングを抑えるウォームアップ＋継続時間）と、重み付けされたヘルススコアリングを備えています。
• Web UI — ソース、サービス、ヘルスモニタリング、設定に対応しています。リアルタイム表示とダークテーマを備えています。
• prom-client のデフォルト設定 — 標準的な Node.js Prometheus 計装で、そのまま動作します。動的なラベル解決では job／service／app／service_name をプローブするため、サービスのフィルタリングがそのまま機能します。
• Loki ラベルのフォールバック — service_name／service／job／app／container を使ってサービスを検出します。先頭にスラッシュが付いた Docker 配信のストリームにも対応しています。
• プラグイン可能なコネクター — インターフェースは 1 つで、クエリ言語は問いません（PromQL、LogQL、Flux、KQL など）。docs/connectors.md を参照してください。
• 認証と TLS — Basic、Bearer、カスタム CA、mTLS に対応しています。docs/auth-and-tls.md を参照してください。
• マルチバックエンド — 同じ種類のインスタンスを複数使用できます。

Inspect — エージェントの動作を確認し、学習して、強制する

エージェント（または CI ボット、あるいは漏えいした認証情報）に、オブザーバビリティバックエンドへのアクセスキーを渡してしまいました。Inspect は、RBAC では答えられない問いに答えます。このアイデンティティの実際の動作と比べて、この呼び出しは正常ですか？

AppArmor の学習ワークフローと、サービスメッシュのトラフィック表示（エージェントのツール呼び出し向けの Kiali をイメージしてください）を取り入れています。

   OFF  ──▶  OBSERVE  ──▶  DRY-RUN (complain)  ──▶  ENFORCE
              │              │                        │
        record calls    compute what WOULD be     block calls that
        only (zero      blocked, but still allow   fall outside the
        risk, default)  — review before enforcing   accepted profile

• Flows — リアルタイムの アイデンティティ → ツール → バックエンド グラフです。エッジの太さは呼び出し量、色は許可／逸脱／ブロックを表します。任意のノードをクリックすると、実際の呼び出し、引数形状の分布を詳しく確認し、観測されたエッジをそのままルールにできます。
• Profile — 学習ループです。「Learn from traffic」 をクリックし、提案されたルール（anonymous → query_logs · service ∈ {payment-service} — N 件の呼び出しから学習）を確認して、それぞれを承認／編集／拒否します。トラフィックを制御するのは、承認されたルールだけです。
• Deviations — プロファイルの範囲外となったすべての呼び出しを確認できます。誰が、どのツールを使い、何が通常と異なっていたかを確認し、ワンクリックでプロファイルに追加するか、異常として確定できます。

プライバシーを設計段階から考慮しています。Inspect が保存するのは引数の形状だけで、生のペイロードは保存しません。また、すべてのデータは最初にゲートウェイのマスキングレイヤーを通過します。外部への呼び出しは一切行わないため、エアギャップ環境での保証は変わりません。

OSS とライセンス対象の違い： observe と dry-run（リアルタイムグラフ、プロファイルの学習、ブロックされるはずだった逸脱の確認）は無料です。アクティブな enforce によるブロックは、ライセンス対象の制御機能です（UI では 🔒 で表示）。可視化は無料で、強制適用はライセンス対象の機能です。設計の詳細： docs/inspect.md。

検出品質

異常検出エンジンは、ラベル付きの合成テストスイートを使ってバックテストされています。このスイートでは、緩やかな悪化（OOM に向かうメモリリーク）、スパイク、段階的な変化、安定したノイズ、一時的な急変、一方向の回復、日周期のパターン、および意図的に判定を難しくした低 SNR の「hard」層を網羅しています。CI のゲートとしてスコアを算出します （backtest.test.ts）。以下の数値は手書きではなく、このスイートから再生成されています。

ケース数	適合率	再現率	F1
64	100.0%	87.5%	93.3%

適合率は 100%（誤報なし）です。再現できなかったケースは、hard 層のノイズフロアを考慮した意図的なものです。このスイートは決定論的で、検出器のリグレッションがあれば CI は失敗します。ローカルで再現するには：

docker run --rm -w /app -v "$(pwd)/mcp-server:/app" node:22-alpine \
  sh -c "npm i --silent && npx tsx --test src/analysis/backtest.test.ts"

スクリーンショット

Inspect — フローグラフ	Inspect — プロファイルの学習

ダッシュボード	サービスの健全性	コネクターハブ

アーキテクチャ

graph TB
    Agent["AI Agent<br/><small>Claude, Ollama, etc.</small>"]

    subgraph MCP ["observability-mcp :3000"]
        Tools["12 MCP Tools"]
        Analysis["Analysis Engine<br/><small>Robust stats, Health Scoring, Correlation</small>"]
        UI["Web UI"]
    end

    subgraph Connectors ["Pluggable Connectors"]
        Prom["Prometheus<br/><small>PromQL — metrics</small>"]
        Loki["Loki<br/><small>LogQL — logs</small>"]
        K8s["Kubernetes<br/><small>watch — topology</small>"]
        Next["Your Backend<br/><small>Any query language</small>"]
    end

    Agent <-->|"MCP<br/>Streamable HTTP"| Tools
    Tools --- Analysis
    Tools --- UI
    MCP --> Prom & Loki & K8s & Next

    style MCP fill:#1a1a2e,stroke:#58a6ff,color:#fff
    style Connectors fill:#0d1117,stroke:#3fb950,color:#fff
    style Agent fill:#58a6ff,stroke:#58a6ff,color:#000
    style Next fill:#0d1117,stroke:#3fb950,color:#8b949e,stroke-dasharray: 5 5

リポジトリの構成

mcp-server/   # the product — server, Web UI, analysis engine, built-in plugins
helm/         # ArtifactHub-grade Helm chart
docs/         # configuration, auth, plugin architecture, airgapped deployment, ...
examples/     # demo material — agent, example services, Prometheus+Loki configs

mcp-server/ がインストール対象です。examples/ 以下はすべて docker compose --profile demo で任意に利用できます。リポジトリでカオス検出をエンドツーエンドでデモするためのもので、本番環境へのデプロイには必要ありません。

インストール

方法	コマンド	おすすめの用途
npm	npx @thotischner/observability-mcp	ローカル開発、Node ツールチェーン、インストール不要
Docker (GHCR)	docker run -p 3000:3000 ghcr.io/thotischner/observability-mcp:latest	本番ホスト、分離環境
Helm	helm repo add observability-mcp https://thotischner.github.io/observability-mcp/ helm install observability-mcp observability-mcp/observability-mcp	Kubernetes
ソースから	git clone … && make demo	サンプルサービスとカオスを含む完全な POC
CLI (omcp)	npm i -g @thotischner/observability-mcp	コネクター、デモスタック、Helm のターミナルからの管理 — CLIを参照

GHCR はマルチアーキテクチャ（amd64 + arm64）に対応しています。利用可能なタグ：latest、main、X.Y.Z、X.Y、X、sha-<commit>。注：semver タグの先頭にある v は取り除かれます。

Helm チャート

このチャートには、Deployment、Service、オプションのIngress/PVC/HPA、NetworkPolicy、ServiceMonitor（Prometheus Operator CRD の有無に応じて自動的に有効化）、helm test 接続プローブ、values.schema.json による検証が含まれています。ArtifactHub 品質のアノテーションも備えています。値の完全なリファレンスについてはhelm/observability-mcp/を、セキュリティを強化した本番環境の例についてはエアギャップ環境へのデプロイガイドを参照してください。

helm repo add observability-mcp https://thotischner.github.io/observability-mcp/
helm repo update
helm install observability-mcp observability-mcp/observability-mcp \
  --set sources.prometheusUrl=http://prometheus.monitoring.svc.cluster.local:9090 \
  --set sources.lokiUrl=http://loki.logging.svc.cluster.local:3100

# docker-compose snippet
services:
  observability-mcp:
    image: ghcr.io/thotischner/observability-mcp:latest
    ports: ["3000:3000"]
    environment:
      PROMETHEUS_URL: http://prometheus:9090
      LOKI_URL: http://loki:3100
    volumes:
      - ./mcp-config:/home/node/.observability-mcp
    restart: unless-stopped

パス、環境変数、${VAR} の置換、sources.yaml の完全なリファレンスなど、設定の詳細についてはdocs/configuration.mdを参照してください。

クイックスタート

オプション A：スタンドアロン（独自のバックエンド）

npx @thotischner/observability-mcp

次に、http://localhost:3000 で Web UI を開き、Sources → + Add Source をクリックして、Prometheus/Loki の URL を指定します。または、UI を使わずに次のようにします。

PROMETHEUS_URL=http://localhost:9090 LOKI_URL=http://localhost:3100 \
  npx @thotischner/observability-mcp

オプション B：Grafana Cloud

Grafana Cloud は Basic Auth を使用します。ユーザー名には数値のインスタンス ID、パスワードには API トークンを指定します。Prometheus と Loki のインスタンス ID は異なります。両方とも Connections → Data sources で確認できます。

# ~/.observability-mcp/sources.yaml
sources:
  - name: grafana-cloud-prom
    type: prometheus
    url: https://prometheus-prod-XX-prod-eu-west-X.grafana.net/api/prom
    enabled: true
    auth:
      type: basic
      username: "${GRAFANA_PROM_USER}"   # numeric instance ID
      password: "${GRAFANA_TOKEN}"
  - name: grafana-cloud-loki
    type: loki
    url: https://logs-prod-XXX.grafana.net
    enabled: true
    auth:
      type: basic
      username: "${GRAFANA_LOKI_USER}"   # different from Prom!
      password: "${GRAFANA_TOKEN}"

GRAFANA_PROM_USER=… GRAFANA_LOKI_USER=… GRAFANA_TOKEN=glc_… \
  npx @thotischner/observability-mcp

オプション C：完全なデモ（サンプルサービスを含む Docker Compose）

git clone https://github.com/ThoTischner/observability-mcp.git
cd observability-mcp
docker compose --profile demo up --build

単一ノードの k3s クラスターを起動し、3 つのサンプルサービスをビルドして、k3s 内の Kubernetes Deployment として実行します。さらに、Prometheus、Loki、Promtail、MCP サーバー、エージェントを docker-compose 側で起動します。http://localhost:3000 を開いてください。

Prometheus がスクレイプし、Loki がログを受信する同じ Deployment が、トポロジーグラフにも表示されます。そのため、エージェントは get_blast_radius を使って、メトリクスやログの異常とその根底にあるホストを関連付けることができます。カオスエンドポイントは引き続き localhost:8080/8081/8082（k3s の NodePort にマッピング）で利用できるため、既存のスクリプトやデモ動画は変更せずに動作します。

--profile demo を指定しない場合は mcp-server のみが起動します。Prometheus/Loki を別の場所ですでに実行していて、それらを MCP 経由で公開したい場合に便利です。

オプション D：ベンチマークモード（OpenTelemetry Demo / Astronomy Shop）

実際のマイクロサービスワークロード（約23サービス、ネイティブな OTel 計装）を対象に、信頼性の高い RCA 数値を算出するには：

make benchmark-up         # clones upstream Astronomy Shop, brings up both stacks
make benchmark-run        # runs the harness baseline vs topology, writes JSON
make benchmark-down       # tears down

make benchmark-up は、--profile benchmark で Tempo と OTel コレクターブリッジを追加し、別の compose プロジェクトで上流スタックをオーケストレーションします。これらのネットワークをこちらのネットワークに接続し、Astronomy Shop のサービスがトレースをこちらの Tempo に送信できるようにします。docs/benchmark-astronomy-shop.mdおよびexamples/benchmark/README.mdを参照してください。初回のダウンロードは約4 GBです。

MCP ツール

ツール	シグナル	目的
list_sources	メタ	設定済みバックエンドと接続状態を確認します
list_services	メタ	すべてのバックエンドで監視されているサービスを確認します
query_metrics	メトリクス	事前計算された要約統計付きでメトリクスをクエリします
query_logs	ログ	エラー／警告の件数と上位パターン付きでログをクエリします
get_service_health	統合	メトリクスとログを組み合わせたヘルススコア（0～100）を取得します
detect_anomalies	統合	堅牢な分析（中央値／MAD＋トレンド）によるシグナル横断の異常検知を行います
get_topology	トポロジー	トポロジー対応コネクターごとの統合インフラストラクチャグラフ（リソース＋エッジ）を返します。ソース／種類／スコープで絞り込めます
get_blast_radius	トポロジー	汎用的な RUNS_ON 関係を起点に、「このリソースのホストに障害が発生したら、ほかに何が停止するか」を調べます。Pod→ノード、VM→ハイパーバイザー、コンテナー→ホストに対応します

2 つのトポロジーツールには、トポロジー対応コネクターが必要です。同梱の Kubernetes コネクターが最初のコネクターです。今後のコネクター（vCenter、NetBox など）は、同じ isTopologyProvider インターフェースを介して接続し、標準のトポロジー用語集に基づく kind／relation の値を出力します。

Claude Code での使用

エージェントは不要です。Claude Code に直接接続します。

CLI：

claude mcp add observability --transport http http://localhost:3000/mcp

または、プロジェクトのルートに .mcp.json を配置します（コミットに適しています）：

{
  "mcpServers": {
    "observability": {
      "transport": { "type": "http", "url": "http://localhost:3000/mcp" }
    }
  }
}

その後、Claude に自然言語で質問します。たとえば、デモでカオスを発生させた後（curl -X POST http://localhost:8081/chaos/error-spike）：

「現在、異常はありますか？」

Claude は detect_anomalies を呼び出し、次の異常を検出します。

{
  "anomalies": [
    { "metric": "cpu", "severity": "high", "service": "payment-service",
      "description": "cpu is 3.4σ above baseline (18.36 → 37.31)" },
    { "metric": "request_rate", "severity": "low", "service": "payment-service",
      "description": "request_rate is -1.8σ below baseline (0.08 → 0.04)" }
  ]
}

「payment-service のエラーログを表示してください。」

Claude は query_logs を呼び出します。

{
  "summary": {
    "total": 11, "errorCount": 11,
    "topPatterns": [
      "Request failed: internal error during POST /payments (6x)",
      "Request failed: internal error during POST /refunds (4x)"
    ]
  }
}

Claude はシグナル（CPU スパイク、エラーログの急増、リクエストレートの半減）を関連付け、インシデントを平易な言葉で説明します。PromQL も LogQL も必要ありません。

デモ：カオスエンジニアリング

3 つのマイクロサービスの例がトラフィックを生成し、カオスの注入に対応します。

curl -X POST http://localhost:8081/chaos/high-cpu        # CPU spike
curl -X POST http://localhost:8081/chaos/error-spike     # CPU + latency + errors
curl -X POST http://localhost:8081/chaos/slow-responses  # Latency
curl -X POST http://localhost:8081/chaos/memory-leak     # OOM logs
curl -X POST http://localhost:8081/chaos/reset

エージェント（docs/agent.md）は 30 秒以内に異常を検知し、Ollama が実行中の場合は LLM によるインシデント分析を生成します。

CLI（omcp）

コネクター、デモスタック、Helm のインストールを管理する CLI が、同じ npm パッケージの omcp bin として提供されています。

インストールするか、インストールせずに一時的に実行します。

npm i -g @thotischner/observability-mcp   # puts `omcp` on your PATH
omcp --help

# or, no install:
npx -p @thotischner/observability-mcp omcp doctor

次に、以下を実行します。

omcp doctor                       # check docker / compose / helm / node
omcp demo up                      # full demo stack (auto-picks free host ports)
omcp plugin list                  # browse the connector hub catalog
omcp plugin install [email protected] --trust-root key.pem    # download + verify + extract
omcp plugin verify ./plugins/tempo --trust-root key.pem # offline audit
omcp helm upgrade obs -- -n monitoring --set sources.prometheusUrl=http://prom:9090

プラグインのインストール／検証では、サーバーのフェイルクローズ方式の署名＋整合性チェックを再利用します（オフライン対応。エアギャップ環境では --offline-dir を使用）。追加の helm フラグは、リテラルの -- の後に渡します。

ドキュメント

• 設定 — パス、環境変数、${VAR} の置換、sources.yaml の完全なリファレンス
• 認証と TLS — Basic、Bearer、カスタム CA、mTLS
• 管理プレーンの認証（basic モード） — Web UI と /api/* プレーン向けのオプションのログイン画面と、署名付きセッション Cookie
• ログのマスキング — query_logs の出力で、エージェントに届く前に PII／シークレットのパターンを自動的にマスキングします。OMCP_REDACTION=off で無効化できます
• アクセス制御の概要と運用手順 — RBAC ロール、監査チェーン、ID ごとのレート制限、サービスカタログの強化、よくある「誰が／なぜ」という質問を調査するための運用手順
• Prometheus — デフォルト、ラベルの解決、resolvedSeries、prom-client との互換性
• Loki — ラベルのフォールバック、Docker コンテナのスラッシュ、マネージド Loki
• コネクター — 独自のバックエンドを作成する
• エージェント — Ollama のセットアップ、ループの動作
• トラブルシューティング — よくある落とし穴と解決方法
• セキュリティ — 自動化パイプライン、脆弱性の報告、組み込みの保護機能
• エアギャップ環境へのデプロイ — イメージのミラーリング、プライベートプラグイン、GitOps に適した設定
• トポロジー用語 — トポロジー対応コネクターが出力する標準の kind／relation 契約と、警告のみを行うバリデーター
• RCA ベンチマーク — 再現可能な A/B テスト用ハーネス。名前空間をまたぐ影響範囲に関する質問（llama3.1:8b、n=10）では、ベースラインのツールセットは 0/10 で、誤ったエンティティ型を幻覚します。同じモデルでトポロジーツールを使用すると、決定的に 10/10 を達成します。全体像については、3 つのシナリオの表をご覧ください
• 関連ツールとの比較 — Datadog Bits AI、HolmesGPT、Robusta との比較を出典付きの表で紹介。それぞれの得意分野と、本プロジェクトの位置付け
• ガバナンスのアクセス制御ゲート — 署名付き権限トークンによるオプションの RBAC／カタログ／監査（デフォルトでは無効）
• Connector Hub — バージョン管理され署名されたコネクターを閲覧できます（カタログ：hub/）
• ユースケース — 利用するプロンプトを含む 5 つのシナリオ

エンドポイント

サービス	URL
MCP サーバー（Streamable HTTP）	http://localhost:3000/mcp
Web UI	http://localhost:3000
ヘルス API	http://localhost:3000/api/health

docker-compose のデモでは、Prometheus は :9090、Loki は :3100 で稼働します。3 つのサンプルサービスは、docker-compose 内の k3s で Kubernetes Deployment として実行され、NodePort のマッピング :8080–:8082 を介してホストからアクセスできます。k8s への移行前と URL は同じなので、既存のカオスコマンドも引き続き動作します。

トランスポート： デフォルトでは Streamable HTTP（/mcp）を使用します。stdio ベースのクライアント／カタログ（Claude Desktop、Glama の mcp-proxy など）では、--stdio（または MCP_TRANSPORT=stdio）を指定して実行します。MCP サーバーは stdin／stdout 経由で動作し、すべてのログは stderr に出力されるため、プロトコルストリームはクリーンな状態に保たれます。

技術スタック

TypeScript、Node 22.15+、@modelcontextprotocol/sdk（Streamable HTTP）、Express、Zod、js-yaml、prom-client（サンプルサービス）、Prometheus、Loki、Promtail、Docker Compose、オプションの Ollama。

要件

• スタンドアロン： Node 22.15+（または npx のみ）
• Docker デモ： Docker + Compose、4 GB 以上の RAM（Ollama を使用する場合は 8 GB 以上）
• オプション： エージェントの LLM 分析用にホスト上で Ollama を実行

コントリビューション

1. リポジトリをフォークし、docker-compose up --build を実行します。
2. イシューを選ぶか、アイデアを話し合うために新しく作成します。
3. PR を提出します。すべてのコードは Docker 内で実行されるため、ローカル依存関係は不要です。

アイデア：新しいコネクター（InfluxDB、Elasticsearch、Datadog）、追加の分析アルゴリズム、UI の改善。

ライセンス

Apache License 2.0 — NOTICEもご覧ください。

最後のMITライセンス版までのリリースはMITのまま利用できます。それ以降のリリースはApache-2.0です。コントリビューションにはContributor License Agreementへの同意が必要です。

---