Depot (depot.dev)

depot-mcp：Depot（depot.dev）向け MCP サーバー

Depot、コンテナのビルドと CI を高速化するサービス向けの、デフォルトで読み取り専用の Model Context Protocol サーバーです。コーディングエージェントに「CI が失敗したのはなぜか」「このビルドが失敗したのはなぜか」という問いに対する Depot 独自の回答と、その回答の根拠となる実行履歴、キャッシュの有効性、レジストリの内容、CI 設定、使用状況データを提供します。

コミュニティプロジェクトです。Depot との提携、Depot による推奨やサポートはありません。 Commons Clause 付き Apache 2.0 ライセンスでソースを公開しています。詳しくはライセンスをご覧ください。

次のものとは別物です： Home Depot、Chromium の depot_tools、Steam のデポ、Perforce のデポ、その他の「デポ」。このサーバーが通信するのは api.depot.dev のみです。

目次

• このプロジェクトの目的
• ステータス
• 前提条件
  • トークンごとにできること
• インストール
• 互換性
• 入手方法
• 設定
• ツール
• 読み取り専用モデルとセキュリティ
• 制限事項
• アーキテクチャ
• トラブルシューティング
• 開発
• コントリビューション
• ロードマップ
• ライセンス

このプロジェクトの目的

Depot はすでに優れたエージェント向けの仕組みを提供していますが、MCP ではありません。Depot が提供するのは Agent Skills です。これは、エージェントに depot CLI の使い方を教える SKILL.md ファイルに加え、文書化された CI API と llms.txt で構成されています。Skills の発表記事では、2 つの制約が挙げられています。スキルが最も効果を発揮するのは SKILL.md の規約を実装したクライアントであり、また「エージェントがスキルを自動的に使用しないことがよくある」という点です。

このサーバーは、そこで残る課題を解決します。

• シェルを使えないエージェント。 スキルを使うには、マシンにログイン済みの depot バイナリが必要ですが、ツール呼び出しには必要ありません。
• SKILL.md を読み込まないクライアント。 MCP はクライアントに依存しません。
• 確実な呼び出し。 説明付きで登録されたツールは、運よく取得されることを期待するのではなく、プロトコルを通じて検出されます。
• 読み取り専用の境界。 スキルでは、エージェントによる depot ci rerun の実行を阻止できません。このサーバーでは実行できないようにしています。詳しくは読み取り専用モデルとセキュリティをご覧ください。

主なツールは、Depot がすでに構築した機能を慎重に薄くラップしたものです。GetFailureDiagnosis はサーバー側で障害を分析し、実行内の失敗を根本原因ごとにまとめて、診断結果、修正案、根拠となる行を返します。結果はコンテキストウィンドウに収まるよう、あらかじめサイズが制限されています。この機能をうまく利用できるようにすることが、このサーバーの主な価値です。

Depot Agent Skills との比較

	Depot Agent Skills	depot-mcp
depot CLI のインストールとログインが必要	はい	いいえ
SKILL.md に対応していないクライアントでも動作	いいえ	はい
呼び出し方法	エージェントがスキルを取得する必要がある	ツールは tools/list に一覧表示される
Depot を変更できる（再実行、キャンセル、リセット）	はい。CLI でできることはすべて可能	デフォルトでは無効。オプトインの書き込みツールは DEPOT_MCP_ALLOW_WRITES で有効化でき、各ツールは最初にドライランを実施。削除には 2 つ目のフラグが必要。リセットは不可
コンテキストウィンドウに収まるよう出力を制限	CLI コマンドによる	すべてのツール
メンテナンス担当	Depot	コミュニティ

2026-09-05 時点で、単独の Depot MCP サーバーは存在しません（公式レジストリ、npm、PyPI のいずれにも、公式・非公式を問わず存在しません）。また、シェルを利用できないエージェントに対する Depot 独自のガイダンスは、CI API を直接呼び出すことです。このサーバーは、その API 呼び出しをエージェント向けに整えたものです。

ステータス

• デフォルトでは読み取り専用です。 DEPOT_MCP_ALLOW_WRITES が未設定の場合、何かを変更できるツールは登録されません。設定すると 10 個の書き込みツールが追加され、どのツールも最初にドライランを実施し、書き込みを行う前に安全でないリクエストを拒否します。対象は、実行またはワークフローのキャンセル、ジョブのキャンセル、失敗したジョブの再試行、単一ジョブの再試行、ワークフローの再実行、ワークフローのディスパッチ（DEPOT_MCP_DISPATCH_ALLOWLIST で任意に制限可能）、CI 変数の設定または削除、プロジェクトの作成、プロジェクトの更新です。詳しくは書き込みツールを参照してください。サンドボックスの停止または強制終了にはベータフラグも必要です。プロジェクトの削除には、さらに DEPOT_MCP_ALLOW_DESTRUCTIVE の設定が必要です。詳しくは破壊的な書き込みを参照してください。リセット、シークレットの書き込み、トークンの発行を行うツールはありません。
• Depot CI はベータ版です。これは Depot 独自のドキュメントに記載されています。CI ツールはここで最も有用なツールであり、仕様変更の影響を受ける可能性も最も高いものです。
• 4 つのベータツールはオプトイン方式です。 DEPOT_MCP_ENABLE_BETA=1 を設定すると、Depot サンドボックス（depot.sandbox.v1）と Depot レジストリ（depot.registry.v1beta1）の読み取り専用ツールが追加されます。これらの API は proto としてのみ公開されており、そのうち 1 つは名前にベータが含まれているため、明示的に有効化しない限りツールは非表示のままです。詳しくはベータ（オプトイン）を参照してください。
• 実際の Depot 組織で検証済みです。 すべての読み取りツール、プロンプト、リソースを、組織、ユーザー、プロジェクトの各トークンを使って実環境で実行しました。すべての書き込みツールを実環境でドライランし、2 つのサンドボックスツールを除くすべての書き込みツールを、2026-09-08 に検証用組織で実際に適用しました（npm run verify:apply）。ディスパッチ、プロジェクトの更新、プロジェクトの削除も含まれます。サンドボックスの停止と強制終了は検証スクリプトの対象ですが、検証用組織に停止できるサンドボックスがなかったため、ドライランのみ実施しています。
• MCP プロトコルのリビジョンは 2025-11-25 です。 このサーバーは 2025-11-25 に対応する @modelcontextprotocol/sdk の 1.x 系を基盤としています。現行仕様のリビジョンは 2026-07-28 で、v2 パッケージ（@modelcontextprotocol/server 2.0.0、2026-07-28 公開）で実装されています。このパッケージも 2025-11-25 のクライアントに対応します。現在のすべてのクライアントは 2025-11-25 をネゴシエートするため、現時点で失われる機能はありません。v2 への移行は、範囲を限定した計画済みの変更です。SDK は 9 つのファイルでインポートされ、トランスポートの接続設定は src/index.ts にあります。

前提条件

• Node.js 20 以降（node --version）。Docker イメージを使う場合、ホストに Node は不要です。
• Depot 組織トークン。 Depot ダッシュボードの「Organization Settings」→「API Tokens」から取得できます。depot login で取得するユーザートークンも使えますが、所属するすべての組織にアクセスできるため、DEPOT_ORG_ID も設定してください。
• プロジェクトトークンは使用できません。 Depot 独自のスコープ表では、Depot CI および API 全体から除外されています。

トークンごとにできること

Depot には 3 種類のトークンがあり、互換性はありません。2026-09-06 に、組織オーナーのユーザートークンも含めて実際に確認済みです。

