METAHEURISTIC
You have spent months building MCP servers that replicate SaaS APIs, and one morning you notice you cannot say what they are for. The agent can read an OpenAPI spec now. It can run a CLI. The server sits between the model and an API that already existed, translating one JSON into another JSON, and the main thing it seems to provide is that everybody agreed to use it. So you ask the question out loud, and the answers come back in camps that have been having the same fight for a year without noticing they agree.
I wrote the abstraction tax in July making the case for the plain binary, so I have been reading every version of this argument since, looking for the one that would change my mind. Two did, a little. But the more useful thing is what happens when you sort the arguments by what they actually claim rather than by which side they think they are on. The camps are fighting over the wrong noun.
Five takes, scored
Strip the argument to the claims it rests on and there are five. The strongest, and the one that anyone who has shipped several servers eventually arrives at, is that an MCP server should not be an API wrapper at all. It should be a second frontend for your backend, built for a model the way the UI is built for a person: less granular than the API, task-shaped rather than CRUD-shaped. Backend-for-frontend, where the frontend is an agent. Or, if you prefer the testing analogy, the API is the unit and the tool is the workflow. A server that exposes forty CRUD routes one-to-one is not a counterexample to this. It is a badly designed server, and most of the ones in the wild are exactly that.
The second take is the flat report from large engineering organisations that dropped the protocol internally as too much overhead and have agents use RPCs and CLIs directly, with a skill that teaches the agent the tool. The third is authentication, and it is the only pro-server argument that the CLI camp does not have a rebuttal for. The fourth is tokens, argued in both directions with equal confidence and almost never measured. The fifth is consensus: use it because everyone else did, so the permission and governance products are built around it. That one is true and it is not an argument about the design.
What almost nobody points out is that the top two takes, which are treated as opposing
sides, are not in conflict. The BFF argument says: do not expose forty CRUD endpoints to a
model, expose a small number of task-shaped operations with good names and trimmed
responses. The dropped-at-scale argument says: do not run a protocol server, hand the
agent a CLI and a skill. Both are correct, and you can do both at once, because a CLI
with a create-invoice-and-email subcommand is a backend-for-frontend. The transport is
not the part that made the first take right.
The synthesis in one line: The value is in the pruning and the naming, not the transport. Neither camp’s best argument requires JSON-RPC over stdio to be true.
The token argument is over, on both sides
Half of every version of this fight is about context cost, and all of it is out of date. The server camp says a raw OpenAPI spec dumped into context costs thousands of tokens and the model still guesses wrong on multi-step flows. The CLI camp says a server loading every schema on connect costs more. Both were true a year ago and both have been fixed by the same move: stop loading things up front. Skills load documentation on demand. Tool search and deferred loading do the same for server schemas, which I covered in July as the protocol’s own steward walking back its founding ergonomic. Gateways with semantic tool search now expose a handful of definitions out of thousands.
So the honest scoreboard for tokens is a draw, and a draw that keeps getting argued because it had become a proxy for the real disagreement. When two sides have both solved a problem and keep citing it, the problem was never the point. The fight is over who owns the layer between the model and the system, and that is an authentication and governance question wearing a token-count costume.
Where I have moved
Two things. The first is elicitation. A subprocess only goes one way: you invoke it, it returns stdout. An MCP server can pause mid-call and ask the user for structured input through the client, which the spec added in the June 2025 revision. I had filed authentication as the protocol’s one honest advantage in July and treated it as narrow. The pause-and-ask capability is broader than I gave it credit for: a tool that can stop and say “this will refund four hundred dollars, confirm” is doing something a binary returning text cannot do without the harness inventing its own protocol for it. If your tools need to negotiate with the human mid-flight, the server model earns its place.
The second is over-provisioning. Give an agent the full API with a bearer token and you have granted it every operation that token can perform, whether or not the task needs it. A server that surfaces only approved tools is a permission surface you can reason about. I made the mirror of this argument in July, that the permission gate belongs in compiled code, and I stand by it, but I under-weighted how many teams have no compiled code in the path at all. They have a model, a shell, and a token in an environment variable. For them, the server is the first place a permission boundary has ever existed, and telling them to go write a Go binary is not advice they will take this quarter.
What the fight actually settles: The disagreement is not MCP versus API. It is whether the layer between the model and the system is task-shaped and permission-scoped, or a raw surface with a key. Both camps want the former. They differ on who builds it.
Where I have not
The maintenance argument, that a server lets you fix auth or an endpoint in one place
instead of in every agent that learned the API separately, answers itself: you are
maintaining a second layer either way, and a CLI is also one place. The consistency
argument, that the protocol gives agents a common way to find tools, is the consensus
argument with different wording. And the claim that newer models are trained specifically
for MCP and therefore call it more reliably than HTTP is the one I would most like to see
measured, because models are trained on tool calling, and a CLI with a --help tree is a
tool call with a discovery step the model has seen in a billion shell transcripts.
The “servers are more secure” claim cuts both ways, as it does everywhere. One side: a server hides keys and limits the surface. The other: a server can return a hidden instruction in its response as easily as an API can, and trusting either is a mistake. Both are right. Neither is an argument for the transport. They are arguments for putting a verifier at every hop, which is the harness argument again in a different costume.
The decision, updated
Here is the call as I would make it today, and it is a revision of July rather than a
reversal. If you own both sides, the agent and the system it calls, build a task-shaped
CLI with good --help, ship a skill that teaches it, and put the permission logic in the
binary. That is the BFF the first take asks for, without a server to operate, and it runs
in every harness that can spawn a process, which is all of them.
If the consumer and the provider are different organisations, the calculus changes, and I think this is the sharpest single dividing line in the whole argument. You cannot ship a binary into someone else’s client. You cannot ask their users to manage a bearer token. You may need to pause and ask them something mid-call. That is where the protocol’s auth flow, elicitation and a single governance chokepoint earn their overhead, and a CLI has no equivalent to offer.
The figure above is the whole post as five switches. Flip them for your situation and read the verdict; the reasons update with it. What it will tell you, for most internal tooling, is what the dropped-at-scale camp says in one line and the BFF camp says in five paragraphs: the thing that makes an agent tool good is pruning, naming, and a permission boundary that does not live in a prompt. Get those right and the transport is a detail. Get them wrong and no protocol will save you.
The lazy ending is that this is an unremarkable engineering question: use the standard when it helps and not when it does not. That is correct and useless, because the whole job is knowing when. It helps when you do not own the other side. It does not when you do. Everything else is tokens, and tokens are a solved argument.
