MCP vs CLI: When to Build a Server and When to Just Use a Command

In 2026 you can give an AI agent a new capability in one of two ways. You build an MCP server, a structured tool the agent discovers over a protocol. Or you hand it a command line tool it runs in a shell. Both work. Both ship to production. The choice is an engineering call, and most of the arguments online treat it like a loyalty test instead.

I ship both. Some client integrations are MCP servers with proper auth. Others are a short script the agent calls with Bash. Here is how I actually decide, with the trade-offs laid out plainly and two cases where I landed on opposite answers.

TL;DR

An MCP server and a CLI are two ways to deliver the same thing: a capability your agent can call. Neither one wins on its own. CLIs are cheaper to set up, lighter on tokens, and they compose better. A script you already have becomes an agent tool for free, and Unix pipes still beat anything for gluing steps together. MCP servers earn their cost when you need real auth, persistent state, or reuse across people and projects. They carry OAuth, they hold a session open, and they advertise themselves to the model so you never have to explain they exist.

The question that actually decides it is rarely about power. It is about who uses this thing, how it logs in, whether it remembers anything between calls, and whether it has to leave your laptop. If the capability is glue for you alone, write a CLI. If it crosses a team, a third party’s login, or a live session, build the server. Most real stacks run both, and Claude Code does not care which is which when it calls them.

The two at a glance

Dimension	CLI tool	MCP server
Setup cost	Almost none. Wrap a script.	Real. Build the protocol, host it, add auth.
Token cost	Pay on output, no schema overhead	Tool definitions sit in context up front
Auth	Inherits your shell credentials	OAuth, scoped tokens, revocable
State / sessions	Cold on every call	Holds connections and session state
Composability	Unix pipes, jq, redirection	Composes inside the client only
Distribution & reuse	Local to your machine	Shared across clients and teammates
Discoverability	You tell the agent it exists	Advertised to the model automatically
Who uses it	You, technical, one machine	Teams, non-technical users, many clients

No single row settles it. Read the table as a menu. The right pick depends on which rows matter for the job in front of you.

What each one actually is

A CLI tool is any command the agent can run: curl, gh, your own deploy.sh, a Python script that hits an API. The agent runs it through Bash, reads what comes back, and moves on. Text in, text out. It is the oldest contract in computing and nothing has replaced it.

An MCP server exposes capabilities over the Model Context Protocol: typed tools with JSON schemas, served over stdio or Streamable HTTP, called by a client like Claude Code. If you want the protocol itself explained from scratch, I wrote that up in What Is MCP and Why Every Developer Needs It. Here I am assuming you know what it is and you are trying to decide when to use it.

One thing is worth holding onto. An MCP server and a CLI can wrap the same underlying API. The capability is never the difference. Everything around the capability is.

The dimensions that actually decide it

Tokens

This one cuts both ways, and the hot takes usually get it half right. MCP tool definitions load into the model’s context whether they fire or not, so ten servers with fat schemas cost you tokens before the agent does anything. A CLI costs nothing until it runs. But CLIs can pay it back on output. A raw curl dump is long and unstructured, and the model spends tokens reading it, where a decent MCP tool returns only the fields it promised. So a few sharp tools beat a pile of vague ones, and a CLI that returns clean JSON beats one that prints a wall of text.

Auth and blast radius

A CLI inherits whatever your shell can do. Fast, and a little scary, because the agent’s reach equals your credentials with nothing scoped down. MCP’s edge here is real. You get OAuth, narrow scopes, and tokens you can revoke without rotating your whole environment. The moment a capability touches a third party’s data or more than one user, auth alone often makes the call for you.

State

A CLI starts cold every time. That is fine for a one-shot request and useless for anything that needs a connection held open, a browser kept warm, a transaction running across several steps. MCP servers remember. If the job is “keep a headless browser alive across ten actions,” that is a server, not ten disconnected commands.

Composability

Here the CLI is hard to beat. Fifty years of Unix means your command pipes into jq, writes to a file, chains into git, drops inside a loop. MCP tools compose within the client’s orchestration but they do not pipe into each other. For messy, exploratory, glue-it-together work, the shell is still the most composable environment anyone has built.

