CircleCI
公式CircleCIのビルド失敗をAIエージェントが修正できるようにします。
CircleCI MCPで何ができますか?
- CircleCI 設定の検証 —
config_helperを使用して、.circleci/config.ymlの構文エラーと意味エラーを検証します。 - パイプラインステータスの取得 —
get_latest_pipeline_statusでブランチの最新パイプラインステータスを確認します。 - パイプラインのトリガーと再実行 —
run_pipelineで新しいパイプラインを開始するか、rerun_workflowでワークフローを最初から、または失敗したジョブから再実行します。 - ビルド失敗の調査 —
get_build_failure_logsで詳細な失敗ログを取得し、get_job_test_resultsでテスト結果を取得します。 - フレークテストの検出 —
find_flaky_testsを使用してテスト実行履歴を分析し、フレークテストを特定します。 - 使用状況とコストの分析 —
download_usage_api_dataで使用状況データをダウンロードし、find_underused_resource_classesで使用率の低いリソースクラスを見つけます。
ドキュメント
[!IMPORTANT] このパッケージは非推奨です。移行してください。
@circleci/mcp-server-circleciは新機能の開発を停止しています。代わりに CircleCI のホステッド MCP サーバーまたはCircleCI CLI MCPを使用してください — 詳細は CircleCI MCP 概要 を参照してください。このリポジトリはアーカイブされます。既存のバージョンは npm から引き続きインストール可能ですが、CircleCI Personal API トークンを保持する保守されていないサーバーを実行することは推奨されません。
自己管理リモートトランスポート(
start=remote)を実行している場合は、まず移行してください:ホステッドサーバーはその直接の代替であり、組織のトークンを仲介するネットワーク公開サービスを運用する必要がなくなります。
CircleCI MCP サーバー
Model Context Protocol(MCP)は、大規模言語モデル(LLM)と外部システム間のコンテキストを管理するための新しい標準化されたプロトコルです。このリポジトリでは、CircleCI 用の MCP サーバーを提供しています。
Cursor、Windsurf、Copilot、Claude、または MCP 互換の任意のクライアントを使用して、IDE から離れることなく自然言語で CircleCI を操作できます。
ツール
| ツール | 説明 |
|---|---|
config_helper | CircleCI 設定を検証し、ガイダンスを取得します |
download_usage_api_data | CircleCI Usage API から使用状況データをダウンロードします |
find_flaky_tests | テスト実行履歴を分析して不安定なテストを特定します |
find_underused_resource_classes | 十分に活用されていないコンピュートリソースを持つジョブを特定します |
get_build_failure_logs | CircleCI ビルドから詳細な失敗ログを取得します |
get_job_test_results | CircleCI ジョブのテストメタデータと結果を取得します |
get_latest_pipeline_status | ブランチの最新パイプラインのステータスを取得します |
list_artifacts | CircleCI ジョブによって生成されたアーティファクトを一覧表示します |
list_component_versions | CircleCI コンポーネントのすべてのバージョンを一覧表示します |
list_followed_projects | フォローしているすべての CircleCI プロジェクトを一覧表示します |
rerun_workflow | ワークフローを最初から、または失敗したジョブから再実行します |
run_pipeline | パイプラインの実行をトリガーします |
run_rollback_pipeline | プロジェクトのロールバックをトリガーします |
インストール
チーム/集中デプロイ: 開発者ごとまたは共有の CircleCI トークンを使用して、組織向けに共有リモートサーバーを1台実行する(Kubernetes、Docker など)場合は、自己管理リモート MCP サーバーを参照してください。
Cursor
前提条件:
- CircleCI Personal API トークン(詳細)
- NPX: Node.js >= v18 と pnpm
- Docker: Docker
ローカル MCP サーバーで NPX を使用する
Cursor の MCP 設定に以下を追加します:
{
"mcpServers": {
"circleci-mcp-server": {
"command": "npx",
"args": ["-y", "@circleci/mcp-server-circleci@latest"],
"env": {
"CIRCLECI_TOKEN": "your-circleci-token",
"CIRCLECI_BASE_URL": "https://circleci.com",
"MAX_MCP_OUTPUT_LENGTH": "50000"
}
}
}
}
CIRCLECI_BASE_URLはオプションです — オンプレミス顧客のみ必須です。MAX_MCP_OUTPUT_LENGTHはオプションです — MCP 応答の最大出力長(デフォルト: 50000)。
ローカル MCP サーバーで Docker を使用する
Cursor の MCP 設定に以下を追加します:
{
"mcpServers": {
"circleci-mcp-server": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"-e",
"CIRCLECI_TOKEN",
"-e",
"CIRCLECI_BASE_URL",
"-e",
"MAX_MCP_OUTPUT_LENGTH",
"circleci/mcp-server-circleci"
],
"env": {
"CIRCLECI_TOKEN": "your-circleci-token",
"CIRCLECI_BASE_URL": "https://circleci.com",
"MAX_MCP_OUTPUT_LENGTH": "50000"
}
}
}
}
自己管理リモート MCP サーバーを使用する
自己管理リモート MCP サーバーを参照してください。ユーザーごとのクライアント設定を使用して、Cursor の MCP 設定に追加します(Cursor Settings → MCP)。
VS Code
前提条件:
- CircleCI Personal API トークン(詳細)
- NPX: Node.js >= v18 と pnpm
- Docker: Docker
ローカル MCP サーバーで NPX を使用する
プロジェクトの .vscode/mcp.json に以下を追加します:
{
"inputs": [
{
"type": "promptString",
"id": "circleci-token",
"description": "CircleCI API Token",
"password": true
},
{
"type": "promptString",
"id": "circleci-base-url",
"description": "CircleCI Base URL",
"default": "https://circleci.com"
}
],
"servers": {
"circleci-mcp-server": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@circleci/mcp-server-circleci@latest"],
"env": {
"CIRCLECI_TOKEN": "${input:circleci-token}",
"CIRCLECI_BASE_URL": "${input:circleci-base-url}"
}
}
}
}
💡 入力は最初のサーバー起動時に求められ、その後 VS Code によって安全に保存されます。
ローカル MCP サーバーで Docker を使用する
プロジェクトの .vscode/mcp.json に以下を追加します:
{
"inputs": [
{
"type": "promptString",
"id": "circleci-token",
"description": "CircleCI API Token",
"password": true
},
{
"type": "promptString",
"id": "circleci-base-url",
"description": "CircleCI Base URL",
"default": "https://circleci.com"
}
],
"servers": {
"circleci-mcp-server": {
"type": "stdio",
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"-e",
"CIRCLECI_TOKEN",
"-e",
"CIRCLECI_BASE_URL",
"circleci/mcp-server-circleci"
],
"env": {
"CIRCLECI_TOKEN": "${input:circleci-token}",
"CIRCLECI_BASE_URL": "${input:circleci-base-url}"
}
}
}
}
自己管理リモート MCP サーバーを使用する
自己管理リモート MCP サーバーを参照してください。.vscode/mcp.json でユーザーごとのクライアント設定を使用します。
Claude Desktop
前提条件:
- CircleCI Personal API トークン(詳細)
- NPX: Node.js >= v18 と pnpm
- Docker: Docker
ローカル MCP サーバーで NPX を使用する
お使いの claude_desktop_config.json に以下を追加します:
{
"mcpServers": {
"circleci-mcp-server": {
"command": "npx",
"args": ["-y", "@circleci/mcp-server-circleci@latest"],
"env": {
"CIRCLECI_TOKEN": "your-circleci-token",
"CIRCLECI_BASE_URL": "https://circleci.com",
"MAX_MCP_OUTPUT_LENGTH": "50000"
}
}
}
}
ローカル MCP サーバーで Docker を使用する
お使いの claude_desktop_config.json に以下を追加します:
{
"mcpServers": {
"circleci-mcp-server": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"-e",
"CIRCLECI_TOKEN",
"-e",
"CIRCLECI_BASE_URL",
"-e",
"MAX_MCP_OUTPUT_LENGTH",
"circleci/mcp-server-circleci"
],
"env": {
"CIRCLECI_TOKEN": "your-circleci-token",
"CIRCLECI_BASE_URL": "https://circleci.com",
"MAX_MCP_OUTPUT_LENGTH": "50000"
}
}
}
}
自己管理リモート MCP サーバーを使用する
自己管理リモート MCP サーバーを参照してください。Claude Desktop および CLI クライアントに示されているようにラッパースクリプトを作成し、それを claude_desktop_config.json で指定します。
設定ファイルを探すか作成するには、Claude Desktop の設定を開き、左サイドバーのDeveloperをクリックして、Edit Configをクリックします。設定ファイルの場所は以下のとおりです:
- macOS:
~/Library/Application Support/Claude/claude_desktop_config.json - Windows:
%APPDATA%\Claude\claude_desktop_config.json
Claude Code
前提条件:
- CircleCI Personal API トークン(詳細)
- NPX: Node.js >= v18 と pnpm
- Docker: Docker
ローカル MCP サーバーで NPX を使用する
claude mcp add circleci-mcp-server -e CIRCLECI_TOKEN=your-circleci-token -- npx -y @circleci/mcp-server-circleci@latest
ローカル MCP サーバーで Docker を使用する
claude mcp add circleci-mcp-server -e CIRCLECI_TOKEN=your-circleci-token -e CIRCLECI_BASE_URL=https://circleci.com -- docker run --rm -i -e CIRCLECI_TOKEN -e CIRCLECI_BASE_URL circleci/mcp-server-circleci
自己管理リモート MCP サーバーを使用する
自己管理リモート MCP サーバーと、そこにある Claude Code クライアントのセットアップを参照してください。
Windsurf
前提条件:
- CircleCI Personal API トークン(詳細)
- NPX: Node.js >= v18 と pnpm
- Docker: Docker
ローカル MCP サーバーで NPX を使用する
Windsurf の mcp_config.json に以下を追加します:
{
"mcpServers": {
"circleci-mcp-server": {
"command": "npx",
"args": ["-y", "@circleci/mcp-server-circleci@latest"],
"env": {
"CIRCLECI_TOKEN": "your-circleci-token",
"CIRCLECI_BASE_URL": "https://circleci.com",
"MAX_MCP_OUTPUT_LENGTH": "50000"
}
}
}
}
ローカル MCP サーバーで Docker を使用する
Windsurf の mcp_config.json に以下を追加します:
{
"mcpServers": {
"circleci-mcp-server": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"-e",
"CIRCLECI_TOKEN",
"-e",
"CIRCLECI_BASE_URL",
"-e",
"MAX_MCP_OUTPUT_LENGTH",
"circleci/mcp-server-circleci"
],
"env": {
"CIRCLECI_TOKEN": "your-circleci-token",
"CIRCLECI_BASE_URL": "https://circleci.com",
"MAX_MCP_OUTPUT_LENGTH": "50000"
}
}
}
}
自己管理リモート MCP サーバーを使用する
自己管理リモート MCP サーバーを参照してください。Windsurf の mcp_config.json でユーザーごとのクライアント設定を使用します。
Amazon Q Developer CLI
前提条件:
Amazon Q Developer の MCP クライアント設定は、mcp.json という名前のファイルに JSON 形式で保存されます。設定は2つのレベルでサポートされています:
- グローバル:
~/.aws/amazonq/mcp.json— すべてのワークスペースに適用されます - ワークスペース:
.amazonq/mcp.json— 現在のワークスペースに固有です
両方のファイルが存在する場合、その内容はマージされます。競合が発生した場合は、ワークスペース設定が優先されます。
ローカル MCP サーバーで NPX を使用する
~/.aws/amazonq/mcp.json を編集するか、以下で .amazonq/mcp.json を作成します:
{
"mcpServers": {
"circleci-local": {
"command": "npx",
"args": [
"-y",
"@circleci/mcp-server-circleci@latest"
],
"env": {
"CIRCLECI_TOKEN": "YOUR_CIRCLECI_TOKEN",
"CIRCLECI_BASE_URL": "https://circleci.com",
"MAX_MCP_OUTPUT_LENGTH": "50000"
},
"timeout": 60000
}
}
}
自己管理リモート MCP サーバーを使用する
自己管理リモート MCP サーバーを参照してください。Claude Desktop および CLI クライアントに示されているようにラッパースクリプトを使用し、q mcp add に登録します。
Amazon Q Developer(IDE 内)
前提条件:
ローカル MCP サーバーで NPX を使用する
~/.aws/amazonq/mcp.json を編集するか、以下で .amazonq/mcp.json を作成します:
{
"mcpServers": {
"circleci-local": {
"command": "npx",
"args": [
"-y",
"@circleci/mcp-server-circleci@latest"
],
"env": {
"CIRCLECI_TOKEN": "YOUR_CIRCLECI_TOKEN",
"CIRCLECI_BASE_URL": "https://circleci.com",
"MAX_MCP_OUTPUT_LENGTH": "50000"
},
"timeout": 60000
}
}
}
自己管理リモート MCP サーバーを使用する
自己管理リモート MCP サーバーを参照してください。Claude Desktop および CLI クライアントに示されているようにラッパースクリプトを使用し、MCP 設定 UI から追加します:
- MCP 設定 UI にアクセス
- + 記号を選択します
- スコープを選択:global または local
- 名前を入力(例:
circleci-remote-mcp) - トランスポートプロトコルを選択:stdio
- スクリプトへのコマンドパスを入力します
- Save をクリックします
Smithery
Smithery を介して Claude Desktop 用の CircleCI MCP サーバーを自動的にインストールするには:
npx -y @smithery/cli install @CircleCI-Public/mcp-server-circleci --client claude
自己管理リモート MCP サーバー
MCP サーバーを一元管理(例:Kubernetes または Docker)で実行し、チームが1つのデプロイを共有できるようにします。開発者の認証方法を選択してください:
デプロイモードの選択
| モード | 使用時期 | サーバー設定 | クライアント設定 | CircleCI 監査証跡 |
|---|---|---|---|---|
| ユーザーごとのトークン(推奨) | SSO 連携の Personal API トークンを持つチーム | REQUIRE_REQUEST_TOKEN=true、サーバー PAT なし | 各開発者が自分の PAT を転送 | 開発者ごと |
| 共有トークン(暫定) | 迅速な展開、単一のサービス ID で問題ない場合 | サーバー上で CIRCLECI_TOKEN、REQUIRE_REQUEST_TOKEN=false(明示的なオプトアウト) | 認証ヘッダー不要 | 単一の共有 ID |
セキュリティ: リモートモードでは、リクエスト認証はデフォルトでオンです。共有トークンモードではこれが無効になり(
REQUIRE_REQUEST_TOKEN=false)、すべての呼び出し元が資格情報なしでサーバーのCIRCLECI_TOKENアイデンティティとして動作できるようになります(任意の設定でパイプラインをトリガーすることも含む)。完全に信頼できるネットワーク上でのみ有効にし、それ以外の場合はユーザーごとのトークンを優先してください。イングレスでの TLS 終端は暗号化を提供しますが、認証は提供しません。この組み合わせはパブリックインターフェースでは安全ではないため、
REQUIRE_REQUEST_TOKEN=falseが非ループバックのバインドアドレスと組み合わされた場合、MCP_ALLOW_UNAUTHENTICATED_NETWORK_ACCESS=trueでリスクを明示的に受け入れない限り、サーバーは起動を拒否します。Host/Originチェックは認証の代替にはなりません — 以下の DNS リバインディング保護を参照してください。
1. サーバーのデプロイ
両モードともリモート HTTP モード(start=remote)を使用します。ポート 8000(または選択したポート)を公開します。
ユーザーごとのトークン(推奨)— localhost から mcp-remote 経由でアクセス:
docker run --rm -p 8000:8000 \
-e start=remote \
-e port=8000 \
-e REQUIRE_REQUEST_TOKEN=true \
circleci/mcp-server-circleci
ユーザーごとのトークン(推奨)— パブリックホスト名から mcp-remote 経由でアクセス:
docker run --rm -p 8000:8000 \
-e start=remote \
-e port=8000 \
-e REQUIRE_REQUEST_TOKEN=true \
-e MCP_ALLOWED_HOSTS=my-mcp.example.com \
circleci/mcp-server-circleci
共有トークン(暫定)— パブリックホスト名から mcp-remote 経由でアクセス:
このモードは、資格情報なしの任意の呼び出し元に組織の PAT を提供するため、公開ポートが信頼できないネットワークから到達不能な場所でのみ実行する必要があり、それを明示的に確認しないとサーバーは起動を拒否します:
docker run --rm -p 8000:8000 \
-e start=remote \
-e port=8000 \
-e CIRCLECI_TOKEN=your-shared-circleci-pat \
-e REQUIRE_REQUEST_TOKEN=false \
-e MCP_ALLOW_UNAUTHENTICATED_NETWORK_ACCESS=true \
-e MCP_ALLOWED_HOSTS=my-mcp.example.com \
circleci/mcp-server-circleci
代わりに、ポートの前に認証を配置することを優先してください — SSO、mTLS、または API キーを要求するイングレス — または上記のユーザーごとのトークンに切り替えてください。
環境変数:
| 変数 | 説明 |
|---|---|
start=remote | stdio の代わりに HTTP+SSE MCP サーバーを起動します |
port | コンテナ内の待受ポート(デフォルト: 8000) |
REQUIRE_REQUEST_TOKEN | Authorization: Bearer または Circle-Token ヘッダーがないリクエストを拒否します。デフォルトは必須です。未認証リクエストを許可するには REQUIRE_REQUEST_TOKEN=false を設定します(共有トークンモード) |
CIRCLECI_TOKEN | ユーザーごとのヘッダーが送信されない場合に、すべてのリクエストで使用される共有フォールバック PAT |
CIRCLECI_BASE_URL | 任意 — オンプレミスの場合のみ必須(デフォルト: https://circleci.com) |
DISABLE_TELEMETRY=true | 使用状況メトリクスのエクスポートをオプトアウトします |
MCP_ALLOWED_HOSTS | 許可する追加の Host ヘッダー値のカンマ区切りリスト(例: my-mcp.example.com,my-mcp.example.com:443)。ループバックホスト名は常に許可されます。非ループバックデプロイメントでは必須です。 |
MCP_ALLOWED_ORIGINS | 許可する追加の Origin ヘッダー値のカンマ区切りリスト(例: https://my-app.example.com)。ループバックオリジンは常に許可されます。ブラウザが(mcp-remote 経由ではなく)このサーバーに直接到達する場合にのみ必要です。 |
MCP_BIND_HOST | バインドするネットワークインターフェース(デフォルト: 0.0.0.0)。ループバックのみに制限するには 127.0.0.1 に設定します(Docker の -p ポートマッピングとは互換性がありません)。 |
MCP_ALLOW_UNAUTHENTICATED_NETWORK_ACCESS | REQUIRE_REQUEST_TOKEN=false を非ループバックバインドアドレスで起動する場合に必須(=true)。ポートに到達できるピアはすべて、資格情報なしでサーバーの CIRCLECI_TOKEN アイデンティティとして動作することを了承します。リクエストトークンが必須の場合は効果がありません。 |
MCP_FILE_OUTPUT_ROOTS | ファイル読み取り/書き込みツールが使用できる追加ディレクトリのカンマ区切りリスト(例: /srv/reports,/data/exports)。作業ディレクトリ、ホームディレクトリ、一時ディレクトリは常に許可されます。下記の注記を参照してください。 |
ファイル出力場所(stdio とリモートトランスポートの両方に適用): ファイルシステムパスを受け付けるツール —
get_build_failure_logs(outputDir)、download_usage_api_data(outputDir)、find_underused_resource_classes(csvFilePath)— は、サーバーの作業ディレクトリ、ユーザーのホームディレクトリ、システムの一時ディレクトリ内でのみ読み書きできます。これらのルート内では、隠し設定ディレクトリ(~/.ssh、~/.aws、~/.config、.git、…)、node_modules、および launch-agent ディレクトリは拒否され、許可されたルートの外に解決されるシンボリックリンクも拒否されます。システムディレクトリ(/etc、/usr、/bin、/System、/Library、%SystemRoot%、…)は無条件に拒否され、再び有効にすることはできません。出力ファイルがシンボリックリンク経由で書き込まれることはありません。チェックアウトがこれらのルートの外にある場合 — コンテナ内の
/workspace、/srv、/opt、/Volumes/workなどのセカンダリボリューム — は、MCP_FILE_OUTPUT_ROOTSをそのディレクトリに設定してください。設定しないと、これらのパスは拒否されます。stdio サーバーの場合、作業ディレクトリは通常すでにプロジェクトルートであるため、設定は不要です。これは、パスがローカルユーザーではなくネットワーククライアントから送られるリモートトランスポートで最も重要です。
DNS リバインディング保護(認証ではありません): リモートトランスポートは、すべての
/mcpリクエストでHostヘッダーを検検証します。デフォルトではループバックアドレス(localhost、127.0.0.1、[::1])のみが受け入れられます。公開デプロイメントでは、クライアントが使用するホスト名にMCP_ALLOWED_HOSTSを設定する必要があります。 設定しない場合、すべての/mcpリクエストは403 Forbiddenを受け取ります。/pingヘルスチェックエンドポイントはガードされていないため、ロードバランサーのプローブはHostに関係なく機能し続けます。(ブラウザが送信する)
Originヘッダーも、存在する場合は検検証されます。mcp-remoteなどの非ブラウザクライアントはOriginを送信しないため、このチェックの影響を受けません。このチェックはアクセス制御ではなく、アクセス制御として依存してはなりません。 両方のヘッダーは呼び出側が選択するため、curl、スクリプト、生のソケットなどの非ブラウザクライアントは、許可された
Hostを送信し、Originを省略することでこのチェックを満たすことができます。その唯一の目的は、攻撃者が制御する DNS によってブラウザがサーバーに向けられるのを防ぐことです。これが DNS リバインディングの脅威です。呼び出し元の認証は、REQUIRE_REQUEST_TOKEN(またはポートの前にある認証プロキシ)の役割です。Originヘッダーを必須にすると、正当な CLI クライアントをすべて壊し、攻撃者を止めることはできません。リバースプロキシの背後にある場合: プロキシが
Hostをバックエンドアドレスに書き換える場合(nginx のデフォルト)、proxy_set_header Host $host;を追加して元のホスト名を通過させ、MCP_ALLOWED_HOSTSをその公開ホスト名に設定します。あるいは、プロキシが転送するホスト名にMCP_ALLOWED_HOSTSを設定します。
サーバーは、以下の方法でリクエストごとのトークンを受け付けます:
Authorization: Bearer <circleci-pat>Circle-Token: <circleci-pat>
クライアントがヘッダートークンを送信した場合、サーバー上の CIRCLECI_TOKEN よりも優先されます。
リクエスト中に記録されたテレメトリメトリクスは、そのリクエストと同じトークンを使用してエクスポートされます。
2. クライアントの設定
ほとんどの MCP クライアントはローカル(stdio)プロセスのみをサポートしています。mcp-remote(サードパーティ製の stdio-to-HTTP ブリッジ)を使用して、リモートサーバーに接続します。
URL スキーム: ローカルテストでは
--allow-http付きでhttp://localhost:8000/mcpを使用します。本番環境では、イングレス/ロードバランサーで TLS を終了し、--allow-httpなしでhttps://your-host/mcpを使用します。
Windows:
--header値のコロンの周囲にスペースを入れないでください。完全なBearer <token>値を環境変数に入れてください。
セキュリティ: 例では便宜上
npxを使用しています。本番環境やチームでの展開では、MCP 設定で特定のバージョンを固定してください(例:mcp-remoteではなくmcp-remote@0.1.38)。0.1.16より前のバージョンは使用しないでください(CVE-2025-6514)。
クライアント設定: ユーザーごとのトークン
各開発者は、すべてのリクエストで自分の CircleCI Personal API Token を転送します:
{
"inputs": [
{
"type": "promptString",
"id": "circleci-token",
"description": "CircleCI API Token",
"password": true
}
],
"mcpServers": {
"circleci-mcp-server-remote": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"http://localhost:8000/mcp",
"--allow-http",
"--header",
"Authorization:${AUTH_HEADER}"
],
"env": {
"AUTH_HEADER": "Bearer ${input:circleci-token}"
}
}
}
}
http://localhost:8000/mcp をチームのサーバー URL に置き換えてください。Cursor と VS Code は ${input:...} プロンプトをサポートしています。他のクライアントは AUTH_HEADER を直接設定できます。
クライアント設定: 共有トークン
サーバーに CIRCLECI_TOKEN が設定され、REQUIRE_REQUEST_TOKEN=false で起動されている場合(リクエスト認証はデフォルトでオンになっており、明示的に無効にする必要があります。また、非ループバックバインドには追加で MCP_ALLOW_UNAUTHENTICATED_NETWORK_ACCESS=true が必要です)、クライアントはトークンを送信する必要はありません:
{
"mcpServers": {
"circleci-mcp-server-remote": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"http://localhost:8000/mcp",
"--allow-http"
]
}
}
}
Claude Desktop および CLI クライアント
ラッパースクリプトを作成します(例: circleci-remote-mcp.sh):
#!/bin/bash
export AUTH_HEADER="Bearer your-circleci-token"
npx mcp-remote http://localhost:8000/mcp --allow-http --header "Authorization:${AUTH_HEADER}"
実行可能にします(chmod +x circleci-remote-mcp.sh)、その後 MCP 設定から参照します:
{
"mcpServers": {
"circleci-remote-mcp-server": {
"command": "/full/path/to/circleci-remote-mcp.sh"
}
}
}
Claude Code
claude mcp add circleci-mcp-server \
-e AUTH_HEADER="Bearer your-circleci-token" \
-- npx mcp-remote http://localhost:8000/mcp --allow-http --header "Authorization:${AUTH_HEADER}"
共有トークンサーバーを使用する場合は、--header と AUTH_HEADER を省略します。
3. デプロイメントの検証
# Health check (no auth required)
curl http://localhost:8000/ping
# Should return 401 when REQUIRE_REQUEST_TOKEN=true and no token is sent
curl -s -o /dev/null -w "%{http_code}\n" -X POST http://localhost:8000/mcp \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'
# Should return 200 with a valid Bearer token and MCP Accept headers
curl -s -o /dev/null -w "%{http_code}\n" -X POST http://localhost:8000/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-H "Authorization: Bearer your-circleci-pat" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'
デモ
実際の動作を見る
例: 「私のブランチで最新の失敗したパイプラインを探してログを取得する」 — その他の例はウィキを参照してください。
https://github.com/user-attachments/assets/3c765985-8827-442a-a8dc-5069e01edb74
ツールの詳細
config_helper
ガイダンスと検証を提供することで、CircleCI 設定タスクを支援します。
.circleci/config.ymlの構文および意味上のエラーを検証します- 詳細な検証結果と設定に関する推奨事項を提供します
- 例: 「CircleCI 設定を検証して」
download_usage_api_data
指定された組織の CircleCI Usage API から使用状況データをダウンロードします。柔軟な日付入力を受け付けます(例: 「2025年3月」や「先月」)。クラウド限定機能です。
オプション 1: 以下の情報を提供して新しいエクスポートジョブを開始します:
orgId、startDate、endDate(最大 32 日間)、outputDir
オプション 2: 以下の情報を提供して既存のエクスポートジョブを確認/ダウンロードします:
orgId、jobId、outputDir
指定された期間の CircleCI 使用状況データを含む CSV ファイルを返します。
[!NOTE] 使用状況データは、コスト最適化分析のために
find_underused_resource_classesツールに入力できます。
find_flaky_tests
テスト実行履歴を分析して、CircleCI プロジェクトのフレークテストを特定します。CircleCI のフレークテスト検出機能を活用します。
このツールは 3 つの方法で使用できます:
-
プロジェクトスラッグを使用(推奨):
- 最初に
list_followed_projectsを使用してプロジェクトを取得し、次に: - 例: 「my-project のフレークテストを取得して」
- 最初に
-
CircleCI プロジェクト URL を使用:
- 例: 「https://app.circleci.com/pipelines/github/org/repo でフレークテストを探して」
-
ローカルプロジェクトコンテキストを使用:
- ワークスペースルートと git リモート URL を提供してローカルワークスペースから動作します
- 例: 「現在のプロジェクトのフレークテストを探して」
出力モード:
- テキスト(デフォルト): フレークテストの詳細をテキスト形式で返します
- ファイル(
FILE_OUTPUT_DIRECTORY環境変数が必要): フレークテストの詳細を含むディレクトリを作成します
find_underused_resource_classes
CircleCI 使用状況データ CSV ファイルを分析して、平均または最大 CPU/RAM 使用率が指定されたしきい値(デフォルト: 40%)を下回るジョブを特定します。
download_usage_api_data から取得した CSV ファイルを提供します。
プロジェクトとワークフローごとに整理された、使用不足のジョブのマークダウンリストを返します — コスト最適化の機会を特定するのに役立ちます。
get_build_failure_logs
CircleCI ビルドから詳細な失敗ログを取得します。このツールは 3 つの方法で使用できます:
-
プロジェクトスラッグとブランチを使用(推奨):
- 最初に
list_followed_projectsを使用してプロジェクトを取得し、次に: - 例: 「main ブランチの my-project のビルド失敗を取得して」
- 最初に
-
CircleCI URL を使用:
- 失敗したジョブ URL またはパイプライン URL を直接提供します
- 例: 「https://app.circleci.com/pipelines/github/org/repo/123 からログを取得して」
-
ローカルプロジェクトコンテキストを使用:
- ワークスペースルート、git リモート URL、ブランチ名を提供してローカルワークスペースから動作します
- 例: 「現在のブランチで最新の失敗したパイプラインを探して」
このツールは、以下を含むフォーマットされたログを返します:
- ジョブ名
- ステップごとの実行詳細
- 失敗メッセージとコンテキスト
get_job_test_results
CircleCI ジョブのテストメタデータを取得し、IDE から離れることなくテスト結果を分析できます。このツールは 3 つの方法で使用できます:
-
プロジェクトスラッグとブランチを使用(推奨):
- 例: 「main ブランチの my-project のテスト結果を取得して」
-
CircleCI URL を使用:
- ジョブ URL:
https://app.circleci.com/pipelines/github/org/repo/123/workflows/abc-def/jobs/789 - ワークフロー URL:
https://app.circleci.com/pipelines/github/org/repo/123/workflows/abc-def - パイプライン URL:
https://app.circleci.com/pipelines/github/org/repo/123
- ジョブ URL:
-
ローカルプロジェクトコンテキストを使用:
- ワークスペースルート、git リモート URL、ブランチ名を提供してローカルワークスペースから動作します
このツールは以下を返します:
- すべてのテストの概要(合計、成功、失敗)
- 失敗したテストの詳細情報: 名前、クラス、ファイル、エラーメッセージ、所要時間
- タイミング付きの成功したテストのリスト
- テスト結果によるフィルタリング
[!NOTE] テストメタデータは CircleCI 設定で構成する必要があります。セットアップ手順についてはテストデータの収集を参照してください。
get_latest_pipeline_status
指定されたブランチの最新パイプラインのステータスを取得します。このツールは次の3つの方法で使用できます:
-
プロジェクトスラッグとブランチを使用(推奨):
- 例:「main ブランチの my-project の最新パイプラインのステータスを取得して」
-
CircleCI プロジェクト URL を使用:
- 例:「https://app.circleci.com/pipelines/github/org/repo の最新パイプラインのステータスを取得して」
-
ローカルプロジェクトコンテキストを使用:
- ワークスペースルート、git リモート URL、ブランチ名を指定することで、ローカルワークスペースから動作します
出力例:
---
Workflow: build
Status: success
Duration: 5 minutes
Created: 4/20/2025, 10:15:30 AM
Stopped: 4/20/2025, 10:20:45 AM
---
Workflow: test
Status: running
Duration: unknown
Created: 4/20/2025, 10:21:00 AM
Stopped: in progress
list_artifacts
CircleCI ジョブで生成されたアーティファクトのリストを取得します。このツールは次の3つの方法で使用できます:
-
プロジェクトスラッグとブランチを使用(推奨):
- まず
list_followed_projectsを使用してプロジェクトを取得し、次に: - 例:「main ブランチの my-project のアーティファクトを一覧表示して」
- まず
-
CircleCI URL を使用:
- ジョブ URL:
https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def/jobs/789 - ワークフロー URL:
https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def - パイプライン URL:
https://app.circleci.com/pipelines/gh/organization/project/123
- ジョブ URL:
-
ローカルプロジェクトコンテキストを使用:
- ワークスペースルート、git リモート URL、ブランチ名を指定することで、ローカルワークスペースから動作します
次のような場合に便利です:
- ビルドアーティファクト(バイナリ、レポート、ログ)のダウンロード URL を見つける
- パイプライン実行で生成されたアーティファクトを確認する
list_component_versions
環境内の特定の CircleCI コンポーネントの全バージョンを一覧表示します。デプロイステータス、コミット情報、タイムスタンプが含まれます。
コンポーネントと環境が指定されていない場合、ツールは選択を促します。
次のような場合に便利です:
- 現在稼働中のバージョンの特定
- ロールバック操作の対象バージョンの選択
- デプロイの詳細(パイプライン、ワークフロー、ジョブ)の取得
list_followed_projects
ユーザーが CircleCI でフォローしているすべてのプロジェクトを一覧表示します。
- アクセス権のあるすべてのプロジェクトを
projectSlugとともに表示します - 例:「CircleCI プロジェクトを一覧表示して」
出力例:
Projects followed:
1. my-project (projectSlug: gh/organization/my-project)
2. another-project (projectSlug: gh/organization/another-project)
[!NOTE] 他の多くの CircleCI ツールでは
projectSlug(プロジェクト名ではなく)が必要です。
rerun_workflow
ワークフローを開始時または失敗したジョブから再実行します。
新しく作成されたワークフローの ID と、それを監視するためのリンクを返します。
run_pipeline
パイプラインの実行をトリガーします。このツールは次の3つの方法で使用できます:
-
プロジェクトスラッグとブランチを使用(推奨):
- 例:「main ブランチの my-project のパイプラインを実行して」
-
CircleCI URL を使用:
- パイプライン URL、ワークフロー URL、ジョブ URL、またはブランチ付きのプロジェクト URL
- 例:「https://app.circleci.com/pipelines/github/org/repo/123 のパイプラインを実行して」
-
ローカルプロジェクトコンテキストを使用:
- ワークスペースルート、git リモート URL、ブランチ名を指定することで、ローカルワークスペースから動作します
ツールはパイプライン実行を監視するためのリンクを返します。
run_rollback_pipeline
CircleCI プロジェクトのロールバックをトリガーします。ツールは対話形式で次の手順を案内します:
- プロジェクト選択 — フォロー中のプロジェクトを一覧表示し、選択させます
- 環境選択 — 利用可能な環境を一覧表示します(1つだけの場合は自動選択)
- コンポーネント選択 — 利用可能なコンポーネントを一覧表示します(1つだけの場合は自動選択)
- バージョン選択 — 利用可能なバージョンを表示し、ロールバック対象を選択します
- ロールバックモード検出 — ロールバックパイプラインが設定されているか確認します
- ロールバックの実行 — 2つのオプション:
- パイプラインロールバック: ロールバックパイプラインをトリガーします
- ワークフロー再実行: ワークフロー ID を使用して以前のワークフローを再実行します
- 確認 — 実行前に概要を表示して確認します
トラブルシューティング
クイック修正
最も一般的な問題:
-
パッケージキャッシュをクリア:
npx clear-npx-cache npm cache clean --force -
最新バージョンを強制: 設定に
@latestを追加:"args": ["-y", "@circleci/mcp-server-circleci@latest"] -
IDE を完全に再起動(ウィンドウの再読み込みだけでなく)
認証の問題
- 無効なトークンエラー: Personal API Tokens で
CIRCLECI_TOKENを確認してください - 権限エラー: トークンがプロジェクトへの読み取りアクセス権を持っていることを確認してください
- 環境変数が読み込まれない:
echo $CIRCLECI_TOKEN(Mac/Linux)またはecho %CIRCLECI_TOKEN%(Windows)でテストしてください
接続とネットワークの問題
- ベース URL:
CIRCLECI_BASE_URLがhttps://circleci.comであることを確認してください - 企業ネットワーク: ファイアウォールの内側にいる場合は npm プロキシ設定を構成してください
- ファイアウォールによるブロック: セキュリティソフトウェアがパッケージのダウンロードをブロックしていないか確認してください
システム要件
- Node.js バージョン:
node --versionで >= 18.0.0 を確認してください - Node.js の更新: 互換性の問題が発生している場合は最新の LTS を検討してください
- パッケージマネージャー: npm/pnpm が動作しているか確認してください:
npm --version
IDE 固有の問題
- 設定ファイルの場所: OS に応じたパスを再確認してください
- 構文エラー: 設定ファイルの JSON 構文を検証してください
- コンソールログ: IDE の開発者コンソールで具体的なエラーを確認してください
- 別の IDE を試す: 他のサポートされているエディタでテストして問題を切り分けてください
プロセスの問題
ハングしたプロセス — 既存の MCP プロセスを強制終了:
# Mac/Linux:
pkill -f "mcp-server-circleci"
# Windows:
taskkill /f /im node.exe
ポート競合: 接続がブロックされているように見える場合は IDE を再起動してください。
高度なデバッグ
- パッケージを直接テスト:
npx @circleci/mcp-server-circleci@latest --help - 詳細ログ:
DEBUG=* npx @circleci/mcp-server-circleci@latest - Docker フォールバック: npx が一貫して失敗する場合は Docker インストールを試してください
それでも解決しない場合:
- GitHub Issues で同様の問題を確認してください
- 問題を報告する際は OS、Node バージョン、IDE を含めてください
- IDE コンソールからの関連エラーメッセージを共有してください
テレメトリ
サーバーはツール使用状況を追跡するための OpenTelemetry メトリクスをサポートしています。DISABLE_TELEMETRY=true を設定しない限り、メトリクスはエクスポートされます。リモートデプロイでは、メトリクスはリクエストと同じトークン(ユーザーごとの PAT または共有サーバー PAT)を使用します。
| メトリクス | 説明 |
|---|---|
circleci.mcp.tool.invocations | ツール呼び出し回数 |
circleci.mcp.tool.duration_ms | 実行時間(ms) |
circleci.mcp.tool.errors | エラー数 |
開発
はじめに
-
リポジトリをクローン:
git clone https://github.com/CircleCI-Public/mcp-server-circleci.git cd mcp-server-circleci -
依存関係をインストール:
pnpm install -
プロジェクトをビルド:
pnpm build
Docker コンテナのビルド
Docker コンテナはローカルで次のコマンドを使用してビルドできます:
docker build -t circleci:mcp-server-circleci .
これにより、circleci:mcp-server-circleci としてタグ付けされた Docker イメージが作成され、任意の MCP クライアントで使用できます。
ローカル stdio モード(単一開発者、クライアント上のトークン):
docker run --rm -i \
-e CIRCLECI_TOKEN=your-circleci-token \
-e CIRCLECI_BASE_URL=https://circleci.com \
circleci/mcp-server-circleci
リモートモード(チーム用の集中サーバー):Self-Managed Remote MCP Server を参照してください。
MCP Inspector を使用した開発
MCP サーバーを反復開発する最も簡単な方法は、MCP Inspector を使用することです。MCP Inspector の詳細については https://modelcontextprotocol.io/docs/tools/inspector で確認できます。
-
開発サーバーを起動:
pnpm watch # Keep this running in one terminal -
別のターミナルで Inspector を起動:
pnpm inspector -
環境を構成:
CIRCLECI_TOKENを Inspector UI の Environment Variables セクションに追加してください- トークンには CircleCI プロジェクトへの読み取りアクセス権が必要です
- 必要に応じて CircleCI ベース URL を設定してください(デフォルトは
https://circleci.com)
テスト
-
テストスイートを実行:
pnpm test -
開発中はウォッチモードでテストを実行:
pnpm test:watch
より詳細なコントリビューションガイドラインについては、CONTRIBUTING.md を参照してください。