ツールグループ	組織トークン	ユーザートークン
depot_whoami	はい	はい
Depot CI：depot_diagnose_ci_failure、depot_list_ci_runs、depot_get_ci_run、depot_get_ci_job、depot_get_ci_attempt、depot_list_ci_workflows、depot_get_ci_workflow、depot_wait_for_ci_run、depot_get_ci_logs、depot_get_ci_job_summary、depot_get_ci_metrics、depot_list_ci_artifacts、depot_get_ci_artifact_url、depot_compare_ci_runs	はい	はい
depot_list_ci_secrets、depot_list_ci_variables	はい	管理者とオーナーのみ
depot_list_images	はい	はい
depot_list_projects、depot_get_project、depot_audit_trust_policies、depot_list_project_tokens、depot_list_builds、depot_get_build、depot_diagnose_build、depot_get_usage、depot_list_project_usage、depot_get_cache_summary	はい	いいえ：ユーザーのロールにかかわらず、Depot は 401 Invalid token を返します
ベータ：depot_list_sandboxes、depot_get_sandbox、depot_list_registry_repositories、depot_get_registry_image	はい	未テスト
プロジェクトトークン	何も実行できません

トークンの取得方法を含む、ツールごと、Depot サービスごとの完全な対応表は、docs/tokens.md にあります。depot_whoami は、どの種類のトークンを保持しているか、また動作しないツールを報告します。

このサーバー専用のトークンを作成すると、個別に取り消せます。Depot には読み取り専用のトークンスコープがありません。トークンをどこかに貼り付ける前に、セキュリティのセクションをお読みください。

インストール

以下のすべてのクライアントは、stdio 経由で同じコマンドを実行します。異なるのは、設定ファイルの保存場所と、トークンをファイルに保存せずに済む方法だけです。

Claude Desktop、Cursor、Windsurf、Cline、JetBrains、およびその他ほとんどのクライアントでそのまま使える汎用設定：

{
  "mcpServers": {
    "depot": {
      "command": "npx",
      "args": ["-y", "depot-mcp"],
      "env": {
        "DEPOT_TOKEN": "YOUR_DEPOT_TOKEN"
      }
    }
  }
}

トークンで複数の組織が見える場合は、env に "DEPOT_ORG_ID": "..." を追加してください。すべてのツールには depot_ が付いており、ツール名はリリース間で変わりません。

Claude Code

claude mcp add depot --scope user --env DEPOT_TOKEN=YOUR_DEPOT_TOKEN -- npx -y depot-mcp

または、リポジトリのルートに .mcp.json をコミットすると、チーム全体で利用できます。Claude Code は command、args、env、url、headers 内の ${VAR} と ${VAR:-default} を展開するため、トークンを各開発者のシェル環境に保持し、git には含めずに済みます。.mcp.json.example をコピーしてください：

{
  "mcpServers": {
    "depot": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "depot-mcp"],
      "env": {
        "DEPOT_TOKEN": "${DEPOT_TOKEN}",
        "DEPOT_ORG_ID": "${DEPOT_ORG_ID:-}"
      }
    }
  }
}

Claude Code は readOnlyHint にかかわらず、MCP ツールを呼び出すたびに確認を求めます。確認を省略するには、.claude/settings.json で読み取り専用ツールを許可してください："permissions": { "allow": ["mcp__depot__*"] }。

Claude Desktop

方法は 2 つあります。

拡張機能バンドル（ワンクリック）。 リリースページから depot-mcp.mcpb をダウンロードし、Claude Desktop で開いて（または Settings、Extensions、Advanced settings、Install extension の順に選択して）、設定フォームにトークンを貼り付けます。manifest.json ではトークンフィールドが機密情報として指定されているため、Claude Desktop は JSON ファイルではなく OS のキーチェーンに保存します。

手動で JSON を編集。 macOS では ~/Library/Application Support/Claude/claude_desktop_config.json、Windows では %APPDATA%\Claude\claude_desktop_config.json を編集し、上記の汎用設定を追加します。

Cursor

ボタンをクリックするとサーバーの設定が入力されます。Cursor に設定が表示されたら、DEPOT_TOKEN を入力してください。または、~/.cursor/mcp.json（すべてのプロジェクト）か .cursor/mcp.json（1 つのプロジェクト）を編集します。Cursor は command、args、env、url、headers 内の ${env:NAME} を解決するため、コミットしたプロジェクトファイルから環境変数のトークンを読み込めます：

{
  "mcpServers": {
    "depot": {
      "command": "npx",
      "args": ["-y", "depot-mcp"],
      "env": {
        "DEPOT_TOKEN": "${env:DEPOT_TOKEN}"
      }
    }
  }
}

VS Code と GitHub Copilot

ボタンを使うとサーバーが登録され、トークンの入力が一度だけ求められます。トークンは VS Code のシークレットとして保存されます。同等の .vscode/mcp.json（トークンは値ではなく入力項目なので、安全にコミットできます）：

{
  "inputs": [
    {
      "type": "promptString",
      "id": "depot-token",
      "description": "Depot Organization token",
      "password": true
    }
  ],
  "servers": {
    "depot": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "depot-mcp"],
      "env": {
        "DEPOT_TOKEN": "${input:depot-token}"
      }
    }
  }
}

または、ターミナルから実行します：code --add-mcp '{"name":"depot","command":"npx","args":["-y","depot-mcp"],"env":{"DEPOT_TOKEN":"YOUR_DEPOT_TOKEN"}}'。VS Code の Copilot Chat は mcp.json の設定を使用します。ユーザーレベルのファイルには「MCP: Open User Configuration」を使用してください。

GitHub Copilot コーディングエージェント

リポジトリの「Settings」から「Copilot」、「Coding agent」、「MCP configuration」の順に選択します。シークレットは、名前が COPILOT_MCP_ で始まる Copilot 環境シークレットである必要があります：

{
  "mcpServers": {
    "depot": {
      "type": "local",
      "command": "npx",
      "args": ["-y", "depot-mcp"],
      "env": {
        "DEPOT_TOKEN": "$COPILOT_MCP_DEPOT_TOKEN"
      },
      "tools": ["*"]
    }
  }
}

OpenAI Codex CLI

codex mcp add depot --env DEPOT_TOKEN=YOUR_DEPOT_TOKEN -- npx -y depot-mcp

または、~/.codex/config.toml に設定します。env_vars は指定した変数をシェルから引き継ぐため、トークンをファイルに書き込まずに済みます：

[mcp_servers.depot]
command = "npx"
args = ["-y", "depot-mcp"]
env_vars = ["DEPOT_TOKEN", "DEPOT_ORG_ID"]

Gemini CLI

gemini mcp add -e DEPOT_TOKEN=YOUR_DEPOT_TOKEN depot npx -y depot-mcp

または、~/.gemini/settings.json に設定します。Gemini CLI は env 内の $VAR と ${VAR} を展開します：

{
  "mcpServers": {
    "depot": {
      "command": "npx",
      "args": ["-y", "depot-mcp"],
      "env": {
        "DEPOT_TOKEN": "$DEPOT_TOKEN"
      }
    }
  }
}

Windsurf

~/.codeium/windsurf/mcp_config.json、または Windsurf の「Settings」、「Cascade」、「MCP Servers」、「Manage」の順に選択します。上記の汎用設定を使用してください。

Zed

settings.json：

{
  "context_servers": {
    "depot": {
      "command": "npx",
      "args": ["-y", "depot-mcp"],
      "env": {
        "DEPOT_TOKEN": "YOUR_DEPOT_TOKEN"
      }
    }
  }
}

Cline

Cline パネルの「MCP Servers」、「Configure」の順に選択します（CLI の場合は ~/.cline/mcp.json）。汎用設定を使用できます。Cline では、サーバーごとに "disabled": false と "autoApprove": ["depot_whoami", "depot_diagnose_ci_failure"] も設定できます。

JetBrains AI Assistant

「Settings」、「Tools」、「AI Assistant」、「Model Context Protocol (MCP)」、「Add」の順に選択し、汎用設定を JSON として貼り付けます。Claude Desktop をすでに設定している場合は、「Import from Claude」で取り込めます。

Docker

ホストに Node.js は不要です。イメージは stdio を使用するため、-i が必要で、-t は使用できません。コマンドラインではなく、環境からトークンを渡してください：

docker build -t depot-mcp .
export DEPOT_TOKEN=YOUR_DEPOT_TOKEN
docker run -i --rm -e DEPOT_TOKEN -e DEPOT_ORG_ID depot-mcp

イメージ用のクライアント設定：

