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 サーバー

License: Apache 2.0 CircleCI npm

Model Context Protocol(MCP)は、大規模言語モデル(LLM)と外部システム間のコンテキストを管理するための新しい標準化されたプロトコルです。このリポジトリでは、CircleCI 用の MCP サーバーを提供しています。

Cursor、Windsurf、Copilot、Claude、または MCP 互換の任意のクライアントを使用して、IDE から離れることなく自然言語で CircleCI を操作できます。

ツール

ツール説明
config_helperCircleCI 設定を検証し、ガイダンスを取得します
download_usage_api_dataCircleCI Usage API から使用状況データをダウンロードします
find_flaky_testsテスト実行履歴を分析して不安定なテストを特定します
find_underused_resource_classes十分に活用されていないコンピュートリソースを持つジョブを特定します
get_build_failure_logsCircleCI ビルドから詳細な失敗ログを取得します
get_job_test_resultsCircleCI ジョブのテストメタデータと結果を取得します
get_latest_pipeline_statusブランチの最新パイプラインのステータスを取得します
list_artifactsCircleCI ジョブによって生成されたアーティファクトを一覧表示します
list_component_versionsCircleCI コンポーネントのすべてのバージョンを一覧表示します
list_followed_projectsフォローしているすべての CircleCI プロジェクトを一覧表示します
rerun_workflowワークフローを最初から、または失敗したジョブから再実行します
run_pipelineパイプラインの実行をトリガーします
run_rollback_pipelineプロジェクトのロールバックをトリガーします

インストール

チーム/集中デプロイ: 開発者ごとまたは共有の CircleCI トークンを使用して、組織向けに共有リモートサーバーを1台実行する(Kubernetes、Docker など)場合は、自己管理リモート MCP サーバーを参照してください。

Cursor

前提条件:

ローカル 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

前提条件:

ローカル 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

前提条件:

ローカル 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

詳細情報: https://modelcontextprotocol.io/quickstart/user

Claude Code

前提条件:

ローカル 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

前提条件:

ローカル 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ユーザーごとのクライアント設定を使用します。

