The last time I asked a coding agent to look at a failed CircleCI job for me, it burned three tool calls parsing --help output and still picked the wrong flag. I laughed, then I stopped laughing, because I do this a lot now and every wasted turn is a real second off my afternoon. So when CircleCI posted on July 7 that they had rebuilt the CLI from scratch in Go and shipped it as a 1.0 beta with an MCP server baked in, I read the whole thing.
The rewrite in one paragraph
CircleCI's new CLI is a ground-up rewrite in Go, shipping as 1.0 beta and installable from cli.circleci.com. Per the post, every data-returning command emits JSON, the login is a browser OAuth flow with credentials in the system keyring, and there is a --jq flag built in so you can query the JSON payload without piping through another binary. There is also a debugging TUI built on charm/bubbletea, structured error messages with links back to the docs, theme customisation with a live preview, and respect for NO_COLOR, PAGER, DO_NOT_TRACK and CI=true. CircleCI describes the design as human-first with composability opt-in: pretty in a terminal, plain and pipeable the moment you redirect output.
The other headline is a first-party MCP server. circleci mcp claude enable, circleci mcp cursor enable and circleci mcp vscode enable wire the same binary up as an MCP transport for those three agent hosts, so your agent can call CircleCI directly instead of shelling out and hoping.
Why the JSON-everywhere promise matters at 3 pm
If your day involves an agent that reads pipeline output and decides what to do next, "predictable JSON on every command" is not a marketing bullet. It is the difference between a loop that resolves in one turn and a loop that eats your afternoon by wording and rewording --help prompts. Stable exit codes do the same job for control flow: an agent that has learned "0 means green, anything else means fetch the JSON payload and look at the error" stops trying to parse ANSI colour codes as facts. CircleCI's own framing is that coding agents cannot guess around rough edges the way a human can, so the rough edges had to go.
For the humans still in the loop, the same design gives you the composability you actually reach for when scripting a check. You can pipe into jq, or skip that and use --jq inline. Text at the terminal, JSON when you redirect stdout, no surprise ANSI in a log file. None of this is revolutionary. It is quietly correct, which is what I want from a CLI I run thirty times a day.
Getting it into your terminal
Install from cli.circleci.com; per the post, packages are there for multiple platforms. circleci run list and circleci run get give you pipeline shape, and circleci job get drops into a specific job. circleci setting set theme opens the theme picker with a live preview if you care about that (I do, more than I should). The MCP wire-up is a single subcommand per agent host: pick your editor, run circleci mcp <host> enable, and the CLI you already installed becomes the transport.
Rough edges worth naming
It is 1.0 beta. That is CircleCI's own label, not mine, and I would not gate a production rollout script on a beta CLI yet, even one this thoughtfully designed. The MCP server ships with three agent hosts named: Claude, Cursor and VS Code. If your team is on Zed, Aider, Continue.dev or something home-rolled, you are waiting for either an upstream add or a shim. And "predictable JSON on every command" is a promise until the first schema change lands. Stable-in-beta and stable-in-1.5 have to actually match, or the agents you trained against the beta will need a second training pass.
How other CI vendors are approaching the same demand
Every serious CI vendor is being pulled toward the same shape by coding agents. The interesting question is which CLI you should point your agent at, and the honest answer depends on where your pipelines already run.
GitHub CLI (gh). The reference point for a lot of us.ghhas had--jsonon most commands for years and is the CLI many agents already know how to drive. If your pipeline is GitHub Actions,ghis the better fit here: your agents are almost certainly trained on it, and the copilot integrations landed first.
GitLab CLI (glab). Same shape, GitLab-flavoured, with growing hooks into Duo. If you live in GitLab,glabis the natural spine for agent integration and where GitLab's own MCP work lands first.
CircleCI CLI (the new one). The concrete win is a first-party MCP server bundled into the CLI you were going to install anyway, plus JSON everywhere by design instead of by patch.
Buddy CLI (bdy). Buddy has its own CLI you can point at a Buddy pipeline. It is a fit if Buddy is already the runner in your stack and you want an agent to hang scripting and pipeline-scoped tokens off the same binary. If your CI is CircleCI or GitHub Actions, use the native CLI instead ofbdy; the whole point of the new CircleCI binary is that the native one now has an MCP server too.
Vendor-agnostic MCP servers. Community MCP server catalogs let a team compose one agent surface across every runner. More assembly work, but the surface survives a CI vendor swap, which is not nothing.
The framing choice for a platform team is not "which CLI is best." It is: given the CI vendor you are already paying, does the first-party CLI now speak the language your agents speak? For CircleCI users, the answer just changed from "sort of" to "yes, from a fresh binary."
What I am watching next
Two things. Whether the JSON schema stays stable through 1.0 GA, because that is the promise the agent story is built on. And whether the circleci mcp host list grows beyond three before agent-driven CI becomes the default flow for the rest of us. If both hold, this rewrite will be the quiet kind of change I only notice a month later, when I realise I stopped writing wrapper scripts.
SOCIAL SHARE CARD GENERATOR