CLI Tools over MCP Servers

A tool-surface preference: give an agent capabilities through command-line tools it invokes via Bash, rather than through MCP servers, then wrap the CLI in your own skill. The argument has two parts. Token efficiency — an MCP server's tool schemas and verbose structured results are loaded into and returned through the context window; a CLI is called on demand and returns only what you ask for, so agents "operate with pretty great token efficiency" using the CLI. Extensibility / own-the-contract — an MCP server is "rigid: you have to do it their way, however the server is built," whereas a CLI is a plain surface you can build on top of in your own opinionated way — the skill you write around it sets defaults, named sessions, and workflow conventions that the raw server would never expose.

Concretely: instead of a Playwright MCP server, the operator uses the Playwright CLI (microsoft/playwright-cli — "CLI for common Playwright actions… inspect selectors and take screenshots") and wraps it in a skill that adds headless-by-default, parallel named sessions, and persistent profiles for login state. This is the Agent-Computer Interface (ACI) principle applied at the choice-of-surface level: the CLI + your skill is a better-engineered ACI than the off-the-shelf MCP server.

Note the boundary: MCP still earns its place where you need a live, stateful, or capability-negotiated connection a shell-out can't give (streaming resources, auth handshakes, servers you don't control). The claim is a default lean, not an absolute.

Claims

Prefer CLI tools (wrapped in your own skill) over MCP servers for agent capabilities. best practice — context: capabilities that map cleanly to a command you can shell out to and where you want to own the conventions; MCP still fits stateful/streaming/negotiated connections. Stated as a default, not an invariant.
MCP servers spend context tokens and constrain you to their fixed interface; a CLI returns only what you request and can be extended on top. observation — the two concrete costs (token overhead, rigidity) that motivate the preference in the demonstrated setting.
Wrapping a CLI in a skill lets you set opinionated defaults (headless, named sessions, persistent profiles) the raw tool doesn't impose. best practice — context: building a reusable capability layer; the wrapper is where reuse and specialization live, and it's contingent on the underlying CLI being stable enough to build on.
The tool surface you choose is itself an ACI decision — pick the one that's cheapest for the model to drive and easiest for you to shape. principle — durable: interface quality gates agent reliability regardless of whether the surface is a CLI or a server.
An agent-first context/memory store is naturally a CLI the agent drives, not a server or a human UI — "written for agents, easy for agents to use," a human almost never runs it. (best practice) — context: the agent-to-agent memory channel (a Context Substrate); a second independent source builds exactly this as CLIs (mulch's ml, seeds' sd) whose commands agents invoke via Bash, corroborating that when the model is the primary caller the fitted surface is a token-efficient CLI you own.
A tool that wants agents to drive it can ship its own skill wrapping its CLI, so the agent loads the skill and shells out to subcommands. best practice — context: a third-party interactive tool (a diff viewer) exposing an agent integration; Hunk ships a hunk-review skill the agent loads via hunk skill path, then reads/writes review comments with hunk session comment list --repo . --type live. Corroborates the skill-wraps-a-CLI surface from the vendor side — the tool author, not the operator, writes the wrapping skill. See Shared Review Surface.
Keep the CLI engine as the brain and offer MCP as a thin bridge, not the primary surface. best practice — context: a capability pack for agents that also want desktop/tool-client reach; a third independent source (Buildable) makes a dependency-free CLI the engine and its MCP bridge a compatibility shim that "does not load the whole brain" — each MCP tool calls the same CLI and returns a compact plan plus the exact references to load, so MCP stays as token-light as the CLI. Corroborates the token-efficiency argument and the "prefer the CLI, reach for MCP only where the surface can't run project commands" default.

Agent-Computer Interface (ACI) — this is ACI at the level of which surface to expose; a CLI + skill is a hand-tuned ACI vs. an off-the-shelf MCP server.
Layered Agentic Architecture — the CLI-backed skill is the capability layer the whole stack is built on.
Agentic UI Testing — the Playwright CLI is what the UI-testing agents drive; token efficiency is why parallel browser agents stay affordable.
Context Substrate — an agent-first, structured memory layer delivered as an ml/sd CLI; a concrete case of "the store is a CLI the agent drives."
Distillate: My 4-Layer Claude Code + Playwright CLI Skill (Agentic Browser Automation & UI Testing)
Distillate: The Agentic Engineering Meta — mulch/seeds are agent-first CLIs, corroborating the CLI-as-agent-surface preference from the memory-store angle.
Distillate: Buildable — A Local, Build-Verified App-Builder Brain for Coding Agents — CLI engine as the brain, MCP as a thin compatibility bridge that "does not load the whole brain"; a third witness for the default lean.
Distillate: Hunk: the review diff as a two-way human↔︎agent annotation channel — a vendor-shipped skill (hunk-review) wraps the hunk CLI so the coding agent can drive the diff viewer.
Shared Review Surface — what the wrapped CLI enables here: a bidirectional annotation store the agent reads and writes through the loaded skill.

CLI Tools over MCP Servers

Claims

Related

Linked from