CLI

Command-line tooling as an interface to APIs across producing, consuming, governance, and MCP

The command-line interface is one of the most underappreciated and most durable interfaces to APIs we have, and it sits at an interesting intersection right now — between the API, the web console, the CI/CD pipeline, the governance toolchain, and the new world of MCP and AI agents. A CLI is, at its core, a client. It’s a thin command-line wrapper over a capability, usually an API, that lets a human or a machine invoke that capability from the terminal where developers actually work. I’ve watched the CLI go from the default way you operated early cloud platforms, to an afterthought during the GUI years, to a comeback as the place automation, governance, and now agentic interaction all converge.

The CLI as a first-class interface goes back, for me, to AWS. When I first onboarded with S3 and EC2 in 2006, there was only an API and a CLI — no GUI dashboard at all. The CLI was on equal footing with the API, and the console came later. That ordering — API first, CLI second, console third — is the API-first discipline made concrete, and AWS lived it more completely than anyone. They invested so seriously in the command line that they maintained a blog dedicated entirely to it, which I flagged in 2016 as a signal of how important the CLI is for reaching enterprise developers. My point then still holds: if your platform interface isn’t also available via a CLI, you might be missing an entire segment of the developer community. Enterprise developers, operations people, and anyone automating their work live in the terminal, and a platform that only offers a web console and an API, with no CLI, is invisible to them.

I wrote about the CLI making a comeback in 2019, and the reasons it came back are exactly the reasons it matters now. The CLI integrates into enterprise workflows. It runs in CI/CD pipelines. It transcends the boundaries of HTTP and individual languages. It’s keyboard-driven, scriptable, loggable, and repeatable in ways a GUI never is. The GUI is where you explore and learn; the CLI is where you operationalize. Once you know what you want to do and you need to do it a thousand times, reliably, in an automated pipeline, you reach for the command line. That’s why the CLI never actually went away — it just got quiet during the years everyone was building web dashboards, and then came roaring back as automation became central to how we operate APIs.

The original API CLI, and still the most important, is curl. I wrote about curl and APIs in 2025 with genuine envy — curl is from 1998 and has resisted a quarter century of churn, an industrial-grade utility that just works. Daniel Stenberg, who created it, is famously uninterested in the API hype and focused instead on the protocol stack underneath. curl is the foundational way developers consume APIs from the command line, the example you put in your documentation, the thing every developer reaches for to make a first call. Its timelessness brings clarity to what’s happening in the API industry — it separates the durable tooling from the theater. Almost every API on earth documents itself with a curl example, which makes curl the lowest-common-denominator CLI client for consuming APIs.

On the consuming side, the CLI is fundamentally how you turn an API into something you operate rather than something you read about. A CLI is a client for an API, and a lot of the modern API client conversation is really a CLI conversation. The unbundling of the API client — Bruno and Insomnia’s inso and Postman’s Newman emerging as Git-friendly, command-line-runnable alternatives — is about being able to take a collection and execute it from the terminal and in the pipeline, not just click through it in a desktop app. A Postman, Bruno, or Insomnia collection is an executable artifact you can run locally on the command line or bake into CI/CD. That’s the consuming story: the CLI lets you script your interactions with the APIs your business depends on, run them on a schedule with CRON, trigger them from events, and monitor your integrations continuously. I’ve made the point that you don’t always need agents to automate — requests, CRON jobs, and events from the command line already cover an enormous amount of automation. The CLI is the honest, durable automation surface that was there before the hype and will be there after it.

On the producing and governance side, the CLI is where the API lifecycle gets enforced. This is the heart of why CLIs matter for governance: the governance checks run as command-line tools. Spectral is a command-line linter for OpenAPI and other schemas, checking for the patterns and anti-patterns your organization cares about. You run the Spectral CLI locally, in your editor, and — most importantly — in your CI/CD pipeline, where it gates every change. The same is true across the whole producing toolchain: validation, OpenAPI bundling and transformation, contract testing with Newman or Bruno or Microcks, breaking-change detection, SDK and code generation with OpenAPI Generator or Kiota or APIMATIC’s CLI, and gateway deployment with the Kong, Tyk, or Zuplo CLIs. When I catalog what tools should be running in your pipeline, nearly every one of them is a CLI. The command line is how the machine-readable contract gets linted, tested, transformed, generated from, and deployed — automatically, repeatably, and enforceably. Governance you can talk about lives in a wiki; governance that actually happens runs as a CLI command in a pipeline that fails the build when the rules are violated.

The CLI is also tightly bound to Git, which I’ve long argued is the factory floor of API operations. The gh CLI and git itself are how you move API artifacts through the GitHub-centered lifecycle — committing OpenAPI definitions, triggering Actions, deploying generated SDKs to repositories that then drive the rest of the pipeline. GitHub as the API lifecycle engine and the CLI as the way you operate against it are two halves of the same workflow. The command line and source control together are the substrate on which definition-driven, GitOps-style API operations run.

Now the CLI’s role is being reframed again by MCP and AI agents, and this is where it gets genuinely interesting. An MCP server and a CLI are, in an important sense, the same kind of thing: both are interfaces that expose a capability to a consumer that isn’t a human clicking a web UI. A CLI exposes a capability to a human at a terminal or to a script in a pipeline; an MCP server exposes a capability to an AI agent. My consistent position is that agents are just the latest wave of API consumers and that nothing fundamental has changed — it’s all still APIs underneath. When I look at something like an MCP server for Microcks mocking and testing, what I see is the same programmatic access the CLI always provided, repackaged for an agent consumer. The terminal itself is becoming an agent surface — agents like Claude Code operate from the command line, calling CLIs and APIs the same way a developer would. So the CLI isn’t being replaced by MCP; the CLI, the API, and the MCP server are converging into a spectrum of interfaces over the same underlying capabilities, each one tuned for a different kind of consumer. The capability is the constant. The CLI is one of its most enduring faces.

That’s the throughline I’d want anyone to take from this. The CLI is a client and an interface, not a relic. It’s how enterprise developers and automation actually consume APIs, how governance checks get enforced in the pipeline, how producers generate and deploy and lint their contracts, and how the new generation of agents operates from the terminal. curl proved the model is timeless. AWS proved it belongs on equal footing with the API. Spectral and the pipeline toolchain proved it’s where governance gets teeth. And MCP is proving that the same instinct — wrap a capability in a thin, scriptable interface for a non-GUI consumer — is exactly what the agentic era needs. The command line has outlasted every interface trend that was supposed to replace it, because the need it serves — operating capabilities programmatically, repeatably, from where you already work — never goes away.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

References

Guidance Details

Explore more

Discover APIs