Skip to main content
Glama
mcp-server-circleci

mcp-server-circleci

Official
IMPORTANT

This package is deprecated. Please migrate.

@circleci/mcp-server-circleci is no longer receiving feature work. Use CircleCI's hosted MCP server or the CircleCI CLI MCP instead — see the CircleCI MCP overview.

This repository will be archived. Existing versions remain installable from npm, but running an unmaintained server that holds a CircleCI Personal API Token is not recommended.

If you are running the self-managed remote transport (start=remote), migrate first: the hosted server is its direct replacement and removes the need to operate a network-facing service that brokers your org's token.

CircleCI MCP Server

License: Apache 2.0 CircleCI npm

Model Context Protocol (MCP) is a new, standardized protocol for managing context between large language models (LLMs) and external systems. In this repository, we provide an MCP Server for CircleCI.

Use Cursor, Windsurf, Copilot, Claude, or any MCP-compatible client to interact with CircleCI using natural language — without leaving your IDE.

Tools

Tool

Description

config_helper

Validate and get guidance for your CircleCI configuration

download_usage_api_data

Download usage data from the CircleCI Usage API

find_flaky_tests

Identify flaky tests by analyzing test execution history

find_underused_resource_classes

Find jobs with underused compute resources

get_build_failure_logs

Retrieve detailed failure logs from CircleCI builds

get_job_test_results

Retrieve test metadata and results for CircleCI jobs

get_latest_pipeline_status

Get the status of the latest pipeline for a branch

list_artifacts

List artifacts produced by a CircleCI job

list_component_versions

List all versions for a CircleCI component

list_followed_projects

List all CircleCI projects you're following

rerun_workflow

Rerun a workflow from start or from the failed job

run_pipeline

Trigger a pipeline to run

run_rollback_pipeline

Trigger a rollback for a project

Related MCP server: codemagic_mcp

Installation

Team / centralized deployment: To run one shared remote server for your org (Kubernetes, Docker, etc.) with per-developer or shared CircleCI tokens, see Self-Managed Remote MCP Server.

Prerequisites:

Using NPX in a local MCP Server

Add the following to your Cursor MCP config:

{
  "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 is optional — required for on-prem customers only. MAX_MCP_OUTPUT_LENGTH is optional — maximum output length for MCP responses (default: 50000).

Using Docker in a local MCP Server

Add the following to your Cursor MCP config:

{
  "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"
      }
    }
  }
}

Using a Self-Managed Remote MCP Server

See Self-Managed Remote MCP Server. Use the per-user client configuration and add it to your Cursor MCP config (Cursor Settings → MCP).

Prerequisites:

Using NPX in a local MCP Server

Add the following to .vscode/mcp.json in your project:

{
  "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}"
      }
    }
  }
}

💡 Inputs are prompted on first server start, then stored securely by VS Code.

Using Docker in a local MCP Server

Add the following to .vscode/mcp.json in your project:

{
  "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}"
      }
    }
  }
}

Using a Self-Managed Remote MCP Server

See Self-Managed Remote MCP Server. Use the per-user client configuration in .vscode/mcp.json.

Prerequisites:

Using NPX in a local MCP Server

Add the following to your 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"
      }
    }
  }
}

Using Docker in a local MCP Server

Add the following to your 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"
      }
    }
  }
}

Using a Self-Managed Remote MCP Server

See Self-Managed Remote MCP Server. Create a wrapper script as shown in Claude Desktop and CLI clients, then point your claude_desktop_config.json at it.

To find or create your config file, open Claude Desktop settings, click Developer in the left sidebar, then click Edit Config. The config file is located at:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

For more information: https://modelcontextprotocol.io/quickstart/user

Prerequisites:

Using NPX in a local MCP Server

claude mcp add circleci-mcp-server -e CIRCLECI_TOKEN=your-circleci-token -- npx -y @circleci/mcp-server-circleci@latest

Using Docker in a local MCP Server

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

Using a Self-Managed Remote MCP Server

See Self-Managed Remote MCP Server and the Claude Code client setup there.

Prerequisites:

Using NPX in a local MCP Server

Add the following to your 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"
      }
    }
  }
}

Using Docker in a local MCP Server

Add the following to your 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"
      }
    }
  }
}

Using a Self-Managed Remote MCP Server

See Self-Managed Remote MCP Server. Use the per-user client configuration in your Windsurf mcp_config.json.

For more information: https://docs.windsurf.com/windsurf/mcp

Prerequisites:

MCP client configuration in Amazon Q Developer is stored in JSON format in a file named mcp.json. Two levels of configuration are supported:

  • Global: ~/.aws/amazonq/mcp.json — applies to all workspaces

  • Workspace: .amazonq/mcp.json — specific to the current workspace

If both files exist, their contents are merged. In case of conflict, the workspace config takes precedence.

Using NPX in a local MCP Server

Edit ~/.aws/amazonq/mcp.json or create .amazonq/mcp.json with the following:

{
  "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
    }
  }
}

Using a Self-Managed Remote MCP Server

See Self-Managed Remote MCP Server. Use a wrapper script as shown in Claude Desktop and CLI clients, then register it with q mcp add.

Prerequisites:

Using NPX in a local MCP Server

Edit ~/.aws/amazonq/mcp.json or create .amazonq/mcp.json with the following:

{
  "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
    }
  }
}

Using a Self-Managed Remote MCP Server

See Self-Managed Remote MCP Server. Use a wrapper script as shown in Claude Desktop and CLI clients, then add it via the MCP configuration UI:

  1. Access the MCP configuration UI

  2. Choose the + symbol

  3. Select scope: global or local

  4. Enter a name (e.g. circleci-remote-mcp)

  5. Select transport protocol: stdio

  6. Enter the command path to your script

  7. Click Save

To install CircleCI MCP Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @CircleCI-Public/mcp-server-circleci --client claude

Self-Managed Remote MCP Server

Run the MCP server centrally (for example on Kubernetes or Docker) so your team shares one deployment. Choose how developers authenticate:

Choose a deployment mode

Mode

When to use

Server setup

Client setup

CircleCI audit trail

Per-user tokens (recommended)

Teams with SSO-backed Personal API Tokens

REQUIRE_REQUEST_TOKEN=true, no server PAT

Each dev forwards their PAT

Per developer

Shared token (interim)

Quick rollout, single service identity OK

CIRCLECI_TOKEN on server, REQUIRE_REQUEST_TOKEN=false (explicit opt-out)

No auth header needed

Single shared identity

Security: Request authentication is on by default in remote mode. The shared-token mode disables it (REQUIRE_REQUEST_TOKEN=false), making every caller able to act as the server's CIRCLECI_TOKEN identity with no credentials — including triggering pipelines with arbitrary config. Only enable it on a network you fully trust, and prefer per-user tokens otherwise. Terminating TLS at an ingress provides encryption, not authentication.

Because that combination is unsafe on a public interface, the server refuses to start when REQUIRE_REQUEST_TOKEN=false is combined with a non-loopback bind address, unless you explicitly accept the risk with MCP_ALLOW_UNAUTHENTICATED_NETWORK_ACCESS=true. The Host/Origin check is not a substitute for authentication — see DNS-rebinding protection below.