{
  "mcpServers": {
    "depot": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "DEPOT_TOKEN", "depot-mcp"],
      "env": {
        "DEPOT_TOKEN": "YOUR_DEPOT_TOKEN"
      }
    }
  }
}

ghcr.io/akshayjain3450/depot-mcp の公開イメージと Docker MCP Catalog エントリーを予定しています。詳しくは入手先を参照してください。

クローンから実行する

npm への公開前でも、現時点で動作します：

git clone https://github.com/akshayjain3450/depot-mcp.git
cd depot-mcp
npm install
npm run build

次に、上記の各ブロックの "command": "npx", "args": ["-y", "depot-mcp"] を "command": "node", "args": ["/absolute/path/to/depot-mcp/dist/index.js"] に置き換えます。Claude Code の場合：

claude mcp add depot --env DEPOT_TOKEN=YOUR_DEPOT_TOKEN -- node /absolute/path/to/depot-mcp/dist/index.js

動作確認

npx @modelcontextprotocol/inspector npx -y depot-mcp      # or: node dist/index.js

次に、エージェントから depot_whoami を呼び出すように指示してください。これにより、トークンが有効であることを確認し、アクセス可能な組織とプロジェクトを報告するとともに、Configuration で説明している組織の曖昧さについて警告します。

バイナリは、トークンがなくても次の 2 つのフラグに応答します。

npx depot-mcp --version   # prints the version from package.json
npx depot-mcp --help      # usage, environment variables, exit codes

パッケージをインポートすると（import { createServer } from 'depot-mcp'）、何も起動せずにサーバーファクトリーを利用できます。stdio を開くのは depot-mcp バイナリだけです。

互換性

このサーバーが対応するのは stdio のみです。ローカルプロセスを起動して MCP 2025-11-25 と通信できる（またはそのバージョンにネゴシエートできる）ものなら、どれでも動作します。「テスト済み」とは、メンテナーが実際のトークンを使ってエンドツーエンドで動作を確認したことを意味します。「検証済み」とは、2026-09-05 にベンダーのドキュメントと設定形式を照合したものの、実行はしていないことを意味します。

クライアント	トランスポート	状態	備考
MCP Inspector	stdio	テスト済み	npm run inspect
CI stdio スモークテスト（initialize + tools/list）	stdio	テスト済み	Node 20 および 22 で、すべてのコミット時に実行
Claude Code	stdio	検証済み	.mcp.json 内の ${VAR} 展開。許可リストに登録されていない限り、呼び出しごとに確認を求めます
Claude Desktop	stdio、.mcpb	検証済み	自動承認で readOnlyHint を考慮します
Cursor	stdio	検証済み	${env:VAR}。ワンクリックのディープリンク
VS Code / Copilot Chat	stdio	検証済み	inputs によってトークンをファイル内に記録せずに済みます。ワンクリックリンク
GitHub Copilot coding agent	stdio（type: local）	検証済み	シークレットには COPILOT_MCP_ のプレフィックスが必要です
OpenAI Codex CLI	stdio	検証済み	env_vars でシェルから転送します
Gemini CLI	stdio	検証済み	env 内の $VAR 展開
Windsurf	stdio	検証済み	汎用設定
Zed	stdio	検証済み	context_servers キー
Cline	stdio	検証済み	ツールごとの autoApprove
JetBrains AI Assistant	stdio	検証済み	Claude Desktop の設定をインポートできます
Docker（任意のクライアント）	docker run -i 経由の stdio	検証済み	CI でイメージをビルド。ランタイムは distroless
Streamable HTTP / リモート	提供なし		トークンがマシンの外部に出るためです。Security を参照してください

一覧にない環境で実行する場合は、クライアント名と動作した設定を添えて issue を作成してください。

入手先

有用性の高い順に、配布予定を示します。「保留中」の項目は、先に npm への公開が必要です。

配布先	識別子	状態
npm	depot-mcp	保留中（release.yml は v* タグで provenance 付きの公開を行います）
Official MCP Registry	io.github.akshayjain3450/depot-mcp (server.json)	保留中。npm 公開後に mcp-publisher publish を実行
Claude Desktop 拡張機能	GitHub リリースの depot-mcp.mcpb（manifest.json）	保留中
Docker MCP Catalog	このリポジトリの Dockerfile を指す server.yaml を含む docker/mcp-registry への PR	保留中
GitHub Container Registry	ghcr.io/akshayjain3450/depot-mcp	保留中
Smithery	リスティングのみ。Smithery は 2025 年 9 月にホスト型 stdio サーバーの提供を終了しました。このサーバーは設計上 stdio です	保留中
Glama、PulseMCP、awesome-mcp-servers	ディレクトリのリスティング	保留中

