MCP or CLI: the right answer depends on where your agent runs

Anthropic invented the Model Context Protocol in late 2024, and it has since become the standard way to let AI agents call external systems. My agents use it every day. They also spend a good part of the day typing plain commands into a terminal, an interface older than I am. So which is better?

Neither. The right answer depends on where the agent is running: your own machine, or a server you do not fully control.

That one variable decides it.

MCP: every server is a new interface to learn

If you run a service and want agents to use it, you build an MCP server for it. The server exposes a fixed, typed set of operations: the specific things an agent is allowed to do against that one service, and nothing else.

Take Linear. I use it to track my projects, and my agents use it to track their tasks, marking things done, moving work along. Linear built the MCP server my agents call into. It is fairly chunky, and it is Linear's job to maintain it, not mine.

That is the catch, though. Every MCP server is shaped differently, because every team builds theirs to fit their own service. Before an agent can call anything, it has to load that server's tool list and schemas into context and work out how the thing is put together, service by service, run by run.

Every MCP server is a restaurant that prints its own menu, and you have to read the whole menu before you are allowed to order.

CLI: ancient, and agents already know it cold

CLI stands for command line interface, and it has been around since close to the beginning of computers, decades before agents existed. You type a command into a terminal and it runs directly against your machine. No windows, no mouse.

The useful thing here is that an agent can type into a terminal just as easily as a person can. Git is the clean example: a CLI since 2005, and so common in every model's training data that the syntax lives in the weights rather than the context window. An LLM does not need documentation to run git. An agent runs git the way you drive home from work: no map, no directions, you just go.

Set that against MCP. An MCP call means loading tool definitions into context and reasoning over them before the first call goes out. A CLI the model already knows skips all of that: no schema to load, no menu to read. Every token an agent spends learning an interface comes out of the same budget as the actual work, so the saving is real.

On balance, I lean towards CLI these days, when I can.

If you build the service, ship both

Everything so far assumes you are the one running the agent. Flip it round. If you are the one building the service, the interface is your call, and nothing says you only get one.

A company can ship a CLI as well as an MCP server, or instead of one. The operations underneath are the same either way; you build them once and put two fronts on. Agents working somewhere they can run commands take the CLI and skip the menu-reading step entirely. Agents that cannot, or should not, run commands call the MCP server. GitHub already works like this, the gh CLI in the terminal and an MCP server everywhere else, and the agent takes whichever fits.

It is a bank with a branch and an app: the same account behind both, and you pick by where you are, not by which is better.

Where it flips: whose machine is this actually running on

A CLI is at its best on your own machine. Locally, an agent with shell access can reach your files, run git, drive the operating system itself, and that is exactly the point: it is your machine, and the blast radius is yours to own.

Put the same access on a server you do not fully control and the sums reverse. A CLI is arbitrary command execution, unbounded by design. If an agent with real shell access on your server misbehaves, or gets compromised, it has a route to the whole box. Unless the sandbox around it is genuine, that is a real path to losing the server.

MCP does not carry that exposure. An MCP server wraps one service and nothing more, a bounded set of typed calls where a shell is arbitrary commands, and even a misbehaving agent can only do what the server was built to let it do. That containment is what makes it safe on infrastructure you do not fully trust.

It sharpens again when the agent is not even yours. If a third party is using your system, an external customer wiring their own agent into your product, giving that agent CLI access is a very, very bad idea. You would be trusting code you have never read, driven by an agent you do not control, with shell-level access to your infrastructure.

Shell access is a master key to the building. An MCP server is a key to one room. You do not cut master keys for strangers.

So the rule I run on: my own machine, lean CLI. A server I do not fully control, lean MCP. Other people's agents calling into my system, MCP only. Same agent, same task even, different answer depending on where it is actually running.

Where Inkie landed

Inkie is that last case exactly. We are a hosted platform, and the agents calling in belong to our customers rather than to us. So there is no shell on offer. There is an MCP server, and that is deliberate.

What the server lets an agent do is the whole content job: create and schedule social posts and blog posts, generate and attach images and video, pull the content calendar to see what is planned and reschedule whatever needs to move. My own agents run their content pipeline through it every day, drafting, scheduling, swapping artwork, and none of it has ever needed them anywhere near a shell on our servers.

The trade-off from the top of this post still applies, mind. Inkie prints its own menu like every other MCP server, and an agent has to read it before it can order. I pay that cost gladly, given what the alternative is. The docs are at app.inkie.ink/docs/mcp if you want to point an agent at it.

A few common questions

Is MCP always safer than a CLI? Only once you factor in who is calling in. On your own machine, CLI is fine, the blast radius is yours. Handing shell access to someone else's agent is the unsafe part, not the interface itself.

Can I offer both a CLI and an MCP server for the same service? Yes, and it is often the right call. GitHub already does this: the gh CLI for local use, an MCP server for everything else, same operations underneath, two fronts.

Why is a CLI more token-efficient than MCP for an agent? Because the model already knows common CLIs like git from its training data. There is no tool schema to load into context first, so every call skips a step MCP always needs.

What does Inkie's own MCP server actually do? It lets an agent create and schedule social posts and blogs, generate and attach images and video, and manage the content calendar, the same bounded set of calls regardless of what the agent is trying to do.

If you are running agents against MCP servers, or handing them a shell, let me know where you have landed. And in the meantime, go out and make some cool shit.