1. Deploy the server

Both modes use remote HTTP mode (start=remote). Publish port 8000 (or your chosen port).

Per-user tokens (recommended) — accessed via mcp-remote from localhost:

docker run --rm -p 8000:8000 \
  -e start=remote \
  -e port=8000 \
  -e REQUIRE_REQUEST_TOKEN=true \
  circleci/mcp-server-circleci

Per-user tokens (recommended) — accessed via mcp-remote from a public hostname:

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

Shared token (interim) — accessed via mcp-remote from a public hostname:

Because this mode serves the org's PAT to any caller with no credential, it must be run only where the published port is unreachable from untrusted networks, and you must acknowledge that explicitly or the server will refuse to start:

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

Prefer putting authentication in front of the port instead — an ingress that requires SSO, mTLS, or an API key — or switch to per-user tokens above.

Environment variables:

Variable

Description

start=remote

Starts the HTTP+SSE MCP server instead of stdio

port

Listening port inside the container (default: 8000)

REQUIRE_REQUEST_TOKEN

Reject requests without Authorization: Bearer or Circle-Token header. Defaults to required; set REQUIRE_REQUEST_TOKEN=false to allow unauthenticated requests (shared-token mode)

CIRCLECI_TOKEN

Shared fallback PAT for all requests when per-user headers are not sent

CIRCLECI_BASE_URL

Optional — required for on-prem only (default: https://circleci.com)

DISABLE_TELEMETRY=true

Opt out of usage metrics export

MCP_ALLOWED_HOSTS

Comma-separated list of additional Host header values to allow (e.g. my-mcp.example.com,my-mcp.example.com:443). Loopback hostnames are always allowed. Required for any non-loopback deployment.

MCP_ALLOWED_ORIGINS

Comma-separated list of additional Origin header values to allow (e.g. https://my-app.example.com). Loopback origins are always allowed. Only needed when a browser directly reaches this server (not via mcp-remote).

MCP_BIND_HOST

Network interface to bind to (default: 0.0.0.0). Set to 127.0.0.1 to restrict to loopback only (not compatible with Docker -p port mapping).

MCP_ALLOW_UNAUTHENTICATED_NETWORK_ACCESS

Required (=true) to start with REQUIRE_REQUEST_TOKEN=false on a non-loopback bind address. Acknowledges that any peer able to reach the port acts as the server's CIRCLECI_TOKEN identity without a credential. Has no effect when request tokens are required.

MCP_FILE_OUTPUT_ROOTS

Comma-separated list of additional directories that file-reading/writing tools may use (e.g. /srv/reports,/data/exports). The working directory, home directory and temp directory are always allowed. See the note below.

File output locations (applies to both stdio and remote transports): Tools that accept a filesystem path — get_build_failure_logs (outputDir), download_usage_api_data (outputDir) and find_underused_resource_classes (csvFilePath) — may only read and write inside the server's working directory, the user's home directory, and the system temp directory. Within those roots, hidden configuration directories (~/.ssh, ~/.aws, ~/.config, .git, …), node_modules and launch-agent directories are rejected, as are symlinks resolving outside the permitted roots. System directories (/etc, /usr, /bin, /System, /Library, %SystemRoot%, …) are refused unconditionally and cannot be re-enabled. Output files are never written through a symlink.

If your checkout lives outside those roots — /workspace in a container, /srv, /opt, a secondary volume such as /Volumes/work — set MCP_FILE_OUTPUT_ROOTS to that directory, otherwise those paths are rejected. For a stdio server the working directory is usually already the project root, so no configuration is needed. This matters most for the remote transport, where the paths come from network clients rather than the local user.

DNS-rebinding protection (not authentication): The remote transport validates the Host header on every /mcp request. By default only loopback addresses (localhost, 127.0.0.1, [::1]) are accepted. Public deployments must set MCP_ALLOWED_HOSTS to the hostname clients use, or all /mcp requests will receive 403 Forbidden. The /ping health-check endpoint is not guarded so load-balancer probes continue to work regardless of Host.

The Origin header (sent by browsers) is also validated when present. Non-browser clients such as mcp-remote never send Origin, so they are unaffected by this check.

This check is not an access control and must not be relied on as one. Both headers are chosen by the caller, so any non-browser client — curl, a script, a raw socket — can send an allowed Host and omit Origin to satisfy it. Its only purpose is to stop a browser from being aimed at the server by attacker-controlled DNS, which is the DNS-rebinding threat. Authenticating callers is the job of REQUIRE_REQUEST_TOKEN (or an authenticating proxy in front of the port). Requiring an Origin header would break every legitimate CLI client while stopping no attacker.

Behind a reverse proxy: If your proxy rewrites Host to the backend address (nginx's default), add proxy_set_header Host $host; to pass the original hostname through, then set MCP_ALLOWED_HOSTS to that public hostname. Alternatively, set MCP_ALLOWED_HOSTS to whatever hostname the proxy does forward.

The server accepts per-request tokens via:

  • Authorization: Bearer <circleci-pat>

  • Circle-Token: <circleci-pat>

If a client sends a header token, it takes precedence over CIRCLECI_TOKEN on the server.

Telemetry metrics recorded during a request are exported using the same token as that request.

2. Configure clients

Most MCP clients only support local (stdio) processes. Use mcp-remote, a third-party stdio-to-HTTP bridge, to connect them to your remote server.

URL scheme: Use http://localhost:8000/mcp with --allow-http for local testing. In production, terminate TLS at your ingress/load balancer and use https://your-host/mcp without --allow-http.

Windows: Avoid spaces around the colon in --header values. Put the full Bearer <token> value in an environment variable.

Security: Examples use npx for convenience. For production or team rollouts, pin a specific version in your MCP config (for example mcp-remote@0.1.38 instead of mcp-remote). Do not use versions below 0.1.16 (CVE-2025-6514).

Client configuration: per-user tokens

Each developer forwards their own CircleCI Personal API Token on every request:

{
  "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}"
      }
    }
  }
}

Replace http://localhost:8000/mcp with your team's server URL. Cursor and VS Code support ${input:...} prompts; other clients can set AUTH_HEADER directly.

Client configuration: shared token

When the server has CIRCLECI_TOKEN set and is started with REQUIRE_REQUEST_TOKEN=false (request auth is on by default and must be explicitly disabled, and a non-loopback bind additionally requires MCP_ALLOW_UNAUTHENTICATED_NETWORK_ACCESS=true), clients do not need to send a token:

{
  "mcpServers": {
    "circleci-mcp-server-remote": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "http://localhost:8000/mcp",
        "--allow-http"
      ]
    }
  }
}

Claude Desktop and CLI clients

Create a wrapper script (e.g. 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}"

Make it executable (chmod +x circleci-remote-mcp.sh), then reference it from your MCP config:

