CircleCI's CLI is now a Go rewrite with an MCP server bolted on

CircleCI has rewritten its CLI from scratch in Go, shipping it as a 1.0 beta with a built-in MCP server for agent hosts like Claude, Cursor, and VS Code. The CLI emits JSON on every data-returning command, supports a --jq flag for inline querying, and includes a debugging TUI, structured error messages, and theme customization. CircleCI's design prioritizes human-first composability with opt-in piping, aiming to eliminate the rough edges that trip up coding agents.

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. 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. 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. 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. 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. 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. gh . gh has had --json on most commands for years and is the CLI many agents already know how to drive. If your pipeline is GitHub Actions, gh is the better fit here: your agents are almost certainly trained on it, and the copilot integrations landed first. glab . glab is the natural spine for agent integration and where GitLab's own MCP work lands first. bdy . bdy ; the whole point of the new CircleCI binary is that the native one now has an MCP server too.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." 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.