詳細情報: https://docs.windsurf.com/windsurf/mcp

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 から追加します:

  1. MCP 設定 UI にアクセス
  2. + 記号を選択します
  3. スコープを選択:global または local
  4. 名前を入力(例:circleci-remote-mcp
  5. トランスポートプロトコルを選択:stdio
  6. スクリプトへのコマンドパスを入力します
  7. 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_TOKENREQUIRE_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=remotestdio の代わりに HTTP+SSE MCP サーバーを起動します
portコンテナ内の待受ポート(デフォルト: 8000
REQUIRE_REQUEST_TOKENAuthorization: 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_ACCESSREQUIRE_REQUEST_TOKEN=false を非ループバックバインドアドレスで起動する場合に必須(=true)。ポートに到達できるピアはすべて、資格情報なしでサーバーの CIRCLECI_TOKEN アイデンティティとして動作することを了承します。リクエストトークンが必須の場合は効果がありません。
MCP_FILE_OUTPUT_ROOTSファイル読み取り/書き込みツールが使用できる追加ディレクトリのカンマ区切りリスト(例: /srv/reports,/data/exports)。作業ディレクトリ、ホームディレクトリ、一時ディレクトリは常に許可されます。下記の注記を参照してください。

ファイル出力場所(stdio とリモートトランスポートの両方に適用): ファイルシステムパスを受け付けるツール — get_build_failure_logsoutputDir)、download_usage_api_dataoutputDir)、find_underused_resource_classescsvFilePath)— は、サーバーの作業ディレクトリ、ユーザーのホームディレクトリ、システムの一時ディレクトリ内でのみ読み書きできます。これらのルート内では、隠し設定ディレクトリ(~/.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 ヘッダーを検検証します。デフォルトではループバックアドレス(localhost127.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}"

共有トークンサーバーを使用する場合は、--headerAUTH_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: 以下の情報を提供して新しいエクスポートジョブを開始します:

  • orgIdstartDateendDate(最大 32 日間)、outputDir

オプション 2: 以下の情報を提供して既存のエクスポートジョブを確認/ダウンロードします:

  • orgIdjobIdoutputDir

指定された期間の CircleCI 使用状況データを含む CSV ファイルを返します。

[!NOTE] 使用状況データは、コスト最適化分析のために find_underused_resource_classes ツールに入力できます。

find_flaky_tests

テスト実行履歴を分析して、CircleCI プロジェクトのフレークテストを特定します。CircleCI のフレークテスト検出機能を活用します。

このツールは 3 つの方法で使用できます:

  1. プロジェクトスラッグを使用(推奨):

    • 最初に list_followed_projects を使用してプロジェクトを取得し、次に:
    • 例: 「my-project のフレークテストを取得して」
  2. CircleCI プロジェクト URL を使用:

  3. ローカルプロジェクトコンテキストを使用:

    • ワークスペースルートと 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 つの方法で使用できます:

  1. プロジェクトスラッグとブランチを使用(推奨):

    • 最初に list_followed_projects を使用してプロジェクトを取得し、次に:
    • 例: 「main ブランチの my-project のビルド失敗を取得して」
  2. CircleCI URL を使用:

  3. ローカルプロジェクトコンテキストを使用:

    • ワークスペースルート、git リモート URL、ブランチ名を提供してローカルワークスペースから動作します
    • 例: 「現在のブランチで最新の失敗したパイプラインを探して」

このツールは、以下を含むフォーマットされたログを返します:

  • ジョブ名
  • ステップごとの実行詳細
  • 失敗メッセージとコンテキスト
get_job_test_results

CircleCI ジョブのテストメタデータを取得し、IDE から離れることなくテスト結果を分析できます。このツールは 3 つの方法で使用できます:

  1. プロジェクトスラッグとブランチを使用(推奨):

    • 例: 「main ブランチの my-project のテスト結果を取得して」
  2. 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
  3. ローカルプロジェクトコンテキストを使用:

    • ワークスペースルート、git リモート URL、ブランチ名を提供してローカルワークスペースから動作します

このツールは以下を返します:

  • すべてのテストの概要(合計、成功、失敗)
  • 失敗したテストの詳細情報: 名前、クラス、ファイル、エラーメッセージ、所要時間
  • タイミング付きの成功したテストのリスト
  • テスト結果によるフィルタリング

[!NOTE] テストメタデータは CircleCI 設定で構成する必要があります。セットアップ手順についてはテストデータの収集を参照してください。

get_latest_pipeline_status 指定されたブランチの最新パイプラインのステータスを取得します。このツールは次の3つの方法で使用できます:
  1. プロジェクトスラッグとブランチを使用(推奨):

    • 例:「main ブランチの my-project の最新パイプラインのステータスを取得して」
  2. CircleCI プロジェクト URL を使用:

  3. ローカルプロジェクトコンテキストを使用:

    • ワークスペースルート、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つの方法で使用できます:

  1. プロジェクトスラッグとブランチを使用(推奨):

    • まず list_followed_projects を使用してプロジェクトを取得し、次に:
    • 例:「main ブランチの my-project のアーティファクトを一覧表示して」
  2. 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
  3. ローカルプロジェクトコンテキストを使用:

    • ワークスペースルート、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つの方法で使用できます:

  1. プロジェクトスラッグとブランチを使用(推奨):

    • 例:「main ブランチの my-project のパイプラインを実行して」
  2. CircleCI URL を使用:

  3. ローカルプロジェクトコンテキストを使用:

    • ワークスペースルート、git リモート URL、ブランチ名を指定することで、ローカルワークスペースから動作します

ツールはパイプライン実行を監視するためのリンクを返します。

run_rollback_pipeline

CircleCI プロジェクトのロールバックをトリガーします。ツールは対話形式で次の手順を案内します:

  1. プロジェクト選択 — フォロー中のプロジェクトを一覧表示し、選択させます
  2. 環境選択 — 利用可能な環境を一覧表示します(1つだけの場合は自動選択)
  3. コンポーネント選択 — 利用可能なコンポーネントを一覧表示します(1つだけの場合は自動選択)
  4. バージョン選択 — 利用可能なバージョンを表示し、ロールバック対象を選択します
  5. ロールバックモード検出 — ロールバックパイプラインが設定されているか確認します
  6. ロールバックの実行 — 2つのオプション:
    • パイプラインロールバック: ロールバックパイプラインをトリガーします
    • ワークフロー再実行: ワークフロー ID を使用して以前のワークフローを再実行します
  7. 確認 — 実行前に概要を表示して確認します

トラブルシューティング

クイック修正

最も一般的な問題:

  1. パッケージキャッシュをクリア:

    npx clear-npx-cache
    npm cache clean --force
    
  2. 最新バージョンを強制: 設定に @latest を追加:

    "args": ["-y", "@circleci/mcp-server-circleci@latest"]
    
  3. IDE を完全に再起動(ウィンドウの再読み込みだけでなく)

認証の問題
  • 無効なトークンエラー: Personal API TokensCIRCLECI_TOKEN を確認してください
  • 権限エラー: トークンがプロジェクトへの読み取りアクセス権を持っていることを確認してください
  • 環境変数が読み込まれない: echo $CIRCLECI_TOKEN(Mac/Linux)または echo %CIRCLECI_TOKEN%(Windows)でテストしてください
接続とネットワークの問題
  • ベース URL: CIRCLECI_BASE_URLhttps://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 インストールを試してください

それでも解決しない場合:

  1. GitHub Issues で同様の問題を確認してください
  2. 問題を報告する際は OS、Node バージョン、IDE を含めてください
  3. IDE コンソールからの関連エラーメッセージを共有してください

テレメトリ

サーバーはツール使用状況を追跡するための OpenTelemetry メトリクスをサポートしています。DISABLE_TELEMETRY=true を設定しない限り、メトリクスはエクスポートされます。リモートデプロイでは、メトリクスはリクエストと同じトークン(ユーザーごとの PAT または共有サーバー PAT)を使用します。

メトリクス説明
circleci.mcp.tool.invocationsツール呼び出し回数
circleci.mcp.tool.duration_ms実行時間(ms)
circleci.mcp.tool.errorsエラー数

開発

はじめに

  1. リポジトリをクローン:

    git clone https://github.com/CircleCI-Public/mcp-server-circleci.git
    cd mcp-server-circleci
    
  2. 依存関係をインストール:

    pnpm install
    
  3. プロジェクトをビルド:

    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 で確認できます。

  1. 開発サーバーを起動:

    pnpm watch # Keep this running in one terminal
    
  2. 別のターミナルで Inspector を起動:

    pnpm inspector
    
  3. 環境を構成:

    • CIRCLECI_TOKEN を Inspector UI の Environment Variables セクションに追加してください
    • トークンには CircleCI プロジェクトへの読み取りアクセス権が必要です
    • 必要に応じて CircleCI ベース URL を設定してください(デフォルトは https://circleci.com

テスト

  • テストスイートを実行:

    pnpm test
    
  • 開発中はウォッチモードでテストを実行:

    pnpm test:watch
    

より詳細なコントリビューションガイドラインについては、CONTRIBUTING.md を参照してください。