{
  "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}"

Omit --header and AUTH_HEADER when using a shared-token server.

3. Verify the deployment

# 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"}}}'

Demo

Example: "Find the latest failed pipeline on my branch and get logs" — see the wiki for more examples.

https://github.com/user-attachments/assets/3c765985-8827-442a-a8dc-5069e01edb74

Tool Details

Assists with CircleCI configuration tasks by providing guidance and validation.

  • Validates your .circleci/config.yml for syntax and semantic errors

  • Provides detailed validation results and configuration recommendations

  • Example: "Validate my CircleCI config"

Downloads usage data from the CircleCI Usage API for a given organization. Accepts flexible date input (e.g., "March 2025" or "last month"). Cloud-only feature.

Option 1: Start a new export job by providing:

  • orgId, startDate, endDate (max 32 days), outputDir

Option 2: Check/download an existing export job by providing:

  • orgId, jobId, outputDir

Returns a CSV file with CircleCI usage data for the specified time frame.

NOTE

Usage data can be fed into thefind_underused_resource_classes tool for cost optimization analysis.

Identifies flaky tests in your CircleCI project by analyzing test execution history. Leverages the flaky test detection feature in CircleCI.

This tool can be used in three ways:

  1. Using Project Slug (Recommended):

    • First use list_followed_projects to get your projects, then:

    • Example: "Get flaky tests for my-project"

  2. Using CircleCI Project URL:

  3. Using Local Project Context:

    • Works from your local workspace by providing workspace root and git remote URL

    • Example: "Find flaky tests in my current project"

Output modes:

  • Text (default): Returns flaky test details in text format

  • File (requires FILE_OUTPUT_DIRECTORY env var): Creates a directory with flaky test details

Analyzes a CircleCI usage data CSV file to find jobs with average or max CPU/RAM usage below a given threshold (default: 40%).

Provide a CSV file obtained from download_usage_api_data.

Returns a markdown list of underused jobs organized by project and workflow — useful for identifying cost optimization opportunities.

Retrieves detailed failure logs from CircleCI builds. This tool can be used in three ways:

  1. Using Project Slug and Branch (Recommended):

    • First use list_followed_projects to get your projects, then:

    • Example: "Get build failures for my-project on the main branch"

  2. Using CircleCI URLs:

  3. Using Local Project Context:

    • Works from your local workspace by providing workspace root, git remote URL, and branch name

    • Example: "Find the latest failed pipeline on my current branch"

The tool returns formatted logs including:

  • Job names

  • Step-by-step execution details

  • Failure messages and context

Retrieves test metadata for CircleCI jobs, allowing you to analyze test results without leaving your IDE. This tool can be used in three ways:

  1. Using Project Slug and Branch (Recommended):

    • Example: "Get test results for my-project on the main branch"

  2. Using CircleCI URL:

    • Job URL: https://app.circleci.com/pipelines/github/org/repo/123/workflows/abc-def/jobs/789

    • Workflow URL: https://app.circleci.com/pipelines/github/org/repo/123/workflows/abc-def

    • Pipeline URL: https://app.circleci.com/pipelines/github/org/repo/123

  3. Using Local Project Context:

    • Works from your local workspace by providing workspace root, git remote URL, and branch name

The tool returns:

  • Summary of all tests (total, successful, failed)

  • Detailed info on failed tests: name, class, file, error message, duration

  • List of successful tests with timing

  • Filter by test result

NOTE

Test metadata must be configured in your CircleCI config. SeeCollect Test Data for setup instructions.

Retrieves the status of the latest pipeline for a given branch. This tool can be used in three ways:

  1. Using Project Slug and Branch (Recommended):

    • Example: "Get the status of the latest pipeline for my-project on the main branch"

  2. Using CircleCI Project URL:

  3. Using Local Project Context:

    • Works from your local workspace by providing workspace root, git remote URL, and branch name

Example output:

---
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

Retrieves the list of artifacts produced by a CircleCI job. This tool can be used in three ways:

  1. Using Project Slug and Branch (Recommended):

    • First use list_followed_projects to get your projects, then:

    • Example: "List artifacts for my-project on the main branch"

  2. Using CircleCI URL:

    • Job URL: https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def/jobs/789

    • Workflow URL: https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def

    • Pipeline URL: https://app.circleci.com/pipelines/gh/organization/project/123

  3. Using Local Project Context:

    • Works from your local workspace by providing workspace root, git remote URL, and branch name

Useful for:

  • Finding download URLs for build artifacts (binaries, reports, logs)

  • Checking what artifacts were produced by a pipeline run

Lists all versions for a specific CircleCI component in an environment. Includes deployment status, commit information, and timestamps.

The tool will prompt you to select the component and environment if not provided.

Useful for:

  • Identifying which version is currently live

  • Selecting target versions for rollback operations

  • Getting deployment details (pipeline, workflow, job)

Lists all projects that the user is following on CircleCI.

  • Shows all projects you have access to with their projectSlug

  • Example: "List my CircleCI projects"

Example output:

Projects followed:
1. my-project (projectSlug: gh/organization/my-project)
2. another-project (projectSlug: gh/organization/another-project)
NOTE

TheprojectSlug (not the project name) is required for many other CircleCI tools.

Reruns a workflow from its start or from the failed job.

Returns the ID of the newly-created workflow and a link to monitor it.

Triggers a pipeline to run. This tool can be used in three ways:

  1. Using Project Slug and Branch (Recommended):

    • Example: "Run the pipeline for my-project on the main branch"

  2. Using CircleCI URL:

  3. Using Local Project Context:

    • Works from your local workspace by providing workspace root, git remote URL, and branch name

The tool returns a link to monitor the pipeline execution.

Triggers a rollback for a CircleCI project. The tool interactively guides you through:

  1. Project Selection — lists followed projects for you to choose from

  2. Environment Selection — lists available environments (auto-selects if only one)

  3. Component Selection — lists available components (auto-selects if only one)

  4. Version Selection — displays available versions; you select the target for rollback

  5. Rollback Mode Detection — checks if a rollback pipeline is configured

  6. Execute Rollback — two options:

    • Pipeline Rollback: triggers the rollback pipeline

    • Workflow Rerun: reruns a previous workflow using its workflow ID

  7. Confirmation — summarizes and confirms before execution

Troubleshooting

Most common issues:

  1. Clear package caches:

    npx clear-npx-cache
    npm cache clean --force
  2. Force latest version: Add @latest to your config:

    "args": ["-y", "@circleci/mcp-server-circleci@latest"]
  3. Restart your IDE completely (not just reload window)

  • Invalid token errors: Verify your CIRCLECI_TOKEN in Personal API Tokens

  • Permission errors: Ensure the token has read access to your projects

  • Environment variables not loading: Test with echo $CIRCLECI_TOKEN (Mac/Linux) or echo %CIRCLECI_TOKEN% (Windows)

  • Base URL: Confirm CIRCLECI_BASE_URL is https://circleci.com

  • Corporate networks: Configure npm proxy settings if behind a firewall

  • Firewall blocking: Check if security software blocks package downloads

  • Node.js version: Ensure it satisfies ^22.23.4 || ^24.22.1 || >=26.12.1 with node --version

  • Update Node.js: Consider latest LTS if experiencing compatibility issues

  • Package manager: Verify npm/pnpm is working: npm --version

  • Config file location: Double-check the path for your OS

  • Syntax errors: Validate JSON syntax in your config file

  • Console logs: Check the IDE developer console for specific errors

  • Try a different IDE: Test in another supported editor to isolate the issue

Hanging processes — kill existing MCP processes:

# Mac/Linux:
pkill -f "mcp-server-circleci"

# Windows:
taskkill /f /im node.exe

Port conflicts: Restart your IDE if the connection seems blocked.

  • Test package directly: npx @circleci/mcp-server-circleci@latest --help

  • Verbose logging: DEBUG=* npx @circleci/mcp-server-circleci@latest

  • Docker fallback: Try Docker installation if npx fails consistently

Still need help?

  1. Check GitHub Issues for similar problems

  2. Include your OS, Node version, and IDE when reporting issues

  3. Share relevant error messages from the IDE console

Telemetry

The server supports OpenTelemetry metrics for tracking tool usage. Metrics are exported unless you set DISABLE_TELEMETRY=true. On remote deployments, metrics use the same token as the request (per-user PAT or shared server PAT).

Metric

Description

circleci.mcp.tool.invocations

Tool invocation count

circleci.mcp.tool.duration_ms

Execution time in ms

circleci.mcp.tool.errors

Error count

Development

Getting Started

  1. Clone the repository:

    git clone https://github.com/CircleCI-Public/mcp-server-circleci.git
    cd mcp-server-circleci
  2. Install dependencies:

    pnpm install
  3. Build the project:

    pnpm build

Building Docker Container

You can build the Docker container locally using:

docker build -t circleci:mcp-server-circleci .

This will create a Docker image tagged as circleci:mcp-server-circleci that you can use with any MCP client.

Local stdio mode (single developer, token on the client):

docker run --rm -i \
  -e CIRCLECI_TOKEN=your-circleci-token \
  -e CIRCLECI_BASE_URL=https://circleci.com \
  circleci/mcp-server-circleci

Remote mode (centralized server for a team): see Self-Managed Remote MCP Server.

Development with MCP Inspector

The easiest way to iterate on the MCP Server is using the MCP inspector. You can learn more about the MCP inspector at https://modelcontextprotocol.io/docs/tools/inspector

  1. Start the development server:

    pnpm watch # Keep this running in one terminal
  2. In a separate terminal, launch the inspector:

    pnpm inspector
  3. Configure the environment:

    • Add your CIRCLECI_TOKEN to the Environment Variables section in the inspector UI

    • The token needs read access to your CircleCI projects

    • Optionally set your CircleCI Base URL (defaults to https://circleci.com)

Testing

  • Run the test suite:

    pnpm test
  • Run tests in watch mode during development:

    pnpm test:watch

For more detailed contribution guidelines, see CONTRIBUTING.md

Available Tools

16 tools
analyze_diffA

This tool is used to analyze a git diff (unstaged, staged, or all changes) against IDE rules to identify rule violations. By default, the tool will use the staged changes, unless the user explicitly asks for unstaged or all changes.

Parameters:

  • params: An object containing:

    • speedMode: boolean - A mode that can be enabled to speed up the analysis. Default value is false.

    • filterBy: enum - "Violations" | "Compliants" | "Human Review Required" | "None" - A filter that can be applied to set the focus of the analysis. Default is None.

    • diff: string - A git diff string.

    • rules: string - Rules to use for analysis, found in the rules subdirectory of the IDE workspace settings. Combine all rules from multiple files by separating them with ---

Returns:

  • A list of rule violations found in the git diff.

Inputs: params.

config_helperB

This tool helps analyze and validate and fix CircleCI configuration files.

Parameters:

  • params: An object containing:

    • configFile: string - The full contents of the CircleCI config file as a string. This should be the raw YAML content, not a file path.

Example usage: { "params": { "configFile": "version: 2.1 orbs: node: circleci/node@7 ..." } }

Note: The configFile content should be provided as a properly escaped string with newlines represented as .

Tool output instructions: - If the config is invalid, the tool will return the errors and the original config. Use the errors to fix the config. - If the config is valid, do nothing.

Inputs: params.

create_prompt_templateA

ABOUT THIS TOOL:

  • This tool is part of a toolchain that generates and provides test cases for a prompt template.

  • This tool helps an AI assistant to generate a prompt template based on one of the following:

    1. feature requirements defined by a user - in which case the tool will generate a new prompt template based on the feature requirements.

    2. a pre-existing prompt or prompt template that a user wants to test, evaluate, or modify - in which case the tool will convert it into a more structured and testable prompt template while leaving the original prompt language relatively unchanged.

  • This tool will return a structured prompt template (e.g. template) along with a context schema (e.g. contextSchema) that defines the expected input parameters for the prompt template.

  • In some cases, a user will want to add test coverage for ALL of the prompts in a given application. In these cases, the AI agent should use this tool to generate a prompt template for each prompt in the application, and should check the entire application for AI prompts that are not already covered by a prompt template in the ./prompts directory.

WHEN SHOULD THIS TOOL BE TRIGGERED?

  • This tool should be triggered whenever the user provides requirements for a new AI-enabled application or a new AI-enabled feature of an existing application (i.e. one that requires a prompt request to an LLM or any AI model).

  • This tool should also be triggered if the user provides a pre-existing prompt or prompt template from their codebase that they want to test, evaluate, or modify.

  • This tool should be triggered even if there are pre-existing files in the ./prompts directory with the <relevant-name>.prompt.yml convention (e.g. bedtime-story-generator.prompt.yml, plant-care-assistant.prompt.yml, customer-support-chatbot.prompt.yml, etc.). Similar files should NEVER be generated directly by the AI agent. Instead, the AI agent should use this tool to first generate a new prompt template.

PARAMETERS:

  • params: object

    • prompt: string (the feature requirements or pre-existing prompt/prompt template that will be used to generate a prompt template. Can be a multi-line string.)

    • promptOrigin: "codebase" | "requirements" (indicates whether the prompt comes from an existing codebase or from new requirements)

    • model: string (the model that the prompt template will be tested against. Explicitly specify the model if it can be inferred from the codebase. Otherwise, defaults to gpt-4.1-mini.)

    • temperature: number (the temperature of the prompt template. Explicitly specify the temperature if it can be inferred from the codebase. Otherwise, defaults to 1.)

EXAMPLE USAGE (from new requirements): { "params": { "prompt": "Create an app that takes any topic and an age (in years), then renders a 1-minute bedtime story for a person of that age.", "promptOrigin": "requirements" "model": "gpt-4.1-mini" "temperature": 1.0 } }

EXAMPLE USAGE (from pre-existing prompt/prompt template in codebase): { "params": { "prompt": "The user wants a bedtime story about {{topic}} for a person of age {{age}} years old. Please craft a captivating tale that captivates their imagination and provides a delightful bedtime experience.", "promptOrigin": "codebase" "model": "claude-3-5-sonnet-latest" "temperature": 0.7 } }

TOOL OUTPUT INSTRUCTIONS:

  • The tool will return...

    • a template that reformulates the user's prompt into a more structured format.

    • a contextSchema that defines the expected input parameters for the template.

    • a promptOrigin that indicates whether the prompt comes from an existing prompt or prompt template in the user's codebase or from new requirements.

  • The tool output -- the template, contextSchema, and promptOrigin -- will also be used as input to the recommend_prompt_template_tests tool to generate a list of recommended tests that can be used to test the prompt template.

Inputs: params.

download_usage_api_dataA
⚠️ **MANDATORY: The handler will REJECT any call that does not include BOTH outputDir and originalUserMessage. These parameters are REQUIRED for all tool calls.**

⚠️ **MANDATORY OUTPUT DIRECTORY SELECTION FOR AI AGENTS:**
1. If the project root (workspace root) is available (e.g., via `workspaceRoot` or known repository context), you MUST pass it as the `outputDir` parameter.
2. If the project root is not available, you MUST use the user's Downloads folder (e.g., `~/Downloads` or `%USERPROFILE%\Downloads`) as the `outputDir` parameter.
3. Only if neither is available, use the current working directory (`process.cwd()`).
4. **Never omit the `outputDir` parameter. Always make the output location explicit.**
5. **Omitting `outputDir` is a critical error. Tool calls without `outputDir` may be rejected or flagged as incorrect. Repeated violations may be treated as a bug in the AI agent.**
6. **AI agents MUST validate their tool calls to ensure `outputDir` is present before execution.**

Downloads usage data from the CircleCI Usage API for a given organization and date range.
This tool both starts the export job and downloads the resulting CSV file when ready.
Required parameters: orgId, startDate, endDate, outputDir.

**outputDir (required):**
The directory where the usage data CSV will be saved.
- You MUST provide `outputDir` for every tool call.
- The file will be saved in the specified directory.
- Omitting `outputDir` will result in an error.

**Directory Selection Instructions for AI Agents:**
- If the project root is available (e.g., via `workspaceRoot`, `outputDir`, or known repository context), always use it as the output directory for file outputs.
- If no project root is available (e.g., running in the user's home directory or a generic environment), use the user's Downloads folder (e.g., `~/Downloads` or `%USERPROFILE%\Downloads`)
- If neither is available, fall back to the current working directory.
- Never place output files in a location that is hard to discover for the user.
- **Always double-check that `outputDir` is present in your tool call.**
- **Always double-check that `originalUserMessage` is present in your tool call.**

This ensures that downloaded usage data is always saved in a location that is relevant and easy for the user to find, and that the output is always copy-paste friendly for status checks, regardless of the environment in which the tool is run.

Inputs: params.

find_flaky_testsA
This tool retrieves information about flaky tests in a CircleCI project. 

The agent receiving this output MUST analyze the flaky test data and implement appropriate fixes based on the specific issues identified.

CRITICAL REQUIREMENTS:
1. Truncation Handling (HIGHEST PRIORITY):
   - ALWAYS check for <MCPTruncationWarning> in the output
   - When present, you MUST start your response with:
     "WARNING: The logs have been truncated. Only showing the most recent entries. Earlier build failures may not be visible."
   - Only proceed with log analysis after acknowledging the truncation

Input options (EXACTLY ONE of these THREE options must be used):

Option 1 - Project Slug:
- projectSlug: The project slug obtained from listFollowedProjects tool (e.g., "gh/organization/project")

Option 2 - Direct URL (provide ONE of these):
- projectURL: The URL of the CircleCI project in any of these formats:
  * Project URL: https://app.circleci.com/pipelines/gh/organization/project
  * Pipeline URL: https://app.circleci.com/pipelines/gh/organization/project/123
  * Workflow URL: https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def
  * Job URL: https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def/jobs/xyz

Option 3 - Project Detection (ALL of these must be provided together):
- workspaceRoot: The absolute path to the workspace root
- gitRemoteURL: The URL of the git remote repository

Additional Requirements:
- Never call this tool with incomplete parameters
- If using Option 1, make sure to extract the projectSlug exactly as provided by listFollowedProjects
- If using Option 2, the URLs MUST be provided by the user - do not attempt to construct or guess URLs
- If using Option 3, BOTH parameters (workspaceRoot, gitRemoteURL) must be provided
- If none of the options can be fully satisfied, ask the user for the missing information before making the tool call

Inputs: params.

find_underused_resource_classesA
Analyzes a CircleCI usage data CSV file to find jobs/resource classes with average or max CPU/RAM usage below a given threshold (default 40%).
This helps identify underused resource classes that may be oversized for their workload.

Required parameter:
- csvFilePath: Path to the usage data CSV file (string). IMPORTANT: This must be an absolute path. If you are given a relative path, you must resolve it to an absolute path before calling this tool.

Optional parameter:
- threshold: Usage percentage threshold (number, default 40)

The tool expects the CSV to have columns: job_name, resource_class, median_cpu_utilization_pct, max_cpu_utilization_pct, median_ram_utilization_pct, max_ram_utilization_pct (case-insensitive). These required columns are a subset of the columns in the CircleCI usage API output and the tool will work with the full set of columns from the usage API CSV.
It returns a summary report listing all jobs/resource classes where any of these metrics is below the threshold.

Inputs: params.

get_build_failure_logsA
This tool helps debug CircleCI build failures by retrieving failure logs.

CRITICAL REQUIREMENTS:
1. Truncation Handling (HIGHEST PRIORITY):
   - ALWAYS check for <MCPTruncationWarning> in the output
   - When present, you MUST start your response with:
     "WARNING: The logs have been truncated. Only showing the most recent entries. Earlier build failures may not be visible."
   - Only proceed with log analysis after acknowledging the truncation

Input options (EXACTLY ONE of these THREE options must be used):

Option 1 - Project Slug and branch (BOTH required):
- projectSlug: The project slug obtained from listFollowedProjects tool (e.g., "gh/organization/project")
- branch: The name of the branch (required when using projectSlug)

Option 2 - Direct URL (provide ONE of these):
- projectURL: The URL of the CircleCI project in any of these formats:
  * Project URL: https://app.circleci.com/pipelines/gh/organization/project
  * Pipeline URL: https://app.circleci.com/pipelines/gh/organization/project/123
  * Legacy Job URL: https://circleci.com/pipelines/gh/organization/project/123
  * Workflow URL: https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def
  * Job URL: https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def/jobs/xyz

Option 3 - Project Detection (ALL of these must be provided together):
- workspaceRoot: The absolute path to the workspace root
- gitRemoteURL: The URL of the git remote repository
- branch: The name of the current branch

Recommended Workflow:
1. Use listFollowedProjects tool to get a list of projects
2. Extract the projectSlug from the chosen project (format: "gh/organization/project")
3. Use that projectSlug with a branch name for this tool

Additional Requirements:
- Never call this tool with incomplete parameters
- If using Option 1, make sure to extract the projectSlug exactly as provided by listFollowedProjects
- If using Option 2, the URLs MUST be provided by the user - do not attempt to construct or guess URLs
- If using Option 3, ALL THREE parameters (workspaceRoot, gitRemoteURL, branch) must be provided
- If none of the options can be fully satisfied, ask the user for the missing information before making the tool call

Inputs: params.

get_job_test_resultsA
This tool retrieves test metadata for a CircleCI job.

PRIORITY USE CASE:
- When asked "are tests passing in CI?" or similar questions about test status
- When asked to "fix failed tests in CI" or help with CI test failures
- Use this tool to check if tests are passing in CircleCI and identify failed tests

Common use cases:
- Get test metadata for a specific job
- Get test metadata for all jobs in a project
- Get test metadata for a specific branch
- Get test metadata for a specific pipeline
- Get test metadata for a specific workflow
- Get test metadata for a specific job

CRITICAL REQUIREMENTS:
1. Truncation Handling (HIGHEST PRIORITY):
   - ALWAYS check for <MCPTruncationWarning> in the output
   - When present, you MUST start your response with:
     "WARNING: The test results have been truncated. Only showing the most recent entries. Some test data may not be visible."
   - Only proceed with test result analysis after acknowledging the truncation

2. Test Result Filtering:
   - Use filterByTestsResult parameter to filter test results:
     * filterByTestsResult: 'failure' - Show only failed tests
     * filterByTestsResult: 'success' - Show only successful tests
   - When looking for failed tests, ALWAYS set filterByTestsResult to 'failure'
   - When checking if tests are passing, set filterByTestsResult to 'success'

Input options (EXACTLY ONE of these THREE options must be used):

Option 1 - Project Slug and branch (BOTH required):
- projectSlug: The project slug obtained from listFollowedProjects tool (e.g., "gh/organization/project")
- branch: The name of the branch (required when using projectSlug)

Option 2 - Direct URL (provide ONE of these):
- projectURL: The URL of the CircleCI job in any of these formats:
  * Job URL: https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def/jobs/789
  * Workflow URL: https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def
  * Pipeline URL: https://app.circleci.com/pipelines/gh/organization/project/123

Option 3 - Project Detection (ALL of these must be provided together):
- workspaceRoot: The absolute path to the workspace root
- gitRemoteURL: The URL of the git remote repository
- branch: The name of the current branch

For simple test status checks (e.g., "are tests passing in CI?") or fixing failed tests, prefer Option 1 with a recent pipeline URL if available.

Additional Requirements:
- Never call this tool with incomplete parameters
- If using Option 1, make sure to extract the projectSlug exactly as provided by listFollowedProjects and include the branch parameter
- If using Option 2, the URL MUST be provided by the user - do not attempt to construct or guess URLs
- If using Option 3, ALL THREE parameters (workspaceRoot, gitRemoteURL, branch) must be provided
- If none of the options can be fully satisfied, ask the user for the missing information before making the tool call

Inputs: params.

get_latest_pipeline_statusA
This tool retrieves the status of the latest pipeline for a CircleCI project. It can be used to check pipeline status, get latest build status, or view current pipeline state.

Common use cases:
- Check latest pipeline status
- Get current build status
- View pipeline state
- Check build progress
- Get pipeline information

Input options (EXACTLY ONE of these THREE options must be used):

Option 1 - Project Slug and branch (BOTH required):
- projectSlug: The project slug obtained from listFollowedProjects tool (e.g., "gh/organization/project")
- branch: The name of the branch (required when using projectSlug)

Option 2 - Direct URL (provide ONE of these):
- projectURL: The URL of the CircleCI project in any of these formats:
  * Project URL: https://app.circleci.com/pipelines/gh/organization/project
  * Pipeline URL: https://app.circleci.com/pipelines/gh/organization/project/123
  * Workflow URL: https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def
  * Job URL: https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def/jobs/xyz
  * Legacy Job URL: https://circleci.com/gh/organization/project/123

Option 3 - Project Detection (ALL of these must be provided together):
- workspaceRoot: The absolute path to the workspace root
- gitRemoteURL: The URL of the git remote repository
- branch: The name of the current branch

Recommended Workflow:
1. Use listFollowedProjects tool to get a list of projects
2. Extract the projectSlug from the chosen project (format: "gh/organization/project")
3. Use that projectSlug with a branch name for this tool

Additional Requirements:
- Never call this tool with incomplete parameters
- If using Option 1, make sure to extract the projectSlug exactly as provided by listFollowedProjects
- If using Option 2, the URLs MUST be provided by the user - do not attempt to construct or guess URLs
- If using Option 3, ALL THREE parameters (workspaceRoot, gitRemoteURL, branch) must be provided
- If none of the options can be fully satisfied, ask the user for the missing information before making the tool call

Inputs: params.

list_component_versionsA
 This tool lists all versions for a CircleCI component. It guides you through a multi-step process to gather the required information and provides lists of available options when parameters are missing.

 **Initial Requirements:**
 - You need either a `projectSlug` (from `listFollowedProjects`) or a `projectID`. The tool will automatically resolve the `orgID` from either of these.

 **Typical Flow:**
 1. **Start:** User requests component versions or deployment information.
 2. **Project Information:** Provide either `projectSlug` or `projectID`. The tool will automatically resolve the `orgID` and `projectID` as needed.
 3. **Environment Selection:** If `environmentID` is not provided, the tool will list all available environments for the organization and prompt the user to select one. Always return all available values without categorizing them.
 4. **Component Selection:** If `componentID` is not provided, the tool will list all available components for the project and prompt the user to select one. Always return all available values without categorizing them.
 5. **Version Listing:** Once both `environmentID` and `componentID` are provided, the tool will list all versions for that component in the specified environment.
 6. **Selection:** User selects a version from the list for subsequent operations.

 **Parameters:**
 - `projectSlug` (optional): The project slug from `listFollowedProjects` (e.g., "gh/organization/project"). Either this or `projectID` must be provided.
 - `projectID` (optional): The CircleCI project ID (UUID). Either this or `projectSlug` must be provided.
 - `orgID` (optional): The organization ID. If not provided, it will be automatically resolved from `projectSlug` or `projectID`.
 - `environmentID` (optional): The environment ID. If not provided, available environments will be listed.
 - `componentID` (optional): The component ID. If not provided, available components will be listed.

 **Behavior:**
 - The tool will guide you through the selection process step by step.
 - Automatically resolves `orgID` from `projectSlug` or `projectID` when needed.
 - When `environmentID` is missing, it lists environments and waits for user selection.
 - When `componentID` is missing (but `environmentID` is provided), it lists components and waits for user selection.
 - Only when both `environmentID` and `componentID` are provided will it list the actual component versions.
 - Make multiple calls to this tool as you gather the required parameters.

 **Common Use Cases:**
 - Identify which versions were deployed for a component
 - Identify which versions are live for a component
 - Identify which versions were deployed to an environment for a component
 - Identify which versions are not live for a component in an environment
 - Select a version for rollback or deployment operations
 - Obtain version name, namespace, and environment details for other CircleCI tools

 **Returns:**
 - When missing `environmentID`: A list of available environments with their IDs
 - When missing `componentID`: A list of available components with their IDs  
 - When both `environmentID` and `componentID` provided: A list of component versions with version name, namespace, environment ID, and is_live status

 **Important Notes:**
 - This tool requires multiple calls to gather all necessary information.
 - Either `projectSlug` or `projectID` must be provided; the tool will resolve the missing project information automatically.
 - The tool will prompt for missing `environmentID` and `componentID` by providing selection lists.
 - Always use the exact IDs returned by the tool in subsequent calls.
 - If pagination limits are reached, the tool will indicate that not all items could be displayed.

 **IMPORTANT:** Do not automatically run additional tools after this tool is called. Wait for explicit user instruction before executing further tool calls. The LLM MUST NOT invoke other CircleCI tools until receiving clear instruction from the user about what to do next, even if the user selects an option. It is acceptable to list out tool call options for the user to choose from, but do not execute them until instructed.
 

Inputs: params.

list_followed_projectsA
This tool lists all projects that the user is following on CircleCI.

Common use cases:
- Identify which CircleCI projects are available to the user
- Select a project for subsequent operations
- Obtain the projectSlug needed for other CircleCI tools

Returns:
- A list of projects that the user is following on CircleCI
- Each entry includes the project name and its projectSlug

Workflow:
1. Run this tool to see available projects
2. User selects a project from the list
3. The LLM should extract and use the projectSlug (not the project name) from the selected project for subsequent tool calls
4. The projectSlug is required for many other CircleCI tools, and will be used for those tool calls after a project is selected

Note: If pagination limits are reached, the tool will indicate that not all projects could be displayed.

IMPORTANT: Do not automatically run any additional tools after this tool is called. Wait for explicit user instruction before executing further tool calls. The LLM MUST NOT invoke any other CircleCI tools until receiving a clear instruction from the user about what to do next, even if the user selects a project. It is acceptable to list out tool call options for the user to choose from, but do not execute them until instructed.

Inputs: params.

recommend_prompt_template_testsB

About this tool:

  • This tool is part of a toolchain that generates and provides test cases for a prompt template.

  • This tool generates an array of recommended tests for a given prompt template.

Parameters:

  • params: object

    • promptTemplate: string (the prompt template to be tested)

    • contextSchema: object (the context schema that defines the expected input parameters for the prompt template)

    • promptOrigin: "codebase" | "requirements" (indicates whether the prompt comes from an existing codebase or from new requirements)

    • model: string (the model that the prompt template will be tested against)

Example usage: { "params": { "promptTemplate": "The user wants a bedtime story about {{topic}} for a person of age {{age}} years old. Please craft a captivating tale that captivates their imagination and provides a delightful bedtime experience.", "contextSchema": { "topic": "string", "age": "number" }, "promptOrigin": "codebase" } }

The tool will return a structured array of test cases that can be used to test the prompt template.

Tool output instructions: - The tool will return a recommendedTests array that can be used to test the prompt template.

Inputs: params.

rerun_workflowA

This tool is used to rerun a workflow from start or from the failed job.

Common use cases:

  • Rerun a workflow from a failed job

  • Rerun a workflow from start

Input options (EXACTLY ONE of these TWO options must be used):

Option 1 - Workflow ID:

  • workflowId: The ID of the workflow to rerun

  • fromFailed: true to rerun from failed, false to rerun from start. If omitted, behavior is based on workflow status. (optional)

Option 2 - Workflow URL:

Inputs: params.

run_evaluation_testsA
This tool allows the users to run evaluation tests on a circleci pipeline.
They can be referred to as "Prompt Tests" or "Evaluation Tests".

This tool triggers a new CircleCI pipeline and returns the URL to monitor its progress.
The tool will generate an appropriate circleci configuration file and trigger a pipeline using this temporary configuration.
The tool will return the project slug.

Input options (EXACTLY ONE of these THREE options must be used):

Option 1 - Project Slug and branch (BOTH required):
- projectSlug: The project slug obtained from listFollowedProjects tool (e.g., "gh/organization/project")
- branch: The name of the branch (required when using projectSlug)

Option 2 - Direct URL (provide ONE of these):
- projectURL: The URL of the CircleCI project in any of these formats:
  * Project URL with branch: https://app.circleci.com/pipelines/gh/organization/project?branch=feature-branch
  * Pipeline URL: https://app.circleci.com/pipelines/gh/organization/project/123
  * Workflow URL: https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def
  * Job URL: https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def/jobs/xyz

Option 3 - Project Detection (ALL of these must be provided together):
- workspaceRoot: The absolute path to the workspace root
- gitRemoteURL: The URL of the git remote repository
- branch: The name of the current branch

Test Files:
- promptFiles: Array of prompt template file objects from the ./prompts directory, each containing:
  * fileName: The name of the prompt template file
  * fileContent: The contents of the prompt template file

Pipeline Selection:
- If the project has multiple pipeline definitions, the tool will return a list of available pipelines
- You must then make another call with the chosen pipeline name using the pipelineChoiceName parameter
- The pipelineChoiceName must exactly match one of the pipeline names returned by the tool
- If the project has only one pipeline definition, pipelineChoiceName is not needed

Additional Requirements:
- Never call this tool with incomplete parameters
- If using Option 1, make sure to extract the projectSlug exactly as provided by listFollowedProjects
- If using Option 2, the URLs MUST be provided by the user - do not attempt to construct or guess URLs
- If using Option 3, ALL THREE parameters (workspaceRoot, gitRemoteURL, branch) must be provided
- If none of the options can be fully satisfied, ask the user for the missing information before making the tool call

Returns:
- A URL to the newly triggered pipeline that can be used to monitor its progress

Inputs: params.

run_pipelineA
This tool triggers a new CircleCI pipeline and returns the URL to monitor its progress.

Input options (EXACTLY ONE of these THREE options must be used):

Option 1 - Project Slug and branch (BOTH required):
- projectSlug: The project slug obtained from listFollowedProjects tool (e.g., "gh/organization/project")
- branch: The name of the branch (required when using projectSlug)

Option 2 - Direct URL (provide ONE of these):
- projectURL: The URL of the CircleCI project in any of these formats:
  * Project URL with branch: https://app.circleci.com/pipelines/gh/organization/project?branch=feature-branch
  * Pipeline URL: https://app.circleci.com/pipelines/gh/organization/project/123
  * Workflow URL: https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def
  * Job URL: https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def/jobs/xyz

Option 3 - Project Detection (ALL of these must be provided together):
- workspaceRoot: The absolute path to the workspace root
- gitRemoteURL: The URL of the git remote repository
- branch: The name of the current branch

Configuration:
- an optional configContent parameter can be provided to override the default pipeline configuration

Pipeline Selection:
- If the project has multiple pipeline definitions, the tool will return a list of available pipelines
- You must then make another call with the chosen pipeline name using the pipelineChoiceName parameter
- The pipelineChoiceName must exactly match one of the pipeline names returned by the tool
- If the project has only one pipeline definition, pipelineChoiceName is not needed

Additional Requirements:
- Never call this tool with incomplete parameters
- If using Option 1, make sure to extract the projectSlug exactly as provided by listFollowedProjects
- If using Option 2, the URLs MUST be provided by the user - do not attempt to construct or guess URLs
- If using Option 3, ALL THREE parameters (workspaceRoot, gitRemoteURL, branch) must be provided
- If none of the options can be fully satisfied, ask the user for the missing information before making the tool call

Returns:
- A URL to the newly triggered pipeline that can be used to monitor its progress

Inputs: params.

run_rollback_pipelineA
Run a rollback pipeline for a CircleCI project. This tool guides you through the full rollback process, adapting to the information you provide and prompting for any missing details.

**Initial Requirements:**
- You need either a `projectSlug` (from `listFollowedProjects`) or a `projectID`. The tool will automatically resolve the project information from either of these.

**Typical Flow:**
1. **Start:** User initiates a rollback request.
2. **Project Selection:** If project id or project slug are not provided, call `listFollowedProjects` to get the list of projects the user follows and present the full list of projects to the user so that they can select the project they want to rollback.
3. **Project Information:** Provide either `projectSlug` or `projectID`. The tool will automatically resolve the project information as needed.
4. **Version Selection:** If component environment and version are not provided, call `listComponentVersions` to get the list of versions for the selected component and environment. If there is only one version, proceed automatically and do not ask the user to select a version. Otherwise, present the user with the full list of versions and ask them to select one. Always return all available values without categorizing them.
5. **Rollback Reason** ask the user for an optional reason for the rollback (e.g., "Critical bug fix"). Skip this step is the user explicitly requests a rollback by workflow rerun.
6. **Rollback pipeline check** if the tool reports that no rollback pipeline is defined, ask the user if they want to trigger a rollback by workflow rerun or suggest to setup a rollback pipeline following the documentation at https://circleci.com/docs/deploy/rollback-a-project-using-the-rollback-pipeline/.
7. **Confirmation:** Summarize the rollback request and confirm with the user before submitting.
8. **Pipeline Rollback:**  if the user requested a rollback by pipeline, call `runRollbackPipeline` passing all parameters including the namespace associated with the version to the tool.
9. **Workflow Rerun** If the user requested a rollback by workflow rerun, call `rerunWorkflow` passing the workflow ID of the selected version to the tool.
10.**Completion:** Report the outcome of the operation.

**Parameters:**
- `projectSlug` (optional): The project slug from `listFollowedProjects` (e.g., "gh/organization/project"). Either this or `projectID` must be provided.
- `projectID` (optional): The CircleCI project ID (UUID). Either this or `projectSlug` must be provided.
- `environmentName` (required): The target environment (e.g., "production", "staging").
- `componentName` (required): The component to rollback (e.g., "frontend", "backend").
- `currentVersion` (required): The currently deployed version.
- `targetVersion` (required): The version to rollback to.
- `namespace` (required): The namespace of the component.
- `reason` (optional): Reason for the rollback.
- `parameters` (optional): Additional rollback parameters as key-value pairs.

**Behavior:**
- If there are more than 20 environments or components, ask the user to refine their selection.
- Never attempt to guess or construct project slugs or URLs; always use values provided by the user or from `listFollowedProjects`.
- Do not prompt for missing parameters until versions have been listed.
- Do not call this tool with incomplete parameters.
- If the selected project lacks rollback pipeline configuration, provide a definitive error message without suggesting alternative projects.

**Returns:**
- On success: The rollback ID or a confirmation in case of workflow rerun.
- On error: A clear message describing what is missing or what went wrong.
- If the selected project does not have a rollback pipeline configured: The tool will provide a clear error message specific to that project and will NOT suggest trying another project.

**Important Note:**
- This tool is designed to work only with the specific project provided by the user.
- If a project does not have rollback capability configured, the tool will NOT recommend trying other projects.
- The assistant should NOT suggest trying different projects when a project lacks rollback configuration.
- Each project must have its own rollback pipeline configuration to be eligible for rollback operations.
- When a project cannot be rolled back, provide only the configuration guidance for THAT specific project.
- The tool automatically resolves project information from either `projectSlug` or `projectID`.
If no version is found, the tool will suggest the user to set up deploy markers following the documentation at:
https://circleci.com/docs/deploy/configure-deploy-markers/

Inputs: params.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.9/5.0

    Scored across 16 tools

    Disambiguation3/5

    Most tools have distinct purposes (e.g., config_helper vs. find_flaky_tests), but there is notable overlap between run_pipeline, run_evaluation_tests, and rerun_workflow, which all involve triggering or re-running CI workflows. Additionally, analyze_diff seems unrelated to CircleCI's core domain, creating confusion about the server's scope. Descriptions help clarify, but the overlap and outlier reduce clarity.

    Naming Consistency4/5

    The majority of tools follow a consistent verb_noun or verb_adjective_noun pattern (e.g., list_followed_projects, get_build_failure_logs, find_underused_resource_classes). However, there are minor deviations like config_helper (noun_verb) and analyze_diff (verb_noun without underscore), which slightly break the pattern but do not severely impact readability.

    Tool Count3/5

    With 16 tools, the count is borderline high for a CI-focused server, especially given the inclusion of prompt-related tools (create_prompt_template, recommend_prompt_template_tests) that seem out of scope. This makes the set feel somewhat bloated and less focused on core CircleCI operations, though it's not extreme.

    Completeness4/5

    For CircleCI operations, the surface covers key areas like project listing, pipeline management, debugging, and usage analysis, with good lifecycle coverage (e.g., run_pipeline, rerun_workflow, get_build_failure_logs). However, gaps exist in areas like user management or detailed configuration editing, and the prompt tools are tangential, slightly reducing coherence for the main domain.

    Maintenance

    ActivityNo data
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      A
      quality
      B
      maintenance
      An MCP server for Zuul CI. Debug build failures by asking questions, not clicking through web UIs. Read-only access to any Zuul instance — builds, logs, pipelines, jobs, and live status. Works with Claude Code, Claude Desktop, Cursor, and any MCP-compatible client.
      44
      59 PyPI
      21
      Apache 2.0
    • A
      license
      Not graded
      quality
      D
      maintenance
      MCP server for the Codemagic CI/CD API, enabling app management, build operations, artifact handling, cache control, and team management through natural language.
      10 npm
      3
      MIT
    • A
      license
      A
      quality
      D
      maintenance
      This MCP server enables users to manage Codemagic CI/CD builds directly from Claude Code, including listing apps, triggering builds, checking status, and canceling builds.
      6
      MIT
    • F
      license
      Not graded
      quality
      D
      maintenance
      An MCP server wrapping the Cursor CLI agent, enabling Claude Code and other MCP clients to delegate tasks to Cursor's AI agent for file writing, bash commands, and codebase queries.
      -