Distribution and discoverability

This is where MCP is at home. A server is something you publish once and point every project or teammate at. It tells the model what tools it has, so the agent knows the capability is there without a prompt from you. A CLI lives on your machine and only fires if you, or your CLAUDE.md, mention it. If the thing has to travel past you, that is a server.

Two cases where the answer flipped

Where the CLI won: a Shopify Admin integration

I built a custom Shopify Admin MCP server once. Ran it for a month. Deleted it. The Admin API is already clean over a plain fetch, the agent could call it directly with a scoped token, and the server just gave me one more thing to maintain. Every tool it exposed was a thin wrapper over a request I could write in a line. When the job is “call this well-documented API I already have keys for,” the server is overhead. A small script does the same work and gets out of the way.

Where the server won: a storefront AI assistant

Flip the shape and the answer flips with it. I build AI assistants into client storefronts, and they need live access to catalog, inventory, and order state. That is not one tidy API call. It is authenticated access, scoped per client, often used by people on the client’s team who will never open a terminal, and reused across every storefront I run. Wrapping that as an MCP server is the right move. The auth, the per-client scoping, and the reuse all push the same direction. A pile of local scripts would mean rebuilding login and access on every machine, and handing a terminal to someone who does not want one.

The same logic holds for an AI tool you lean on rather than build. Say you are generating product or ad video with something like Higgsfield. For a one-off render you fire its API or CLI and move on. But the day a client’s marketing person needs to trigger it themselves, across projects, with their own access, you have crossed into server territory for the same reasons the storefront assistant did.

The pattern gets obvious once you have felt it a few times. If a capability wraps something already easy to call, it tends to get deleted. If it exposes state you cannot otherwise reach, behind a login, across machines, or held in a session, it tends to stay.

How I decide

Start with a CLI. Move to an MCP server when you hit one of these:

• It has to travel. Teammates or several client projects need the same capability.
• It logs into a third party. The work touches someone else’s data and needs scoped, revocable access.
• It holds state. A live session, an open connection, a browser kept warm across steps.
• Non-technical people use it. Someone who will never touch a terminal has to run it.
• The model should find it on its own, without you naming it every time.

Hit none of those and a CLI is quicker to build, lighter on context, and easier to compose. Hit one or more and the server pays for itself. Plenty of stacks run both at once. That is normal, and it is where most real work ends up.

FAQ

Is an MCP server just a wrapper around an API? Often it is, and that is the moment to ask whether you need it. A server earns its place when it adds auth, state, distribution, or discovery on top of the API. If it adds none of those, call the API directly.

Which is more token-efficient, MCP or a CLI? It depends on how you use them. MCP tool definitions sit in context whether they fire or not, so a stack of unused servers is wasted budget. CLIs cost nothing until they run, but they can return long output the model pays to read. A few sharp MCP tools, or a CLI that returns clean JSON, both keep the bill down.

Can Claude Code use MCP servers and CLIs at the same time? Yes. It calls MCP tools and runs shell commands in the same session without treating them differently. Most production setups mix the two: MCP for authenticated and shared capabilities, CLIs for local glue.

As a Shopify developer, when should I build an MCP server instead of calling the Admin API directly? Call the Admin API directly for most agent work. It is well documented and easy to reach with a scoped token. Build a server when store data has to go to non-technical teammates, when one integration has to serve many client projects, or when you need session state the API call alone does not keep.

Does MCP replace the command line? No. They solve different problems. MCP standardizes authenticated, discoverable, stateful tools across clients. The command line stays the fastest, most composable way to hand an agent a one-off capability. Most builders end up using both.

Is the CLI approach less secure? It can be. A CLI inherits your shell’s full credentials with nothing scoped, so the agent can do anything you can. MCP’s OAuth and tight scopes are a real advantage when the work touches sensitive or third-party data. For low-risk local tasks, a CLI’s simplicity is fine.

Tools mentioned

• Shopify CLI: direct Admin and Storefront access without an MCP layer
• Higgsfield: generative AI for product and ad video
• GitHub MCP Server
• Anthropic reference MCP servers

Last updated: 2026-06-11.