- Home
- Resources
- Integrations
- CircleCI
Claude CircleCI connectorWhat Claude can do in your CircleCI account.
The Claude CircleCI connector exposes 24 tools: 10 read, 3 act on your pipelines, and 11 have no description anywhere. Here: which runs, logs and tests Claude reads, what it can rerun, cancel or roll back, what CircleCI says to review first, and who can switch it off.
Verified Trustpilot reviews · AI, automation & growth agency
What changes when a build goes red
A failed build usually means opening CircleCI, finding the run, then the workflow, then the job, then scrolling logs. With the connector on, you ask Claude why the last run on your branch failed. It chains the lookups itself, reads the failing step's output and explains what broke, right in the conversation.
Find the cause of a red build. list_runs finds the latest run on the branch, get_run confirms it failed, and get_job_logs reads the failed steps without you naming one.
Rerun only what failed. A long workflow broke near the end. rerun_workflow can restart just the failed jobs and what depends on them.
Check costs and releases. download_usage_data exports an organization's usage as CSV files, and list_deploy_component_versions checks which component versions run across your fleet.
What the sheet does not say: this is CircleCI's hosted server, built for inspecting runs. Managing contexts, environment variables, orbs or policies belongs to CircleCI's command-line option, not this connector. Eleven tools on the sheet have no description. And nothing runs by itself: no tool reacts to a push or a failure on its own. To react automatically to pipeline events, the CircleCI n8n integration fits that job, which is different from a conversation.
The vocabulary in one minute
Five words you will meet while connecting CircleCI.
- Connector
- The link you set up once between Claude and an account you already own, so Claude can work on it while it answers you.
- Tool
- One named thing a connector lets Claude do. Claude picks the ones it needs on its own; the directory sheet lists them by name.
- Authorization
- The service's own sign-in screen, where you hand Claude the access it will use afterwards. Granted once per person, revocable the same way.
- Approval
- The confirmation Claude waits for before it goes through with something that changes the account, shown in the chat when it matters.
- MCP
- The shared standard connectors are built on: it is what lets an assistant like Claude talk to an outside service.
Connect CircleCI to Claude in three steps
- 01
Find CircleCI in Claude
In Claude's settings, open Customize, then Connectors, and look for CircleCI in the list. On a Team or Enterprise workspace, an Owner or Primary Owner has to switch the connector on before any member can connect.
- 02
Start the connection
Click Connect on its row, then sign in to CircleCI in the window CircleCI opens itself. If the link breaks later, use Disconnect and connect again; CircleCI also advises re-authenticating when sign-in fails.
- 03
Read the authorization screen
Read the authorization screen before you accept. It belongs to CircleCI, not Claude, and it decides what the access covers. You can also withdraw that access later from your CircleCI account.
The 24 tools of the Claude CircleCI connector
CircleCI gives Claude 24 tools: 10 that read your account, 3 that change something in it, and 11 no official source describes.
Three groups: what Claude reads, what it changes in your pipelines, and what no official source describes. Names stay exactly as Claude shows them.
- 10 read
- 3 write
- 11 not documented
Tools index
What Claude reads (10)
10 toolsTen tools that look at runs, jobs, logs, tests, artifacts and config without changing them.
download_usage_data
Exports an organization's usage data as downloadable CSV files for a chosen period, identified by org slug or ID.
get_job
Fetches one job with its phase, its outcome and a step-by-step breakdown that includes each step's exit code.
get_job_logs
Reads the output of a job's steps. If you do not name a step, it goes straight to the ones that failed, which is usually what you want.
get_run
Pulls a single run with its phase, its outcome, the version control details behind it and any config errors CircleCI detected.
get_workflow
Returns one workflow's name, phase and outcome, which tells Claude where a run stands before it digs into individual jobs and their logs.
list_deploy_component_versions
According to the directory sheet, it lets Claude check which component versions are deployed across your fleet, as part of day-to-day project management.
list_job_artifacts
Per the directory sheet, it lists the artifacts your builds produced, so you can grab outputs like reports or packages without hunting through the interface.
list_job_tests
Lists a job's test results. By default it returns only failing tests, with an option to include passing and skipped ones.
list_runs
Lists runs for a project, by slug or ID, or your own runs across every project you work on, with filters on branch and on run status.
validate_config
Described on the directory sheet as a config helper, it assists with validating and troubleshooting your .circleci/config.yml setup.
What Claude changes (3)
3 toolsThree tools that change real CI state. No source describes a confirmation specific to them; the general rule below applies.
cancel_workflow
Approval: see the ruleCancels a workflow that is currently running.
rerun_workflow
Approval: see the ruleRestarts a workflow. By default every job runs again; with the right option, only failed jobs and whatever depends on them rerun.
rollback_deploy_component
Approval: see the ruleThe directory sheet says you can ask Claude to roll back a deployment from the conversation, without opening CircleCI.
Undocumented (11)
11 toolsThe directory publishes these eleven names and nothing more. No official text says what they do, and we will not guess from a name.
get_deploy_component
This name is on the directory's list, and that is all anyone publishes about it. No official source documents it: neither CircleCI's MCP page nor any Claude article describes it.
get_deploy_environment
Another listed name that no official source documents. The directory shows it; the explanation is simply missing. Better to flag the gap than to fill it with a guess drawn from how the name sounds.
get_job_resource_usage
Listed on the sheet, explained nowhere. Neither CircleCI's tool page nor any Claude article gives it a single sentence, so this page does not describe it or hint at what it might cover.
get_me
No page from CircleCI or Anthropic says what this tool returns. The directory only prints its name, so this page stops there too. No official source documents it.
get_orb
The name appears on the sheet without any official explanation. CircleCI's MCP page is silent on it, and so is every Claude page. Its role is simply not on record anywhere public today.
get_orb_source
Here again, a name and nothing else: no official source documents it, and guessing its behavior from the wording would be exactly the mistake this page avoids. The gap is real, not an oversight.
list_deploy_components
This tool is printed on the directory sheet with no sentence from CircleCI or Claude behind it. No official source documents it: we know it exists, not what it does. If CircleCI publishes a description later, this note will follow.
list_deploy_environments
No source documents this name. The directory lists it, CircleCI's MCP page leaves it out, and no Claude help article covers the connector at all. Nothing more can be said honestly.
list_deployments
One more name the sheet shows without any official description, from CircleCI or from Anthropic. Rather than infer anything, this page reports the silence and stops there, as it should.
list_run_workflows
CircleCI's MCP page describes a tool under a close but different name, and nothing documents this exact name. The page does not assume the two are the same tool, and no official source documents this one.
list_workflow_jobs
Same mismatch: CircleCI documents a tool with a neighboring name, while this exact name has no description from any official source. No official source documents it, so treat it as undocumented.
What Claude asks before acting
By default, Claude stops and asks for your go-ahead before any action it takes on an account for you. The request appears in the conversation when it matters.
That covers rerunning, cancelling and rolling back. CircleCI adds its own advice: review destructive actions before confirming, most of all on a shared or production-facing project. On Team or Enterprise, owners decide whether members may let some actions through without being asked, and they can cap what a connector may do for everyone. Claude works with your rights and nothing more: a project you cannot open in CircleCI stays closed to it.
Which Claude plans it runs on
Of the 819 sheets in the official directory, none shows plan availability. The connector-by-connector answer is not published anywhere.
The general rule is public: remote connectors are open to all users on Claude, Cowork, Claude Desktop and mobile. On Team and Enterprise, an Owner or Primary Owner enables the connector for the organization before each member can connect. For the current state, check the connector's sheet in the official directory. Worth knowing: only CircleCI documents this connector; there is no Claude help article for it.
Where this connector stops
A connector is not an automation. Claude calls these tools while it answers you; nothing starts when a build fails or a deploy finishes.
The tool list is an observed floor, not a promise: an admin can open actions no public sheet shows. The partner badge is not a security audit either, and Anthropic writes it on every sheet: it does not choose the tools a publisher exposes and does not guarantee they behave as described. Connect only what comes from a publisher you trust. If you want to compare with other connectors, they sit on the Integrations hub.
Need help connecting CircleCI to Claude?
A person reads every message.