@depot/* や dev.depot/* の名前空間では絶対に探さないでください。これらの名前空間は Depot のものであり、このプロジェクトは Depot のものではありません。

設定

すべての設定は環境変数で、クライアントの設定で指定します。

変数	必須	デフォルト	目的
DEPOT_TOKEN	はい		Depot API トークンです。印字可能な ASCII 文字のみを含む単一行である必要があります。折り返されたターミナルからコピーした改行は、値をエコーせずに起動時に拒否されます。これを指定しないとサーバーは起動せず、終了コード 78 を返します。
DEPOT_ORG_ID	いいえ		x-depot-org として送信されます。トークンから複数の組織が見える場合は設定してください（下記を参照）。
DEPOT_PROJECT_ID	いいえ		コンテナビルドのデフォルトプロジェクトです。これにより、プロジェクトを指定せずにビルドツールを呼び出せます。
DEPOT_API_URL	いいえ	https://api.depot.dev	API エンドポイントを上書きします。https:// である必要があります。スタブに対して実行する場合に限り、localhost では通常の http:// も使用できます。
DEPOT_MCP_MAX_LOG_PAGES	いいえ	20	ツール呼び出しごとに取得するログ／ステップページ数の上限です。1 回の呼び出しでギガバイト単位のログを取得しないようにします。
DEPOT_MCP_OUTPUT_BUDGET	いいえ	24000	1 つのツール結果に対する文字数の上限です。
DEPOT_MCP_ENABLE_BETA	いいえ	0	Depot サンドボックスと Depot レジストリ向けの読み取り専用ベータツールも 4 つ登録します。Depot API が予告なく変更される可能性があるため、デフォルトでは無効です。有効かどうかは depot_whoami で確認できます。
DEPOT_MCP_ALLOW_WRITES	いいえ	0	将来のバージョン用に予約されています。現在は何もしません。 このゲートは、登録方法を作り直さずに後から変更ツールを追加できるように設けられています。v1 では変更ツールを定義していないため、設定しても何も変わりません。その旨は depot_whoami に表示されます。
DEPOT_MCP_ALLOW_WRITES	いいえ	0	1 を設定すると、Depot CI の書き込みツールを 5 つ登録します。設定しない場合、それらは一切登録されず、tools/list に表示されません。すべての書き込み操作はデフォルトで dryRun: true です。登録されている書き込みツールは depot_whoami で確認できます。
DEPOT_MCP_ALLOW_WRITES	いいえ	0	1 を設定すると、書き込みツールを登録します。すべてのツールはデフォルトで dryRun: true です。このフラグを設定していないクライアントには表示されません。書き込みが有効かどうかは、標準エラー出力の起動時メッセージと depot_whoami の両方に表示されます。
DEPOT_MCP_DISPATCH_ALLOWLIST	いいえ		depot_dispatch_ci_workflow が開始できる owner/name:workflow.yml 形式のエントリーを、カンマ区切りで指定します。例：acme/api:deploy.yml,acme/api:nightly.yml。設定すると、該当しないもののディスパッチはリクエスト送信前に拒否されます。未設定の場合、トークンから見えるすべてのリポジトリをディスパッチできます。リポジトリ名は大文字と小文字を区別せず照合され、ワークフローファイル名は完全一致で照合されます。形式が不正なエントリーがあると、サーバーは起動時に停止します。
DEPOT_MCP_ALLOW_DESTRUCTIVE	いいえ	0	1 に設定すると、DEPOT_MCP_ALLOW_WRITES と合わせて、取り消し不能な書き込み操作（depot_delete_project）も登録します。これ単独では何も起こりません。書き込みが無効なサーバーでは、削除は実行できません。各破壊的ツールには、対象を指定する確認用引数も必要です。このゲートが開いているかどうかは、起動時メッセージと depot_whoami に表示されます。

各 Depot API 呼び出しには約 40 秒の全体タイムアウトがあり、unavailable、deadline_exceeded、aborted、および 429 レスポンスに対しては、回数に上限を設けた再試行（指数バックオフ）を行います。invalid_argument、not_found、permission_denied、および failed_precondition は再試行されません。ログのページ取得やビルド診断など、複数の呼び出しを行うツールは、1 回のタイムアウトを超えて実行される場合があります。そのため、後続ページの取得がタイムアウトした場合も、処理全体を失敗させず部分的な結果を返します。

組織に関する注意点

これは Depot で最も混乱しやすい障害の原因であり、Depot 独自の Agent Skill でも指摘されています。ユーザートークンからは、所属するすべての組織が見えます。複数の組織が見える状態で DEPOT_ORG_ID が未設定の場合、リクエストはそのうち 1 つの組織に対して処理され、ほかの組織の情報はエラーではなく空として扱われます。一覧が不自然に空に見える場合は、depot_whoami を呼び出してください。この状況を正確に検出し、設定すべき値を知らせてくれます。

ツール

常時利用できる28個のツールには、すべて depot_ という接頭辞が付き、depot_<verb>_<noun> という名前で、readOnlyHint: true および destructiveHint: false が指定されています。さらに4個の読み取り専用ツールは DEPOT_MCP_ENABLE_BETA の設定後に利用できます（ベータ版を参照）。10個の取り消し可能な書き込みツールは DEPOT_MCP_ALLOW_WRITES の設定後に利用でき（書き込みツールを参照）、2個のサンドボックス書き込みツールはそのフラグとベータ版フラグの両方を設定すると利用できます。さらに、1個の取り消し不可能な書き込みツールは DEPOT_MCP_ALLOW_DESTRUCTIVE を追加で設定すると利用できます（破壊的な書き込みを参照）。書き込みツールには readOnlyHint: false が指定され、destructiveHint と idempotentHint には実態に即した値が設定されています。ツール名は安定しています。名前の変更や削除は破壊的変更となり、変更としてバージョン管理されます。

診断（まずはこちら）

ツール	回答する内容
depot_diagnose_ci_failure	この CI の実行／ワークフロー／ジョブ／試行が失敗した理由は何ですか？ 根本原因を分類し、AI による診断、修正案、根拠となる行を提示します。
depot_diagnose_build	このコンテナのビルドが失敗した理由は何ですか？ 失敗したステップを特定し、そのエラーとログ末尾に加えて、キャッシュの有効性を返します。ステップの出力がページ上限を超えていた場合は、logPageCapHit と logNextPageToken を報告します。
depot_whoami	トークンは有効ですか？ また、どの情報にアクセスできますか？ 上記の組織の曖昧さを診断し、DEPOT_ORG_ID で指定された組織をトークンが参照できない場合は警告します。

Depot CI

ツール	回答できる質問
depot_list_ci_runs	最近実行されたものや、失敗したものはどれですか？ステータス、リポジトリ、SHA、トリガー、PR で絞り込めます。
depot_get_ci_run	この実行のワークフロー、ジョブ、試行のツリーと、失敗したノードを確認できます。
depot_get_ci_job	このジョブは再試行を通じてどのような結果になりましたか？ステータス、結果、記録されたエラー、ランナーのラベル、所要時間、およびサンドボックス ID を含むすべての試行を新しい順に確認できます。
depot_get_ci_attempt	1 回の試行の記録です。ステータス、結果、エラー、サンドボックス ID とセッション ID、所要時間、現在の試行かどうかを確認できます。
depot_list_ci_workflows	最近実行されたワークフローや、失敗したワークフローはどれですか？名前、ステータス、リポジトリ、SHA、トリガー、PR で絞り込めます。ワークフローごとのジョブ数も確認できます。
depot_get_ci_workflow	1 つのワークフローの実行履歴（再実行と再試行）と、そのジョブ → 試行のツリーを確認できます。
depot_wait_for_ci_run	もう完了しましたか？runId に対して GetRunStatus を、または workflowId に対して GetWorkflow をポーリングします（再実行または再試行後に監視する対象です。再実行と再試行では新しい実行が開始されますが、新しい run は作成されません）。最大 timeoutSeconds 秒（デフォルトは 120、最大は 300）ポーリングし、run、ワークフローの最新の実行、または untilJobKey で指定したジョブのいずれかが終端状態になった時点で、結果、経過時間、ポーリング回数、および状態が変化したすべてのノードを報告します。ポーリングは上限付きです。タイムアウトすると timedOut: true が返されるため、エージェントは再度呼び出します。ストリーミングは行いません。
depot_get_ci_logs	試行の範囲指定された生ログを取得します。デフォルトでは末尾を取得し、grep／ステップ／ストリームのフィルターと、正確なカーソルによる前方ページングに対応しています。フィルターは取得後にこのサーバー上で実行されるため、grep でも DEPOT_MCP_MAX_LOG_PAGES ページ分まで読み取ります。ページ上限に達すると、ログが続いていることが結果に示され、pageCapHit と nextPageToken を使って続きを読むことができます。ログの途中を末尾として示すことはありません。行の本文は 2000 文字に制限されます（bodyTruncated）。
depot_get_ci_job_summary	ジョブが自身について公開した内容（$GITHUB_STEP_SUMMARY に相当するもの）を確認できます。
depot_get_ci_metrics	OOM による強制終了でしたか、それとも CPU 不足でしたか？run、ジョブ、または試行の CPU／メモリを確認できます。
depot_list_ci_artifacts	run がアップロードしたものと、その署名付きダウンロード URL を確認できます。pageToken を受け付けます。
depot_get_ci_artifact_url	ID を指定して 1 つのアーティファクトの署名付きダウンロード URL を取得します。URL に有効期限が含まれる場合は、その期限も返します。この URL は有効期間の短いベアラー機能です。結果にもその旨が示され、このツールが URL を取得することはありません。
depot_compare_ci_runs	2 つの run の間で何が変わりましたか？ジョブキーを基準にしたジョブのマトリックスに、A と B のステータス、所要時間とピークメモリの差（GetRunMetrics に基づき、Depot にサンプルがない場合は空欄）、一方の run にのみ存在するジョブ、および B で新たに発生したエラーメッセージと B で解消されたエラーメッセージを表示します（Depot の失敗分析に基づき、失敗した側についてのみ取得します）。2 つのコミット間のリグレッションの調査や、不安定な失敗と再現性のある失敗の判別に使えます。
depot_list_ci_secrets	どの CI シークレットが存在し、どこに適用されますか？名前とスコープのみを表示します。Depot がシークレットの値を返すことはありません。
depot_list_ci_variables	値とスコープを含む、どの CI 変数が存在するかを確認できます。認証情報とみられる値はマスクされます（以下を参照）。

コンテナのビルド、プロジェクト、レジストリ、使用状況

ツール	内容
depot_list_builds	実行時間とキャッシュヒット率を含む、最近のコンテナビルドを確認します。
depot_get_build	1 件のビルドについて、ステータス、所要時間、キャッシュカウンター、ヒット率、および terminal と failure のフラグを確認します。ビルドが失敗した場合は depot_diagnose_build を案内します。実行中のビルドをポーリングする用途にも十分軽量です。
depot_list_projects	どのビルドプロジェクトが存在し、どのリージョン、ハードウェア、キャッシュポリシーが設定されているかを確認します。pageToken を受け付けます。
depot_get_project	1 件のプロジェクトの完全な設定と OIDC 信頼ポリシーを確認します。
depot_audit_trust_policies	どの外部 CI アイデンティティ（GitHub リポジトリ、Buildkite パイプライン、CircleCI、GitLab プロジェクト）が、組織全体のどのプロジェクトにビルドできるかを確認します。projectId を指定すると 1 件のプロジェクトを対象とし、指定しない場合は先頭の 50 件を対象とします。ポリシーがない場合も正常な結果です。
depot_list_project_tokens	プロジェクトにどのプロジェクトトークンがあるかを確認します。ID、説明、Depot が保持する場合はタイムスタンプが含まれます。シークレットは決して表示されません。Depot は作成時に一度だけシークレットを表示し、このサーバーはトークンを作成しません。
depot_list_images	このプロジェクトのレジストリにあるイメージと、そのダイジェスト、サイズを確認します。
depot_get_usage	支出の内訳を確認します。ビルド時間、キャッシュで節約した時間、GitHub Actions ランナーの時間、ストレージ、サンドボックスが含まれます。日付は UTC です。日付のみを指定した endAt は、その日全体を含みます。
depot_list_project_usage	期間内の全プロジェクトについて、ビルド数、ビルド時間、レイヤーキャッシュサイズを確認します。キャッシュサイズの大きい順に並び、名前も解決されます。pageToken を受け付けます。
depot_get_cache_summary	このプロジェクトのキャッシュが機能しているかを確認します。現在のサイズに対する保持ポリシー、最近のビルドのヒット率、節約した時間、および所見（サイズ上限に近い、ヒット率が低い、保持期間よりビルド頻度が低い場合）を表示します。Depot はキャッシュエントリーを一覧表示できず、このサーバーはキャッシュをリセットしません。このツールはその両方を明示します。

ベータ版（オプトイン）

DEPOT_MCP_ENABLE_BETA=1 の場合にのみ登録されます。他のすべての機能と同様に読み取り専用ですが、Depot が proto（depot.sandbox.v1、depot.registry.v1beta1 など、名前に beta が含まれるもの）としてのみ公開している Depot API を使用するため、Depot の変更履歴に記載されないままフィールド名、状態、ページング方法が変更される可能性があります。各ツールの説明にはその旨が記載されています。2026-09-06 に Organization トークンで実際に検証済みです。各 RPC は JSON バインディングに応答しました（試用用組織では空のリストが返され、不明な ID には Depot 固有の not_found が返されました）。

ツール	内容
depot_list_sandboxes	どの Depot サンドボックスが存在し、どの状態、イメージ、リソースを使用しているかを確認します。状態と作成時刻で絞り込み、トークンによるページングができます。環境変数は名前のみ報告されます。
depot_get_sandbox	1 件のサンドボックスについて、ライフサイクルの所要時間、終了コード、エラーメッセージ、計測された CPU とネットワークの使用量、環境変数名を確認します。値は表示されません。
depot_list_registry_repositories	組織のレジストリにあるリポジトリと、そのサイズ、最終プッシュ時刻、保持ポリシーの有無を確認します。番号（page、hasMore）でページングします。
depot_get_registry_image	このリポジトリのタグまたはダイジェストが何を指しているかを確認します。ダイジェスト、サイズ、タグ、プッシュ時刻、および要約されたマニフェスト（マルチプラットフォームインデックスの場合はプラットフォーム、単一イメージの場合はレイヤー数と設定ダイジェスト）が含まれます。

意図的に公開していない機能：サンドボックスの作成、コマンドの実行、タイムアウトの変更、レジストリトークンの一覧表示または作成、あらゆる削除。サンドボックスの停止や強制終了は書き込み操作であるため、depot_stop_sandbox と depot_kill_sandbox は DEPOT_MCP_ALLOW_WRITES も設定されている場合にのみ利用できます。詳しくは書き込みツールをご覧ください。ロードマップに記載された 5 つ目のベータツール depot_list_test_results は depot CLI が必要なため、実装されていません。

書き込みツール（オプトイン）

DEPOT_MCP_ALLOW_WRITES=1 の場合にのみ登録されます。このフラグがなければ、クライアントから見てこれらのツールは存在しません。tools/list に表示されず、呼び出すと不明なツールとして失敗します。depot_whoami は、これらのツールが登録されているかどうかを報告し、名前を表示します。

すべての書き込みツールは同じ方法で動作します。

1. dryRun のデフォルトは true です。 この呼び出しは Depot の読み取り RPC で現在の状態を取得し、変更内容のプレビューと、再送信する正確な引数を返します。
2. ユーザーの確認後、dryRun: false で再送信します。 ツールは状態を再度読み取り、その最新の状態に拒否ルールを適用してから、変更を行う RPC を 1 つだけ呼び出します。Depot 独自の 412 応答は、わかりやすいメッセージに変換されます。

適用された書き込みごとに、標準エラー出力に [depot-mcp write] <tool> <ids> <time> という 1 行が記録されるため、オペレーターはエージェントが何を変更したかを確認できます。トークンは記録されません。

ツール	Depot RPC	拒否する条件
depot_cancel_ci_run	CancelRun、または workflowId が指定されている場合は CancelWorkflow	すでに終了状態の実行またはワークフロー。指定した実行に属さない workflowId
depot_cancel_ci_job	CancelJob	すでに終了状態のジョブ。指定した runId に属さないジョブ
depot_retry_ci_failed_jobs	RetryFailedJobs	まだ実行中のワークフロー。失敗またはキャンセルされたジョブがないワークフロー。複数のワークフローがある runId（workflowId を指定してください）。force: true でない場合、試行回数が 3 回以上の失敗ジョブ
depot_retry_ci_job	RetryJob	失敗またはキャンセルされた状態ではないジョブ。force: true でない場合、試行回数が 3 回以上のジョブ
depot_rerun_ci_workflow	RerunWorkflow	まだ実行中のワークフロー。失敗したジョブがあるワークフロー（失敗したジョブだけを再試行するほうが低コストです）
depot_dispatch_ci_workflow	DispatchWorkflow	DEPOT_MCP_DISPATCH_ALLOWLIST が設定されている場合、そのリストにないリポジトリとワークフローファイル。owner/name 形式ではない repo。ファイル名ではなくパスである workflow。空の ref。inputs が 20 個を超える場合、または値が 1000 文字を超える場合。プレビューには、そのワークフローの最後の実行が表示され、新しい実行によってデプロイが行われたり、実行時間が消費されたりする可能性があることが明記されます
depot_set_ci_variable	SetVariableVariant	マスキングルールで認証情報と判定される値（Depot のシークレットを使用してください）。すでにシークレットに属している名前
depot_delete_ci_variable	DeleteVariableVariant、または allVariants: true の場合は DeleteVariable	0 個または複数のバリアントに一致するセレクター。allVariants を指定しない変数全体の削除
depot_create_project	CreateProject	allowDuplicateName: true でない場合、重複するプロジェクト名。us-east-1 または eu-central-1 以外のリージョン
depot_update_project	UpdateProject	何も変更しない呼び出し（すべての値が現在の値と同じ）。プロジェクト固有のものではない regionId（Depot ではプロジェクトを移動できません）。1 未満の cacheKeepGb または cacheKeepDays。プレビューには差分が表示され、キャッシュ縮小時（エビクション）とハードウェア変更時（コスト）の警告が含まれます。また、Depot は省略された値を 0 として読み取るため、両方のキャッシュ値が送信されます
depot_stop_sandbox（DEPOT_MCP_ENABLE_BETA も必要）	StopSandbox、ベータ版 depot.sandbox.v1	すでに終了、キャンセル、または失敗しているサンドボックス。同じケースに対する Depot 独自の 412 は変換されます
depot_kill_sandbox（DEPOT_MCP_ENABLE_BETA も必要）	KillSandbox、ベータ版 depot.sandbox.v1	stop と同じ条件。kill は強制版で、サンドボックスの状態は cancelled になります

アノテーション：12 個すべてに readOnlyHint: false。キャンセル、変数の削除、サンドボックスの kill には destructiveHint: true。新しい試行、実行、プロジェクトを作成する再試行、再実行、ディスパッチ、プロジェクト作成には idempotentHint: false。 ライブ環境で検証済みの内容。 すべての書き込みツールについて、実際の Depot 組織でドライランを実行し、プレビュー経路、その依存先となる読み取り RPC、およびすべての拒否ルールを確認済みです。サンドボックスの停止と強制終了を除くすべての書き込みで適用経路も実行済みです。試用組織には実行対象となるサンドボックスがありませんでした。この検証は npm run verify:apply で行われ、記録は docs/verification/apply-0.2.1.md にあります。CI の書き込みに使うリクエストフィールド名は Depot がドキュメント化しています。変数とプロジェクトの書き込みに使うフィールド名は、Depot のオープンソース CLI にベンダー同梱されている v3beta2 バインディングと depot/proto に由来するため、それぞれ初回の実適用を検証ステップとして扱ってください。

破壊的な書き込み（第 2 のゲート）

元に戻せない書き込みもあり、ドライランをしても、誤った対象を削除した場合には復旧できません。こうした書き込みは第 2 のフラグ DEPOT_MCP_ALLOW_DESTRUCTIVE で保護されており、DEPOT_MCP_ALLOW_WRITES も設定されている場合にのみ有効です。書き込みが有効で、第 2 のフラグが無効の場合、tools/list には表示されず、depot_whoami は破壊的操作のゲートが無効だと示します。また、各操作には破壊対象の名前を指定する確認引数も必要です。この値は一覧からコピーするのではなく、ユーザーが入力します。

ツール	Depot RPC	確認	拒否条件
depot_delete_project	DeleteProject	confirmProjectName はプロジェクトの現在の名前と完全に一致する必要があります	変更呼び出しを行う前に、名前が一致しない場合は拒否します。また、過去 24 時間以内にビルドが実行されているプロジェクトは、force: true でない限り拒否します。プレビューにはプロジェクト、ビルド数、最後に実行された日時が表示されるため、削除対象を確認できます

アノテーション：destructiveHint: true、idempotentHint: true。削除されるもの：プロジェクト、そのレイヤーキャッシュ、ビルド履歴、レジストリイメージ、信頼ポリシー、プロジェクトトークン。

プロンプト

7 つのプロンプトでツールをワークフローにつなぎ、エージェントが本来なら手順を一つずつ考えなければならない作業を実行できます。引数はそれぞれの種類に含められる文字だけに制限され（リポジトリは owner/name、ID は英字、数字、.、_、-）、補間前に JSON 形式で引用されるため、悪意のある引数で指示を書き換えることはできません。

プロンプト	引数	内容
diagnose-latest-failure	repo?	最後に失敗した実行を見つけて診断し、修正案を提示します。
explain-build-slowness	projectId?	ビルドと使用状況から、キャッシュミスか作業量の増加かを判定します。
triage-failures-today	repo?、hours?（デフォルトは 24）	指定期間内の失敗およびキャンセルされた実行を一覧表示し、リポジトリ、ワークフロー、失敗したジョブごとに分類します。最大 5 件の異なるグループを診断し、各グループが再発か新規かを示す表を作成して、安全に再試行できそうなものを伝えます。エージェントに再試行を求めることはありません。このサーバーでは再試行できないためです。
compare-ci-runs	runA、runB	両方の実行ツリーとメトリクス、および失敗した側の診断を提示します。ステータスの差分、ジョブごとの所要時間とピークメモリの差分、一方の実行にのみ存在する失敗グループを報告します。
cache-audit	projectId?	キャッシュポリシーを含むプロジェクト一覧、それぞれの直近 20 件のビルド、および 30 日分の使用状況を提示します。ヒット率が 50% 未満の場合、コールドビルド、保持期間が短い場合にフラグを付けます。プロジェクトのキャッシュリセットは提供していないことを明記します。
debug-missing-secret	name、repo、branch?、workflow?	スコープフィルターを指定して depot_list_ci_secrets と depot_list_ci_variables を実行し、ジョブに一致するバリアントと、ジョブから参照できない可能性のある理由を説明します。
watch-run	runId	実行が完了するまで depot_get_ci_run をポーリングします（最大 20 回）。失敗した場合は診断し、成功した場合は成果物を一覧表示します。

リソース

4 つの読み取り専用リソースは、ツール呼び出しではなく @ メンションやリソースピッカーでコンテキストを添付するクライアント向けに、URI を通じて同じデータを公開します。それぞれ、対応するツールと同じ Depot RPC とパーサーを呼び出し、text/plain を返し、DEPOT_MCP_OUTPUT_BUDGET に従い、Depot のエラーを読みやすい JSON-RPC エラーに変換します。テンプレートにリストコールバックはなく、サブスクライブするものもありません。読み取りのたびに新しいリクエストが行われます。

URI	内容
depot://ci/run/{runId}	depot_get_ci_run がレンダリングする、ワークフロー、ジョブ、試行のツリーです（GetRunStatus のみから取得）。
depot://ci/runs/failed	直近の失敗した CI 実行 20 件です。新しいものから順に並びます。
depot://project/{projectId}/builds	プロジェクトの直近のコンテナビルド 20 件とキャッシュヒット率です。
depot://projects	リージョン、ハードウェア、キャッシュポリシーを含む、すべてのプロジェクトです。

出力は常に上限内に収まります

各ツールは出力に上限を設け、切り詰めた場合はエージェントに知らせます。

• ログツールはリングバッファに順次ページングし、結果として末尾を返します。GetJobAttemptLogs は末尾を指定するパラメーターがなく、古い順にページングするためです。
• depot_diagnose_ci_failure は Depot 独自の bounds オブジェクトを平易な説明の注記として引き継ぎ、Depotが破棄したデータとこのサーバーが破棄したデータを区別します。そのため、不完全な診断が完全なものに見えることはありません。
• すべての結果は DEPOT_MCP_OUTPUT_BUDGET に従います。

読み取り専用モデルとセキュリティ

最初の項目を注意深く読んでください。

• Depot には読み取り専用のトークンスコープがありません。 ListRuns を呼び出せる Organization トークンは、CancelRun、RerunWorkflow、DeleteProject も呼び出せます。このサーバーに渡す認証情報によって安全になるわけではありません。このサーバーのツール登録が安全性を担保するすべてです。DEPOT_MCP_ALLOW_WRITES が設定されていない場合、変更を加えるツールを登録しないため、デフォルトで読み取り専用になります。トークンが制限されているからではありません。このフラグを設定すると、書き込みツールが利用可能になります。各ツールは最初にドライランを行い、Depot を呼び出す前にサーバー側で拒否する仕組みですが、dryRun: false の呼び出しは Depot を変更します。depot_dispatch_ci_workflow はワークフローを開始できます。DEPOT_MCP_DISPATCH_ALLOWLIST が設定されている場合は、その許可リストの範囲内に限られます。プロジェクトのリセット、イメージやシークレットの削除、トークンの発行を行うツールは、引き続きありません。readOnlyHint は強制機能ではなく、クライアントへのヒントとして扱ってください。
• 取り消せない書き込みには第 2 のゲートがあります。 DEPOT_MCP_ALLOW_DESTRUCTIVE を設定すると、DEPOT_MCP_ALLOW_WRITES も設定されている場合に限り、depot_delete_project が追加されます。このツールは、confirmProjectName がプロジェクトの現在の名前と一致しない限り、処理を拒否します。書き込みを無効にすると、削除も無効になります。詳しくは破壊的な書き込みを参照してください。
• 一部の操作は単に後回しにしているのではなく、対象外です。ProjectService/ResetProject（キャッシュされたデータをすべて削除します。もっともらしい「修正」に見えても、取り消せず、見えにくく、多大な影響を及ぼす可能性があります）、CIService/Run（お使いのインフラ上で任意のワークフローコンテンツを実行します）、トークンとシークレットの書き込み（CreateToken はシークレットを返すため、トランスクリプトに記録されます）、イメージとタグの削除、ShareBuild（公開 URL を作成します。読み取りを装ったデータ漏えいです）。
• トークンがログに記録されたり、出力されたり、ディスクに書き込まれたりすることはありません。 トークンは環境変数からのみ読み込まれ、エラーや depot_whoami で出力されることもありません。エンドポイントの設定ミスによってリクエストヘッダーが応答に含まれる場合に備え、トランスポート層および Depot 独自のエラーエンベロープからのエラーメッセージは、モデルに渡る前にトークンを除去します。このサーバーは ~/.config/depot/depot.yaml を読み込まないため、渡すつもりのなかった環境内の認証情報を取得することはありません。
• CI 変数の値はマスキングされます。 Depot はサーバー側でシークレットの値を隠しますが、変数の値はそのまま返します。また、変数がシークレットの保存に誤用されることもあります。名前または内容が認証情報のように見える値はプレースホルダーに置き換えられ、どのルールに該当したかも結果に示されるため、その変数が存在することは確認できます。
• このサーバー専用の Organization トークンを作成してください。個別に失効できるようになります。
• stdio のみを使用し、待ち受けポートはありません。 トークンが通過するネットワーク境界は、api.depot.dev への TLS 接続のみです。
• CI ログは信頼できないテキストです。 ログ行、ステップの概要、アーティファクト名、変数の値、Depot の AI による診断はリポジトリのコンテンツに由来します。そのため、Depot CI で実行されるリポジトリにプッシュできる人なら、これらの内容に任意の文言を含められます。このサーバーはそれらを返しますが、それに基づいて動作することはありません。ただし、エージェントは動作する可能性があります。概要では、そうしたテキストを --- begin untrusted CI content --- と --- end untrusted CI content --- の間に区切って表示し、Depot の診断と修正案には未検証のラベルを付け、構造化出力に contentWarning フィールドを含めます。サーバーの指示では、モデルに対し、これらをコマンドではなくデータとして扱うよう伝えます。
• Depot は CLI の認証情報を OS のキーチェーンではなく、プレーンテキスト（モード 0600）で保存します。macOS では ~/Library/Application Support/depot/depot.yaml、Linux では ~/.config/depot/depot.yaml です。そこからトークンをコピーする場合は注意してください。CLI は DEPOT_TOKEN より保存済みのログイン情報を優先するため、CLI とこのサーバーが異なる組織を参照している可能性があります。

アノテーションの扱いはクライアントによって異なります。Claude Desktop は readOnlyHint を自動承認に使用し、Claude Code はツールが許可リストに登録されていない限り毎回確認を求め、Cursor は独自の実行モードを使用します。セキュリティ上の問題は、SECURITY.md に記載された方法で報告してください。

制限事項

• Depot の API 経由でコンテナビルドを開始することは、誰にもできません。 ビルドを実行するには、mTLS BuildKit エンドポイントを取得し、ローカルのビルドコンテキストを転送する必要があります。これを行うために、depot CLI は BuildKit のフォークを組み込んでいます。このサーバーでビルドを行うことはできず、監視のみが可能です。人が depot build を実行するか、CI が実行します。
• コンテナのビルドステップは JSON ではなく、Connect のバイナリ protobuf エンコーディングで読み取られます。 Depot の GetBuildSteps の JSON バインディングは Depot 側で失敗します（サーバーが自身のレスポンスをエンコードできません）。そのため、このサーバーには Depot が公開している build.proto を基にした、2 つのビルドステップ RPC 用の依存関係のない小さな protobuf コーデックが含まれています。2026-09-06 時点では、GetBuildStepLogs はどちらのエンコーディングでもサーバー側の internal error を返します。そのため、depot_diagnose_build は失敗したステップと記録されたエラーを報告しますが、通常、ステップのログ行は報告しません。失敗するのではなく、結果でこのことを明示します。
• depot.ci.v1 にはリファレンスドキュメントがありますが、公開スキーマはありません。 depot/proto にも Buf Schema Registry にも存在しません。型の生成元も、破壊的変更の差分を確認する対象もありません。誰も公開していない契約をあるものとして扱うのではなく、camelCase と snake_case のどちらにも対応し、protobuf の int64 が文字列としてエンコードされる形式を処理し、列挙型の名前プレフィックスを除去する、寛容なアクセサーを使ってレスポンスを読み取ります。フィールドがない場合もクラッシュせず、「不明」として扱います。
• depot_get_ci_metrics は、認識できるフィールドとともに Depot の未加工ドキュメントを返します。 Depot のドキュメントでは、これらの RPC が CPU とメモリの概要を返すと説明されていますが、フィールド名は公開されていません。
• depot.ci.v3beta2 は、名前のとおりベータ版です。 シークレットと変数のツールは、最も破損しやすいツールです。リストのフィルターはドキュメント化されていないため、このサーバー内でフィルタリングを行い、Depot に送信するリクエストは空にします。
• ログのストリーミングには対応していません。 Depot は、トークンごと、かつ組織ごとに同時ログストリーム数を制限しています。ストリーミングツールを不用意に使うと、実際の CI を含む組織全体で上限を使い果たすおそれがあります。このサーバーでは代わりに、Depot のドキュメントで明示的に推奨されている単項の GetJobAttemptLogs をポーリングします。
• wait_for_run_to_finish ツールは意図的に用意していません。 長時間のポーリングは、ツール呼び出しのタイムアウトに適していません。代わりに、もう一度ステータスをリクエストしてください。エージェントはターンをまたいでポーリングできます。

アーキテクチャ

flowchart LR
    Client["MCP client<br/>(Claude Code, Cursor, VS Code, Codex, ...)"]
    Server["depot-mcp<br/>node dist/index.js"]
    API["api.depot.dev<br/>Connect JSON over HTTPS"]

    Client -- "JSON-RPC over stdio<br/>tools, prompts, resources" --> Server
    Server -- "POST /depot.ci.v1.CIService/GetFailureDiagnosis<br/>Authorization: Bearer DEPOT_TOKEN<br/>x-depot-org: DEPOT_ORG_ID" --> API
    API -- "JSON, read through tolerant accessors" --> Server
    Server -- "text summary + structuredContent,<br/>capped by DEPOT_MCP_OUTPUT_BUDGET" --> Client

1 つのプロセス、1 つの認証情報、リッスンポートなし、protobuf ツールチェーンなし。Depot の Connect バインディングは、HTTP POST 経由のプレーンな JSON なので、クライアントはリトライ機能を備えた fetch ラッパーです。ツールはそれぞれ src/tools/ の個別モジュールに分かれています。共通ヘルパー（budget、redact、resolve、ci-target）によって、各ツールを小さく保ち、出力を予測可能にしています。設計メモ、Depot API の調査、先行事例のレビューは、docs/ と research/ にあります。

トラブルシューティング

症状	原因と対処方法
claude mcp list に Failed to connect と表示され、ログに sh: depot-mcp: command not found と記録される	depot-mcp リポジトリ自体の中から Claude Code を起動しています。npx は同じ名前のプロジェクトを認識してインストールをスキップします。別のディレクトリから claude を起動するか、登録先を node <clone>/dist/index.js に指定してください。
サーバーがコード 78 で直ちに終了する	DEPOT_TOKEN が未設定、または空です。通常はクライアントの env ブロックへの設定漏れが原因です。
プロジェクト、ビルド、または使用状況のツールで unauthenticated と表示されるが、CI ツールは動作する	ユーザートークンを使用しています。これらのサービスで受け付けるのは Organization トークンのみです。トークンごとにできることを参照してください。
トークンは有効なのに、すべてのリストが空になる	DEPOT_ORG_ID を指定していない複数組織対応トークンです。depot_whoami を呼び出すと、参照可能な組織が表示されます。
permission_denied または unauthenticated と表示される	プロジェクトトークン（未対応）、失効したトークン、または誤った組織が原因です。depot_whoami で原因を特定できます。
depot_diagnose_ci_failure が state: empty を返す	Depot が分類できる失敗が実行に含まれていないか、指定した ID が失敗した実行ではありません。status: ["failed"] を指定して depot_list_ci_runs を呼び出すと、該当する実行を見つけられます。
state: over_limit	対象範囲が広すぎます。結果に narrowerTargets が表示されるので、ワークフロー ID またはジョブ ID を指定して再度呼び出してください。
結果に truncated: true と表示される	想定どおりです。結果の hint（より絞り込んだフィルター、grep、pageToken）を使用するか、DEPOT_MCP_OUTPUT_BUDGET を引き上げてください。
depot_list_sandboxes またはレジストリリポジトリのツールがツール一覧にない	ベータ機能で、デフォルトでは無効です。サーバーの env に DEPOT_MCP_ENABLE_BETA=1 を設定してください。有効になっているかは depot_whoami で確認できます。
クライアントに「response was interrupted」またはコンテキストエラーが表示される	クライアント独自の MCP 出力上限が原因です。生ログの代わりに診断ツールを使用するか、tailLines の値を下げるか、grep を使用してください。
初回実行時に npx が応答しなくなる	パッケージをダウンロードしています。ターミナルで npx -y depot-mcp を一度実行してから、クライアントを再起動してください。
クライアントには何も表示されないが、Inspector では動作する	stdout には JSON-RPC のみを出力する必要があります。ログを追加した場合は stderr に出力してください。
429 resource_exhausted	Depot のトークン単位または組織単位の制限に達しています。しばらくお待ちください。サーバーはすでにバックオフして再試行します。
約 40 秒後に deadline_exceeded が発生する	Depot が呼び出しごとの制限時間内に応答しませんでした。再試行してください。問題が続く場合は、ページ数を減らす、実行ではなくジョブを指定するなど、リクエストの範囲を絞ってください。
DEPOT_API_URL must be an https URL	ローカルスタブ用の http://localhost を除き、https:// エンドポイントのみ受け付けられます。
書き込みツールがツール一覧にない	DEPOT_MCP_ALLOW_WRITES が未設定です。これがデフォルトです。クライアントの env ブロックに 1 を設定し、サーバーを再起動してください。depot_stop_sandbox と depot_kill_sandbox には DEPOT_MCP_ENABLE_BETA=1 も必要です。
depot_dispatch_ci_workflow が、ワークフローが許可リストにないと表示する	DEPOT_MCP_DISPATCH_ALLOWLIST が設定されており、対象の owner/name:workflow.yml が含まれていません。追加するか、変数を未設定にして、トークンで参照可能な任意のリポジトリを許可してください。
書き込みツールがツール一覧にない	DEPOT_MCP_ALLOW_WRITES が未設定です。これがデフォルトです。クライアントの env ブロックに 1 を設定し、サーバーを再起動してください。
書き込み機能が有効なのに depot_delete_project がない	DEPOT_MCP_ALLOW_DESTRUCTIVE が未設定です。両方のフラグが必要です。破壊的操作のゲートが無効であることは depot_whoami に表示されます。
depot_delete_project が confirmProjectName ... is not this project's current name と返す	確認用の名前が一致しませんでした。ドライランのプレビューまたは depot_get_project から名前を確認し、ユーザーに確認してもらってください。完全一致が必要です。
書き込みツールが Depot の呼び出し前に Refused ... before calling Depot と返す	最新の読み取り結果で事前条件を満たしていません（対象がすでに終了状態、ワークフローがまだ実行中、失敗がない、試行上限に達しているなど）。メッセージにルールが記載されます。dryRun: true を指定すると現在の状態を確認できます。
サーバーは起動時に stderr に 1 行書き込みます（depot-mcp 0.1.0 ready on stdio ...）。ほとんどのクライアントでは、MCP ログに stderr が表示されます。

開発

npm install
npm run typecheck   # tsc --noEmit, strict
npm run lint        # eslint with type-aware rules
npm test            # vitest, no network or Depot account needed
npm run build       # emit dist/
npm run inspect     # build, then open the MCP Inspector
npm run smoke:stdio # handshake + tools/list against dist/, no token needed
DEPOT_MCP_ENABLE_BETA=1 npm run smoke:stdio   # the same with the four beta tools registered

テストでは、SDK の InMemoryTransport を介して実際の Client と実際の McpServer を接続し、fetch は test/fixtures/ に記録されたフィクスチャを返すようスタブ化します。入力の検証、出力スキーマへの適合、アノテーション、文字数の上限、エラーの変換という一連の往復処理全体を検証します。フィクスチャでは、GetFailureDiagnosis の 4 つの状態（focused_failure、grouped_failures、over_limit、empty）、空の結果、Connect のエラーエンベロープを網羅しています。

自分の Depot 組織を使ったライブチェック

DEPOT_TOKEN=YOUR_DEPOT_TOKEN npm run smoke

このチェックでは読み取り専用の呼び出しのみを実行し、見つかった内容を表示するとともに、各チェックの成功、失敗、スキップを報告します。組織に分析対象の失敗した実行がない場合、失敗診断のチェックはスキップされます。該当する実行がないと、主要なツールをテストできません。

リリース前に、npm run verify は .env 内の各トークン種別で、すべてのツール、プロンプト、リソースを実行し、トークン種別ごとのマトリックスを表示します。docs/verification.md では、マトリックス、オプトイン方式の適用実行、各リリースで人が一度実施する Claude Code セッションテストについて説明しています。

構成

src/
  index.ts          entrypoint: config, stdio transport
  server.ts         McpServer construction and instructions
  config.ts         environment resolution, fail-fast validation
  prompts.ts        the two chained workflows
  depot/
    client.ts       fetch against Depot's Connect JSON binding, with retry
    api.ts          typed RPC surface
    errors.ts       Connect error codes -> actionable messages
    shape.ts        tolerant accessors for an unpublished schema
  lib/
    tool.ts         registration, validation, error translation in one place
    write.ts        the write pattern: dryRun default, preview, refusal, audit line
    budget.ts       character budgets and truncation
    diagnosis.ts    parsing and shaping the GetFailureDiagnosis document
    ci-tree.ts      run -> workflow -> job -> attempt parsing
    ci-detail.ts    GetJob and GetWorkflow parsing, terminal states, attempt counts
    ci-target.ts    loose identifier resolution
    redact.ts       credential scrubbing
    write.ts        the dryRun / preview / refuse / apply shape of every write tool
    build.ts  project.ts  resolve.ts  time.ts
  tools/            one module per tool group; index.ts holds the write and beta gates
                    (beta.ts lists sandboxes.ts and registry-beta.ts)
  tools/            one module per tool group; index.ts holds the write and destructive gates,
                    writes.ts the gated lists, ci-writes.ts the five CI write tools,
                    projects-admin.ts the project update and delete
test/               vitest: unit, tool round-trips over InMemoryTransport, fixtures
docs/               design notes and distribution details
research/           the API and design research this was built from
.github/            CI, release, smoke and metadata scripts, templates
server.json         MCP Registry entry      manifest.json   Claude Desktop .mcpb manifest
Dockerfile          distroless stdio image  .mcp.json.example  Claude Code project config

research/ には、Depot API、MCP の設計上の決定、この実装が踏襲する先行事例の調査が記載されています。自明でない変更を加える前に読んでおくことをおすすめします。

コントリビューション

まず CONTRIBUTING.md をお読みください。要点は、デフォルトでは読み取り専用にし、書き込みはすべてゲートとそのドライランを通すこと、トークンをいかなる場所にも含めないこと、出力に上限を設けること、MCP クライアントのハーネスを通じてテストすること、コミットに署名すること（git commit -s）です。バグ報告と機能リクエストにはテンプレートがあります。セキュリティ上の問題は課題トラッカーではなく、SECURITY.md を通じて報告してください。

ライセンス

Apache License 2.0 に Commons Clause License Condition v1.0 を付加しています。LICENSE と NOTICE をご覧ください。

簡単に言うと、次のことができます。

• 自宅でも職場でも使用できます。Depot を利用する商用 CI パイプラインや有料製品での使用も含まれます。
• LICENSE ファイルと NOTICE ファイルを同梱する限り、変更、フォーク、再配布ができます。
• 同じ条件のもとで、変更をコントリビュートできます。

次のことはできません。

• このサーバーの機能だけ、または主としてその機能に価値を依存するものを販売したり、ホスティング料金を請求したり、有料の製品やサービスとして提供したりすること。

Commons Clause が付加されているため、OSI の定義では、これはオープンソースではなく、ソースが利用可能なソフトウェアです。それ以外の Apache 2.0 の条件（特許許諾、保証の否認、帰属表示）は変更なく適用されます。

Depot はその所有者の商標です。このプロジェクトは Depot Technologies Inc. とは無関係です。