CLI over MCP

The argument

The Model Context Protocol, or MCP, is a standard that gives AI agents structured access to external tools, letting an agent call an API, query a database, or control a service. It became the dominant integration approach adopted by most major agent frameworks. Peter Steinberger built his own agent tooling without MCP support and considers that a feature rather than a gap, arguing that command-line interfaces are the correct integration primitive for AI agents instead.¹

His reasoning rests on four points. CLIs were designed for humans: every command-line tool that exists was built and refined by people who found it useful, so the corpus of Unix tooling is the largest collection of validated human-usable interfaces in history, and agents trained on code are already expert Unix users who know how to use tools like grep, ffmpeg, and curl without being taught. "No insane human tries to call an MCP manually," Steinberger says. "You just want to use CLIs."¹ No restart is required: MCP servers must be configured at startup, so adding or changing a tool means restarting the session, while CLIs can be invoked on the fly in any session with no configuration change, letting an agent discover and use a new tool mid-task. Composability scales naturally: Unix pipes and standard input and output give CLIs composability built in, they chain, and they are testable, whereas MCP's own composition patterns are more complex: Steinberger points to Anthropic's own search feature tool, "something super custom for MCPs," still in beta because the problem is so gnarly.¹ And there is less cognitive overhead: MCPs require a config file, a restart workflow, and an understanding of the protocol, while CLIs require nothing beyond the binary being installed. As a practical bridge, Steinberger built a tool called MakePorter that converts MCP servers into CLIs, so any MCP can still be used as a CLI when no CLI equivalent yet exists.¹

Why it matters

This is a meaningful contrarian position in agent tooling. MCP was designed to solve the tool discovery and invocation problem for agents, but the argument is that this problem was already solved by Unix, and that MCP adds a new abstraction layer without proportional benefit. The deeper principle is to give agents tools designed for humans: agents are already competent Unix users, the tooling inventory is enormous, and the interface is stable, so inventing agent-specific integration protocols mostly creates new surface area to learn, configure, and maintain.

A hybrid in practice: X's developer platform

X's developer platform occupies a point in this design space that does not cleanly fall on either side. It ships both a pure command-line integration, where an agent calls the standalone xurl CLI binary directly with no protocol layer at all, and a hosted MCP integration built on that same binary: running xurl mcp turns it into a local bridge that lets any MCP client reach a hosted server exposing more than 200 tools.² The reason a bridge was needed at all is instructive: X's authorization model requires a registered developer application with no dynamic client registration and no native discovery mechanism, so MCP has no clean answer for authenticating a remote server as a specific user's account.³ The problem was solved the CLI way instead, with a local process that owns the PKCE login flow, caches the token, and auto-refreshes it, and that result was then wrapped in an MCP-compatible transport for clients that want structured, multi-tool, centrally versioned access.² A simpler fallback, a static, read-only App-only Bearer token pointed directly at the MCP endpoint with no bridge, exists side by side with it for callers who do not need write access or user context.

Enterprise case study: don't fight the weights

An internal engineering account from Sierra supplies a data point at enterprise scale, and it lands on a hybrid that partly vindicates the CLI argument even inside a heavily MCP-oriented company. Sierra's own name for the logic is "don't fight the weights": GitHub's full MCP server exposed hundreds of tools that bloated agent context, so the team had its agent mint a scoped read-only token and use the ordinary gh CLI instead, because agents already know that tool from training, and it did the same for the AWS CLI.⁴ That confirms the claim that agents are expert Unix users, demonstrated inside a large AI company rather than argued from outside one. But MCP still owns the parts CLIs are weak at: the team runs everything through a single internal MCP gateway for per-user permissioning, audit trails, cross-customer isolation, and discovery, the exact strengths MCP has over a bare CLI.⁴ Cerebras describes a similar posture, keeping its own retrieval tools as free of large-language-model overhead as possible so that any MCP-compatible agent becomes the orchestration layer rather than the protocol itself doing the reasoning.⁵

The resolved position at enterprise scale is therefore not CLI or MCP but a division of labor: CLI for execution the model already knows, MCP for authorization, auditing, and discovery, with MCP acting as the governed envelope and CLIs as the payload.

Tensions

MCP's real advantage may be structured output: CLIs return unstructured text, while MCP returns structured data, which matters for tasks that require reliably parsing a tool's response. Authorization and scoping are also a genuine gap, since MCP provides a natural mechanism for granting an agent a specific tool with specific permissions, while a CLI has no equivalent built in and an agent gets full access to whatever the CLI can do as the current user. Discoverability cuts the same way: MCP tooling is self-describing, registering its own capabilities, while CLIs require already knowing the tool exists and reading its documentation, which matters more for an agent operating in an unfamiliar environment. And the right answer may simply be scale-dependent: at the scale of one personal agent on one machine, CLI-first works cleanly, while at enterprise scale, with many agents, many tools, and audit requirements, MCP's structure may be closer to necessary.