mcp-server-circleci
OfficialThis server provides CircleCI operations and related testing/analysis tools through MCP-compatible clients.
Validate and fix CircleCI configuration files.
List followed projects and retrieve project slugs.
Check latest pipeline status and retrieve build failure logs, test results, and artifacts.
Trigger pipelines, rerun workflows from start or failed job, run rollback pipelines, and inspect component versions.
Find flaky tests and underused resource classes, and download/analyze CircleCI Usage API CSV data.
Analyze git diffs against IDE rules.
Generate prompt templates, recommend prompt-template tests, and run evaluation tests through CircleCI.
Run locally via NPX/Docker or as a self-managed remote MCP server with per-user or shared token authentication.
Integrates with CircleCI to retrieve build failure logs and identify flaky tests. Supports accessing logs via CircleCI URLs or local project context, and analyzing test execution history to detect unreliable tests in a project's test suite.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mcp-server-circleci show me the status of my latest pipeline"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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
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 |
Validate and get guidance for your CircleCI configuration | |
Download usage data from the CircleCI Usage API | |
Identify flaky tests by analyzing test execution history | |
Find jobs with underused compute resources | |
Retrieve detailed failure logs from CircleCI builds | |
Retrieve test metadata and results for CircleCI jobs | |
Get the status of the latest pipeline for a branch | |
List artifacts produced by a CircleCI job | |
List all versions for a CircleCI component | |
List all CircleCI projects you're following | |
Rerun a workflow from start or from the failed job | |
Trigger a pipeline to run | |
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:
Docker: Docker
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_URLis optional — required for on-prem customers only.MAX_MCP_OUTPUT_LENGTHis 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:
Docker: Docker
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:
Docker: Docker
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.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
For more information: https://modelcontextprotocol.io/quickstart/user
Prerequisites:
Docker: Docker
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@latestUsing 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-circleciUsing a Self-Managed Remote MCP Server
See Self-Managed Remote MCP Server and the Claude Code client setup there.
Prerequisites:
Docker: Docker
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 workspacesWorkspace:
.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:
Choose the + symbol
Select scope: global or local
Enter a name (e.g.
circleci-remote-mcp)Select transport protocol: stdio
Enter the command path to your script
Click Save
To install CircleCI MCP Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @CircleCI-Public/mcp-server-circleci --client claudeSelf-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 |
| Each dev forwards their PAT | Per developer |
Shared token (interim) | Quick rollout, single service identity OK |
| 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'sCIRCLECI_TOKENidentity 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=falseis combined with a non-loopback bind address, unless you explicitly accept the risk withMCP_ALLOW_UNAUTHENTICATED_NETWORK_ACCESS=true. TheHost/Origincheck 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-circleciPer-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-circleciShared 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-circleciPrefer 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 |
| Starts the HTTP+SSE MCP server instead of stdio |
| Listening port inside the container (default: |
| Reject requests without |
| Shared fallback PAT for all requests when per-user headers are not sent |
| Optional — required for on-prem only (default: |
| Opt out of usage metrics export |
| Comma-separated list of additional |
| Comma-separated list of additional |
| Network interface to bind to (default: |
| Required ( |
| Comma-separated list of additional directories that file-reading/writing tools may use (e.g. |
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) andfind_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_modulesand 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 —
/workspacein a container,/srv,/opt, a secondary volume such as/Volumes/work— setMCP_FILE_OUTPUT_ROOTSto 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
Hostheader on every/mcprequest. By default only loopback addresses (localhost,127.0.0.1,[::1]) are accepted. Public deployments must setMCP_ALLOWED_HOSTSto the hostname clients use, or all/mcprequests will receive403 Forbidden. The/pinghealth-check endpoint is not guarded so load-balancer probes continue to work regardless ofHost.The
Originheader (sent by browsers) is also validated when present. Non-browser clients such asmcp-remotenever sendOrigin, 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
Hostand omitOriginto 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 ofREQUIRE_REQUEST_TOKEN(or an authenticating proxy in front of the port). Requiring anOriginheader would break every legitimate CLI client while stopping no attacker.Behind a reverse proxy: If your proxy rewrites
Hostto the backend address (nginx's default), addproxy_set_header Host $host;to pass the original hostname through, then setMCP_ALLOWED_HOSTSto that public hostname. Alternatively, setMCP_ALLOWED_HOSTSto 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/mcpwith--allow-httpfor local testing. In production, terminate TLS at your ingress/load balancer and usehttps://your-host/mcpwithout--allow-http.
Windows: Avoid spaces around the colon in
--headervalues. Put the fullBearer <token>value in an environment variable.
Security: Examples use
npxfor convenience. For production or team rollouts, pin a specific version in your MCP config (for examplemcp-remote@0.1.38instead ofmcp-remote). Do not use versions below0.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.ymlfor syntax and semantic errorsProvides 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.
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:
Using Project Slug (Recommended):
First use
list_followed_projectsto get your projects, then:Example: "Get flaky tests for my-project"
Using CircleCI Project URL:
Example: "Find flaky tests in https://app.circleci.com/pipelines/github/org/repo"
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_DIRECTORYenv 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:
Using Project Slug and Branch (Recommended):
First use
list_followed_projectsto get your projects, then:Example: "Get build failures for my-project on the main branch"
Using CircleCI URLs:
Provide a failed job URL or pipeline URL directly
Example: "Get logs from https://app.circleci.com/pipelines/github/org/repo/123"
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:
Using Project Slug and Branch (Recommended):
Example: "Get test results for my-project on the main branch"
Using CircleCI URL:
Job URL:
https://app.circleci.com/pipelines/github/org/repo/123/workflows/abc-def/jobs/789Workflow URL:
https://app.circleci.com/pipelines/github/org/repo/123/workflows/abc-defPipeline URL:
https://app.circleci.com/pipelines/github/org/repo/123
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
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:
Using Project Slug and Branch (Recommended):
Example: "Get the status of the latest pipeline for my-project on the main branch"
Using CircleCI Project URL:
Example: "Get the status of the latest pipeline for https://app.circleci.com/pipelines/github/org/repo"
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 progressRetrieves the list of artifacts produced by a CircleCI job. This tool can be used in three ways:
Using Project Slug and Branch (Recommended):
First use
list_followed_projectsto get your projects, then:Example: "List artifacts for my-project on the main branch"
Using CircleCI URL:
Job URL:
https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-def/jobs/789Workflow URL:
https://app.circleci.com/pipelines/gh/organization/project/123/workflows/abc-defPipeline URL:
https://app.circleci.com/pipelines/gh/organization/project/123
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
projectSlugExample: "List my CircleCI projects"
Example output:
Projects followed:
1. my-project (projectSlug: gh/organization/my-project)
2. another-project (projectSlug: gh/organization/another-project)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:
Using Project Slug and Branch (Recommended):
Example: "Run the pipeline for my-project on the main branch"
Using CircleCI URL:
Pipeline URL, Workflow URL, Job URL, or Project URL with branch
Example: "Run the pipeline for https://app.circleci.com/pipelines/github/org/repo/123"
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:
Project Selection — lists followed projects for you to choose from
Environment Selection — lists available environments (auto-selects if only one)
Component Selection — lists available components (auto-selects if only one)
Version Selection — displays available versions; you select the target for rollback
Rollback Mode Detection — checks if a rollback pipeline is configured
Execute Rollback — two options:
Pipeline Rollback: triggers the rollback pipeline
Workflow Rerun: reruns a previous workflow using its workflow ID
Confirmation — summarizes and confirms before execution
Troubleshooting
Most common issues:
Clear package caches:
npx clear-npx-cache npm cache clean --forceForce latest version: Add
@latestto your config:"args": ["-y", "@circleci/mcp-server-circleci@latest"]Restart your IDE completely (not just reload window)
Invalid token errors: Verify your
CIRCLECI_TOKENin Personal API TokensPermission errors: Ensure the token has read access to your projects
Environment variables not loading: Test with
echo $CIRCLECI_TOKEN(Mac/Linux) orecho %CIRCLECI_TOKEN%(Windows)
Base URL: Confirm
CIRCLECI_BASE_URLishttps://circleci.comCorporate 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.1withnode --versionUpdate 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.exePort conflicts: Restart your IDE if the connection seems blocked.
Test package directly:
npx @circleci/mcp-server-circleci@latest --helpVerbose logging:
DEBUG=* npx @circleci/mcp-server-circleci@latestDocker fallback: Try Docker installation if npx fails consistently
Still need help?
Check GitHub Issues for similar problems
Include your OS, Node version, and IDE when reporting issues
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 |
| Tool invocation count |
| Execution time in ms |
| Error count |
Development
Getting Started
Clone the repository:
git clone https://github.com/CircleCI-Public/mcp-server-circleci.git cd mcp-server-circleciInstall dependencies:
pnpm installBuild 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-circleciRemote 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
Start the development server:
pnpm watch # Keep this running in one terminalIn a separate terminal, launch the inspector:
pnpm inspectorConfigure the environment:
Add your
CIRCLECI_TOKENto the Environment Variables section in the inspector UIThe 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 testRun tests in watch mode during development:
pnpm test:watch
For more detailed contribution guidelines, see CONTRIBUTING.md
Available Tools
16 toolsanalyze_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:
feature requirements defined by a user - in which case the tool will generate a new prompt template based on the feature requirements.
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
./promptsdirectory.
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
./promptsdirectory with the<relevant-name>.prompt.ymlconvention (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
templatethat reformulates the user's prompt into a more structured format.a
contextSchemathat defines the expected input parameters for the template.a
promptOriginthat 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, andpromptOrigin-- will also be used as input to therecommend_prompt_template_teststool 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:
workflowURL: The URL 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)
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
Scored across 16 tools
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.
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.
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.
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
Related MCP Connectors
Run, debug, and triage tests from your IDE using natural language, no dashboard switching, no manual data transfers. The TestMu AI (formerly LambdaTest) MCP Server is a single remote server exposing four tool suites: HyperExecute — analyze your project, generate YAML configs and test runner commands, then monitor jobs and sessions. Automation — pull a TestID's details plus command, network, and console logs into one chat for instant root-cause analysis. Includes mobile app upload. SmartUI — explain pixel, layout, DOM, and perceptual changes in a visual regression run, with context-aware React/HTML/CSS fixes. Accessibility — audit any public URL or a local React app against WCAG and get ready-to-apply remediation steps. Connects over https://mcp.lambdatest.com/mcp using OAuth 2.1 — no API keys in your config. One-click install in Cursor; works with Claude, GitHub Copilot, Cline, and any MCP client. Tests execute on the TestMu AI cloud: 3,000+ browsers and 10,000+ real devices.
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Official Fibery MCP server: query and update your workspace from any AI client via OAuth.
Related MCP Servers
- AlicenseAqualityBmaintenanceAn 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.4459 PyPI21Apache 2.0
- AlicenseNot gradedqualityDmaintenanceMCP server for the Codemagic CI/CD API, enabling app management, build operations, artifact handling, cache control, and team management through natural language.10 npm3MIT
- AlicenseAqualityDmaintenanceThis MCP server enables users to manage Codemagic CI/CD builds directly from Claude Code, including listing apps, triggering builds, checking status, and canceling builds.6MIT
- FlicenseNot gradedqualityDmaintenanceAn 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.-