CircleCI released a new CLI on July 7, and it is not an incremental update. It is a ground-up rewrite in Go, designed for a workflow where the terminal and the browser trade places: the browser is where you review code and dashboards, and the terminal is where you debug CI failures, trigger runs, and now—interact with your agent.
The new CLI ships with a built-in MCP server, a terminal user interface for run inspection, native --json and --jq output on every command, OAuth login with system keyring storage, and a design guide written for humans and coding agents alike. For teams that live in the terminal, this is a meaningful quality-of-life upgrade. For teams preparing for agent-driven workflows, it is infrastructure.
Here is what changed, why the rewrite matters, and what the MCP integration means for developer tooling.
Why a Rewrite Instead of a Refactor
The existing CircleCI CLI served developers for years. It validated configs, triggered pipelines, and streamed logs from orb sources. Like most long-lived command-line tools, it accumulated edge cases, inconsistent exit codes, and output formats that were designed for human eyes, not for scripts or agents. The CircleCI team decided that patching around those issues would cost more than starting fresh.
The new CLI was written from scratch in Go, with a design guide written before the first commit. That guide lives in the repository’s agents/ directory, because it doubles as instructions for the coding agents that helped build parts of the tool. The philosophy is stated plainly: human-first, with composability opt-in. Beautiful in a terminal, plain and pipeable the moment you redirect output.
Every data-returning command gets --json. Every error is structured: what happened, why, what to try next, and where the docs are. Commands nest at most two levels deep. circleci config is your pipeline YAML; circleci setting is the CLI’s own configuration. The two are never mixed. These are not flashy features. They are the difference between a tool you fight and a tool that feels like it is on your side.
Built for Agents: The MCP Server Inside
The most distinctive feature of the new CLI is the MCP server built directly into the binary. MCP—the Model Context Protocol from Anthropic—is an open standard for connecting AI assistants to external data sources and tools. CircleCI embedded an MCP server so that agents can inspect CI runs, read job logs, and find failures without a human pointing them to the right pipeline.
Enabling it takes one command:
circleci mcp claude enable
circleci mcp cursor enable
circleci mcp vscode enable
The CLI registers itself with Claude Desktop, Cursor, VS Code, or any MCP-compatible client. The agent receives a set of tools to list runs, get job details, inspect step output, and read test results. No separate install, no glue code, no API token passed through environment variables to a third-party MCP bridge.
This matters because agent integration in CI/CD tooling is usually an afterthought. Teams build wrappers, parse HTML, or reverse-engineer internal APIs to let an agent understand what their pipelines are doing. By embedding the MCP server natively, CircleCI makes the CLI legible to agents by default. The same --json flags and stable exit codes that make the tool scriptable also make it agent-friendly. The generated llms.txt file exposes command documentation in a format optimized for LLM consumption.
Terminal UX Without the Browser
The CLI replaces a significant portion of the CircleCI web UI for day-to-day debugging. circleci run list shows recent runs inferred from your Git remote. circleci run get renders a full markdown report: workflows, jobs, outcomes, timings. circleci job get drills into a single job with per-step durations and exit codes.
The interactive terminal user interface, built on the charm/bubbletea stack, turns circleci run get with no arguments into a run picker: filter by trigger, status, and age; drill into workflows, jobs, and steps; page through output and jump to what failed. The loop that used to require six clicks in the web UI is navigable with a few keystrokes, entirely in the terminal.
Every data-returning command supports --json, and --jq is built in. You do not need jq installed, and output is colorized at a terminal and plain when piped. Names of failed jobs in one line:
circleci run get --json --jq '.workflows[].jobs[] | select(.outcome != "success").name'
Theming, Keyring Login, and Environment Awareness
The rendered output is fully themed. circleci setting set theme opens a live-preview picker: arrow through options and watch headings, tables, and inline code restyle in real time. Themes apply to all rendered output, not just the interactive flows.
Login no longer requires generating a personal API token in the web UI and pasting it into the terminal. Running circleci auth login picks your host and hands you off to the browser for OAuth. The token comes back stored in your system keyring, not a plaintext file. Personal access tokens are still available one arrow key away.
Environment variables are respected: NO_COLOR and your configured PAGER; DO_NOT_TRACK disables telemetry; CI=true implies non-interactive mode with no spinners and no update nags. TTY detection means output degrades sensibly when piped, and colors downsample for basic terminals. Discovery keeps you in the terminal: circleci help getting-started orients you, and circleci help environment documents every environment variable. The goal is never needing to leave the terminal to find out what the terminal can do.
The Larger Picture
The CircleCI CLI rewrite is a signal about where developer tooling is heading. For years, the industry built CLIs for humans and APIs for automation, with a gap in between that teams filled with brittle scripts. The new model, demonstrated by this CLI and by tools like the JetBrains AI IDE and GitHub’s Copilot CLI, is a single interface designed for both humans and agents from the ground up.
The implications for platform engineering teams are practical. If your CI/CD tooling exposes a clean, JSON-first, MCP-compatible surface, your internal agents can reason about builds, find failures, and suggest fixes without custom integration work. If it does not, you are writing that integration yourself. CircleCI’s decision to ship a native MCP server makes the tool immediately usable in agent-driven workflows, which is increasingly where developer productivity tools are being consumed.
The CLI is in beta now, installable from cli.circleci.com. The standards it sets for itself—structured errors, stable exit codes, agent-readable help text, and native MCP support—are the ones that other CI/CD tools will be measured against as agent integration becomes the default rather than the exception.


