MCP has won — just not against the CLI

MCP has won — just not the contest its critics thought it was entering.

A year ago, one of the sharpest arguments against the Model Context Protocol went like this:

Most MCP servers would be better as CLIs.

Peter Steinberger put it plainly in the headline “Free the CLI from its MCP shackles.” Agents already know how to call command-line tools. CLIs can be loaded on demand, composed, and tested by humans and machines alike. Why fill the model's context with another layer of tool definitions?

It was a good critique.

But it was aimed at the wrong contest.

MCP did not need to beat the CLI. It needed to beat the bespoke integration between every AI product and every external system.

That contest now looks settled.

The curve is not subtle

On August 28, Vercel founder Guillermo Rauch pointed out that MCP is growing explosively. Not only on Vercel's platform, but also in downloads of its open-source mcp-handler package for building MCP servers.

The npm numbers support the direction:

mcp-handler · monthly npm downloads

May–August 2026 · August through 29/8

From 1.23 million in May to 3.45 million in August: +180%. Source: npm downloads API. Downloads are an ecosystem signal, not a count of unique users.

Vercel's Josh also reported that MCP tool calls on Vercel had grown 564 percent in three months: 43 percent in June, 117 percent in July, and 114 percent in August.

The official TypeScript SDK for MCP recorded 52.1 million npm downloads in the latest full week and almost 204 million over 30 days.

npm numbers need caveats. One download is not one person. CI runs, caches, and transitive dependencies all count. Vercel's tool-call number is also the company's own statement, not a public dataset we can audit.

Still, three signals point the same way: more people are building, installing, and calling MCP tools in production.

The interesting question is no longer whether the protocol has traction. It is why it caught on.

Peter was right about coding agents

Peter's argument was — and remains — strong inside a terminal environment.

A coding agent already has a shell, files, pipes, exit codes, and scripts. If a tool can explain itself through --help, return stable JSON, and behave deterministically, a CLI is often the shortest path from intent to action.

A large MCP server, by contrast, can place dozens of tool definitions into context before any of them are needed. It can make debugging less direct. And it can become an inferior copy of a mature tool that already exists — GitHub MCP versus gh is Peter's own example.

So the advice still holds:

Do not build an MCP wrapper merely because you can.

But that does not make MCP redundant. It only means MCP should not always be the tool's core.

That distinction matters.

CLI and MCP solve different problems

The CLI is an excellent interface inside a development environment.

MCP is a distribution standard between products.

An ordinary user in ChatGPT or Claude.ai does not have a terminal open. They do not want to install Homebrew, edit a JSON file, manage a local process, or learn the arguments for five commands.

They want to click connect, approve access, and say:

Find the latest customer case, compare it with our project plan, and create the three missing tasks.

Here, MCP is not an alternative to shell scripting. It is the standard connector between the conversation and the systems behind it.

Distribution is the turning point

Anthropic launched MCP in November 2024 with local support in Claude Desktop. By May 2025, it had expanded to remote MCP through Claude Integrations on web and desktop. At launch, users could connect Claude to ten services including Jira, Confluence, Zapier, Cloudflare, Asana, Sentry, PayPal, and Linear. One month later, Integrations reached Pro, Max, Team, and Enterprise plans.

OpenAI's current plugin architecture goes further. Its official documentation describes plugins as packages people can discover, install, share, and publish in ChatGPT and Codex. A plugin may contain skills, an MCP server, or both. ChatGPT and Codex even share one plugin directory.

That is the decisive shift.

MCP is no longer mainly something a developer adds to a local configuration file. It is becoming infrastructure behind a button in the AI products ordinary people already use.

When the same server can connect to Claude, ChatGPT, Codex, and other clients, the economics change for vendors. They no longer build one Claude integration, one ChatGPT integration, and a separate agent integration. They build an MCP server and let clients compete on user experience.

That is how standards win: not because they are always the most elegant technical solution, but because they remove enough duplicated work from both sides of the market.

From protocol to platform

MCP now has the boring infrastructure a standard needs in order to stick:

a public specification and SDKs
remote transport over HTTPS
an authorization model
an official registry with standardized metadata and namespace verification
formal governance under LF Projects
support across competing AI platforms

The registry is still in preview, and security remains a real concern. A standard makes software easier to connect; it does not automatically make that software trustworthy. Weak tool descriptions, overly broad permissions, and prompt injection do not disappear because the connection follows a specification.

But the change in the debate is itself evidence of maturity. We are no longer discussing only how a client starts a local process. We are discussing discovery, OAuth, registries, scopes, UI, enterprise policy, and governance.

Those are platform problems.

The architecture that survives

The funny part is that Peter's own Peekaboo 2.0 almost describes the architecture I expect to win.

He built the tool as a Swift CLI with a thin TypeScript MCP wrapper. When he wanted to free the functionality from an MCP-only approach, he made the CLI the central engine — but kept the MCP server.

Exactly.

Build a deterministic core that can be tested and used directly. Give coding agents CLI access when that is the best local interface. Add a thin MCP adapter when the tool needs to be discovered, authorized, and used across ChatGPT, Claude, and the next client.

It is not CLI or MCP.

It is CLI under MCP.

So, has MCP won?

Yes — if “won” means the market has selected a common integration language on top of which competitors now build distribution, registries, and user experiences.

No — if it means every function should become an MCP tool, or that an MCP wrapper is always better than a CLI.

Peter was right that too many local tools were turned into heavy MCP servers.

He was wrong if the conclusion was that this made the protocol itself irrelevant.

MCP did not win because agents suddenly became bad at using CLIs.

MCP won because ordinary users were never supposed to learn them.