What is CircleCI MCP Server for managing context between LLMs and CircleCI.?
Model Context Protocol (MCP) is a new, standardized protocol for managing context between large language models (LLMs) and external systems. This repository provides an MCP Server for CircleCI, allowing users to interact with CircleCI using natural language through various supported clients.
Documentation
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.
This lets you use Cursor IDE, Windsurf, Copilot, or any MCP supported Client, to use natural language to accomplish things with CircleCI, e.g.:
To find/create this file, first open your claude desktop settings. Then click on "Developer" in the left-hand bar of the Settings pane, and then click on "Edit Config"
To find/create this file, first open your Claude Desktop settings. Then click on "Developer" in the left-hand bar of the Settings pane, and then click on "Edit Config"
To install CircleCI MCP Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @CircleCI-Public/mcp-server-circleci --client claude
Amazon Q Developer CLi
MCP client configuration in Amazon Q Developer is stored in JSON format, in a file named mcp.json.
Amazon Q Developer CLI supports two levels of MCP configuration:
Global Configuration: ~/.aws/amazonq/mcp.json - Applies to all workspaces
Workspace Configuration: .amazonq/mcp.json - Specific to the current workspace
Both files are optional; neither, one, or both can exist. If both files exist, Amazon Q Developer reads MCP configuration from both and combines them, taking the union of their contents. If there is a conflict (i.e., a server defined in the global config is also present in the workspace config), a warning is displayed and only the server entry in the workspace config is used.
Using NPX in a local MCP Server
Edit your global configuration file ~/.aws/amazonq/mcp.json or create a new one in the current workspace .amazonq/mcp.json with the following content:
If you select global scope, the MCP server configuration is stored in ~/.aws/amazonq/mcp.json and available across all your projects. If you select local scope, the configuration is stored in .amazonq/mcp.json within your current project.
In the Name field, enter the name of the CircleCI remote MCP server (e.g. circleci-remote-mcp).
Select the transport protocol (stdio).
In the Command field, enter the shell command created previously that the MCP server will run when it initializes (e.g. /full/path/to/circleci-remote-mcp.sh).
Click the Save button.
Features
Supported Tools
get_build_failure_logs
Retrieves detailed failure logs from CircleCI builds. This tool can be used in three ways:
Using Project Slug and Branch (Recommended Workflow):
First, list your available projects:
Use the list_followed_projects tool to get your projects
Example: "List my CircleCI projects"
Then choose the project, which has a projectSlug associated with it
Example: "Lets use my-project"
Then ask to retrieve the build failure logs for a specific branch:
Example: "Get build failures for my-project on the main branch"
This will return the flaky tests and their details in a text format
2. Using file output mode: (requires the FILE_OUTPUT_DIRECTORY environment variable to be set)
This will create a directory with the flaky tests and their details
The tool returns detailed information about flaky tests, including:
Test names and file locations
Failure messages and contexts
This helps you:
Identify unreliable tests in your test suite
Get detailed context about test failures
Make data-driven decisions about test improvements
get_latest_pipeline_status
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 Workflow):
First, list your available projects:
Use the list_followed_projects tool to get your projects
Example: "List my CircleCI projects"
Then choose the project, which has a projectSlug associated with it
Example: "Lets use my-project"
Then ask to retrieve the latest pipeline status for a specific branch:
Example: "Get the status of the latest pipeline for my-project on the main branch"
Example: "Get the status of the latest pipeline for my current project"
The tool returns a formatted status of the latest pipeline:
Workflow names and their current status
Duration of each workflow
Creation and completion timestamps
Overall pipeline health
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
This is particularly useful for:
- Checking the status of the latest pipeline
- Getting the status of the latest pipeline for a specific branch
- Quickly checking the status of the latest pipeline without leaving your IDE
- `get_job_test_results`
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 Workflow):
- First, list your available projects:
- Use the list_followed_projects tool to get your projects
- Example: "List my CircleCI projects"
- Then choose the project, which has a projectSlug associated with it
- Example: "Lets use my-project"
- Then ask to retrieve the test results for a specific branch:
- Example: "Get test results for my-project on the main branch"
2. Using CircleCI URL:
- Provide a CircleCI URL in any of these formats:
- 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"
- Example: "Get test results for https://app.circleci.com/pipelines/github/org/repo/123/workflows/abc-def"
3. Using Local Project Context:
- Works from your local workspace by providing:
- Workspace root path
- Git remote URL
- Branch name
- Example: "Get test results for my current project on the main branch"
The tool returns detailed test result information:
- Summary of all tests (total, successful, failed)
- Detailed information about failed tests including:
- Test name and class
- File location
- Error messages
- Runtime duration
- List of successful tests with timing information
- Filter by tests result
This is particularly useful for:
- Quickly analyzing test failures without visiting the CircleCI web UI
- Identifying patterns in test failures
- Finding slow tests that might need optimization
- Checking test coverage across your project
- Troubleshooting flaky tests
Note: The tool requires that test metadata is properly configured in your CircleCI config. For more information on setting up test metadata collection, see:
https://circleci.com/docs/collect-test-data/
- `config_helper`
Assists with CircleCI configuration tasks by providing guidance and validation. This tool helps you:
1. Validate CircleCI Config:
- Checks your .circleci/config.yml for syntax and semantic errors
- Example: "Validate my CircleCI config"
The tool provides:
- Detailed validation results
- Configuration recommendations
This helps you:
- Catch configuration errors before pushing
- Learn CircleCI configuration best practices
- Troubleshoot configuration issues
- Implement CircleCI features correctly
- `create_prompt_template`
Helps generate structured prompt templates for AI-enabled applications based on feature requirements. This tool:
1. Converts Feature Requirements to Structured Prompts:
- Transforms user requirements into optimized prompt templates
- Example: "Create a prompt template for generating bedtime stories by age and topic"
The tool provides:
- A structured prompt template
- A context schema defining required input parameters
This helps you:
- Create effective prompts for AI applications
- Standardize input parameters for consistent results
- Build robust AI-powered features
- `recommend_prompt_template_tests`
Generates test cases for prompt templates to ensure they produce expected results. This tool:
1. Provides Test Cases for Prompt Templates:
- Creates diverse test scenarios based on your prompt template and context schema
- Example: "Generate tests for my bedtime story prompt template"
The tool provides:
- An array of recommended test cases
- Various parameter combinations to test template robustness
This helps you:
- Validate prompt template functionality
- Ensure consistent AI responses across inputs
- Identify edge cases and potential issues
- Improve overall AI application quality
- `list_followed_projects`
Lists all projects that the user is following on CircleCI. This tool:
1. Retrieves and Displays Projects:
- Shows all projects the user has access to and is following
- Provides the project name and projectSlug for each entry
- Example: "List my CircleCI projects"
The tool returns a formatted list of projects, example output:
This is particularly useful for:
- Identifying which CircleCI projects are available to you
- Obtaining the projectSlug needed for other CircleCI tools
- Selecting a project for subsequent operations
Note: The projectSlug (not the project name) is required for many other CircleCI tools, and will be used for those tool calls after a project is selected.
- `run_pipeline`
Triggers a pipeline to run. This tool can be used in three ways:
1. Using Project Slug and Branch (Recommended Workflow):
- First, list your available projects:
- Use the list_followed_projects tool to get your projects
- Example: "List my CircleCI projects"
- Then choose the project, which has a projectSlug associated with it
- Example: "Lets use my-project"
- Then ask to run the pipeline for a specific branch:
- Example: "Run the pipeline for my-project on the main branch"
2. Using CircleCI URL:
- Provide a CircleCI URL in any of these formats:
- 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"
- Project URL with branch: "https://app.circleci.com/projects/github/org/repo?branch=main"
- Example: "Run the pipeline for https://app.circleci.com/pipelines/github/org/repo/123/workflows/abc-def"
3. Using Local Project Context:
- Works from your local workspace by providing:
- Workspace root path
- Git remote URL
- Branch name
- Example: "Run the pipeline for my current project on the main branch"
The tool returns a link to monitor the pipeline execution.
This is particularly useful for:
- Quickly running pipelines without visiting the CircleCI web UI
- Running pipelines from a specific branch
- `run_rollback_pipeline`
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 Step:**
- First, call the `list_followed_projects` tool to retrieve the list of projects the user follows.
- Then, ask the user to select a project by providing either a `projectID` or the exact `projectSlug` as returned by `list_followed_projects`.
**Typical Flow:**
1. **Start:** User initiates a rollback request.
2. **Project Selection:** If a \`projectSlug\` or \`projectID\` is not provided, call \`listFollowedProjects\` and prompt the user to select a project using the exact value returned.
3. **Execute the tool and list the versions.**
4. **Workflow Rerun:**
- Inform the user of the fact that no rollback pipeline is defined for this project.
- Ask the user if they want to rerun a workflow.
- If the user wants to rerun a workflow, execute the tool with rollback_type set to \`WORKFLOW_RERUN\`. Do not propose to choose another project.
6. **Component Selection:**
- If the project has multiple components, present up to 20 options for the user to choose from.
- If there is only one component, proceed automatically and do not ask the user to select a component.
7. **Environment Selection:**
- If the project has multiple environments, present up to 20 options for the user to choose from.
- If there is only one environment, proceed automatically and do not ask the user to select an environment.
8. **Version Selection:**
- Present the user with available versions to rollback to, based on the selected environment and component. Include the namespace for each version.
- Ask for both the current deployed version and the target version to rollback to.
9. **Optional Details:**
- If the rollback type is \`PIPELINE\`, prompt the user for an optional reason for the rollback (e.g., "Critical bug fix").
- If the rollback type is \`WORKFLOW_RERUN\`, provide the workflow ID of the selected version to the tool.
- provide the namespace for the selected version to the tool.
10. **Confirmation:**
- Summarize the rollback request and confirm with the user before submitting.
**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.
- `rerun_workflow`
Reruns a workflow from its start or from the failed job.
The tool returns the ID of the newly-created workflow, and a link to monitor the new workflow.
This is particularly useful for:
- Quickly rerunning a workflow from its start or from the failed job without visiting the CircleCI web UI
- `analyze_diff`
Analyzes git diffs against cursor rules to identify rule violations.
This tool can be used by providing:
1. Git Diff Content:
- Staged changes: `git diff --cached`
- Unstaged changes: `git diff`
- All changes: `git diff HEAD`
- Example: "Analyze my staged changes against the cursor rules"
2. Repository Rules:
- Rules from `.cursorrules` file in your repository root
- Rules from `.cursor/rules` directory
- Multiple rule files combined with `---` separator
- Example: "Check my diff against the TypeScript coding standards"
The tool provides:
- Detailed violation reports with confidence scores
- Specific explanations for each rule violation
Example usage scenarios:
- "Analyze my staged changes for any rule violations"
- "Check my unstaged changes against rules"
This is particularly useful for:
- Pre-commit code quality checks
- Ensuring consistency with team coding standards
- Catching rule violations before code review
The tool integrates with your existing cursor rules setup and provides immediate feedback on code quality, helping you catch issues early in the development process.
# Development
## Getting Started
1. Clone the repository:
```bash
git clone https://github.com/CircleCI-Public/mcp-server-circleci.git
cd mcp-server-circleci
Install dependencies:
pnpm install
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.
To run the container locally:
docker run --rm -i -e CIRCLECI_TOKEN=your-circleci-token -e CIRCLECI_BASE_URL=https://circleci.com circleci:mcp-server-circleci
To run the container as a self-managed remote MCP server you need to add the environment variable start=remote to the docker run command. You can also define the port to use with the environment variable port=<port> or else the default port 8000 will be used: