# Circleci MCP server

Source: https://glimind.com/server/mcp-registry%2Fcom.circleci%2Fmcp
Registry id: `mcp-registry/com.circleci/mcp`
Status: auth-required (checked 2026-10-26T22:11:03.047Z)

## Verdict

Circleci MCP server answered 100% of Glimind's liveness checks over 30 days, better than 42% of MCP servers, with 280 ms median handshake and 0 outages in 90 days. Its agent-readiness grade is A (100/100) across 22 tools, costing an agent about 4,827 tokens to load. Checked every few minutes; no tool is ever called.

## Measurements (30 days)

| Metric | Value | Better than |
|---|---|---|
| Uptime, 30 days | 100% | 42% of MCP servers |
| Median handshake latency | 280 ms | 64% of MCP servers |
| p95 handshake latency | 529 ms | — |
| Checks in 30 days | 213 | — |
| Outages, 90 days | 0 | — |
| Median recovery | — | — |
| Agent-readiness score | 100/100 (A) | 94% of MCP servers |
| Tools | 22 | — |
| Tool-list size for an agent | ~4,827 tokens | 39% of MCP servers |
| Days observed | 29 | — |

## Install

```json
{
  "mcpServers": {
    "circleci-mcp-server": {
      "type": "http",
      "url": "https://mcp.circleci.com/v1/mcp"
    }
  }
}
```

Claude Code:

```sh
claude mcp add --transport http circleci-mcp-server https://mcp.circleci.com/v1/mcp
```

## Tools (22)

- `cancel_workflow`: Cancel a running CircleCI workflow, given its UUID (a workflow id from list_workflows or get_workflow). Cancellation is asynchronous: a successful call means th
- `download_usage_data`: Export a CircleCI organization's usage data as downloadable CSV files. This is a two-phase, asynchronous tool. Phase 1 — start: call with org (an org slug like 
- `get_deploy_component`: Fetch a single CircleCI deploy component by its UUID (a component id from list_deploy_components), returning its name and owning project ID.
- `get_deploy_environment`: Fetch a single CircleCI deploy environment by its UUID (an environment id from list_deploy_environments), returning its name and owning org ID.
- `get_job`: Fetch a single CircleCI job by its UUID (a job id from list_jobs), returning its phase, outcome, and per-step detail including each step's exit code — the signa
- `get_job_logs`: Fetch the stdout/stderr of a CircleCI job's steps, given the job's UUID (a job id from list_jobs). When no step is named, the failed steps are read automaticall
- `get_orb`: Fetch a registry orb's metadata and published version history — given the orb as "namespace/name" (e.g. "circleci/go") or an orb UUID. Returns the latest versio
- `get_orb_source`: Fetch the YAML source of an orb version referenced by a CircleCI config — given the orb as "namespace/name" optionally pinned to a version ("circleci/go@1.2.3",
- `get_run`: Fetch a single CircleCI run by its UUID (a run id from list_runs), returning its phase, outcome, VCS details, and any config errors. The next step in the CI-acc
- `get_workflow`: Fetch a single CircleCI workflow by its UUID (a workflow id from list_workflows), returning its name, phase, and outcome. A workflow's id feeds list_jobs.
- `list_artifacts`: List the artifacts a CircleCI job produced — the files it persisted beyond the run, such as test reports, coverage, build outputs, or logs — given the job's UUI
- `list_deploy_component_versions`: List versions of a CircleCI deploy component — given the component's UUID (a component id from list_deploy_components or get_deploy_component). Optionally filte
- `list_deploy_components`: List CircleCI deploy components for a project — given its slug ("gh/org/repo") or UUID. Deploy components are the deployable units of a project (services, appli
- `list_deploy_environments`: List CircleCI deploy environments for an organization — given its slug ("gh/myorg") or UUID. Deploy environments represent named targets such as production or s
- `list_deployments`: List recent CircleCI deployments for a project — given its slug ("gh/org/repo") or UUID. Returns deployments newest-first with component name, version, type, st
- `list_job_tests`: List a CircleCI job's test results, given the job's UUID (a job id from list_jobs or get_job). By default only failing tests are returned — the ones that explai
- `list_jobs`: List the jobs belonging to a CircleCI workflow, given the workflow's UUID (a workflow id from list_workflows or get_workflow). The next step in the CI-access ch
- `list_runs`: List CircleCI runs for a project — given its slug ("gh/org/repo") or UUID — or the authenticated user's own runs across all projects (mine=true). Optionally fil
- `list_workflows`: List the workflows belonging to a CircleCI run, given the run's UUID (a run id from list_runs or get_run). The next step in the CI-access chain: each workflow's
- `me`: Get details of the authenticated CircleCI user. Use this when a request is about the user's own profile, or when information is missing to build other tool call
- `rerun_workflow`: Rerun a CircleCI workflow, given its UUID (a workflow id from list_workflows or get_workflow). By default every job reruns from the start; set from_failed=true 
- `validate_config`: Validate a CircleCI pipeline config by compiling it — the equivalent of the `circleci config validate` CLI command. Pass the raw config YAML (the contents of .c

Measured by Glimind (https://glimind.com): MCP handshake + tool list only, no tool is ever called. CC BY 4.0.