Namsang Labs
Radar · #ai #mcp #cli #developer-tools #ai-agent

MCP, Unnecessary for Individuals and Incomplete for Organizations

· Sangkyoon Nam
Also in 한국어 , 日本語

On the left pedestal a terminal connects straight to a toolbox with one short cable while an MCP adapter sits pushed aside. On the right, a large MCP hub takes cables from many terminals, but its padlock slot is empty

On March 25, 2026, a tally put monthly SDK downloads for MCP (Model Context Protocol) past 97 million. That’s 16 months after its November 2024 launch, and by the numbers alone MCP won.

Another scene from the same month points the other way. Perplexity CTO Denis Yarats said at the Ask 2026 conference that they had started pulling MCP out of their flagship product over production cost. Y Combinator CEO Garry Tan wrote on X that MCP wasn’t much good, adding that he’d built a Playwright CLI wrapper in 30 minutes that night and was using it instead of MCP.

There are things 97 million downloads don’t tell you.

#The space the schema eats

Most MCP clients put tool schemas into the model’s context window up front. Each tool brings what commands it has, what arguments it takes, and what it returns, so every tool you attach shrinks the space the model has for the task, and accuracy tends to drop with it.

The reasons Yarats gave were two: context window consumption and auth. Secondhand reports carry a figure that schemas ate 72% of the context, but I couldn’t confirm from the talk itself whether that number is Perplexity’s own measurement or was carried over from another deployment. What is certain is that the more often an agent calls tools, the more this cost piles up.

“MCP sucks honestly. It eats too much context window and you have to toggle it on and off and the auth sucks.”

Source: Garry Tan, X

What Tan built instead was a Playwright CLI wrapper, and once he’d built it, he said, he found Vercel had already made the same thing. Perplexity kept its MCP servers but moved the flagship product to its own REST-based agent API.

This cost isn’t the protocol’s fate. In November 2025 Anthropic published an approach where, instead of loading every tool definition up front, the agent pulls in only the tools it needs through code, and said that in its example 150,000 tokens dropped to 2,000. But that same post wrote that most MCP clients load all tool definitions into the context up front. Lazy loading is a workaround each client has to implement on its own, not the default behavior of common implementations, and the numbers above come from the common approach of loading tool definitions up front.

#Give an LLM a CLI and it figures it out

On February 28, 2026, Eric Holmes wrote that LLMs are already good at using command-line tools. They’ve been trained on millions of man pages, Stack Overflow answers, and GitHub repos full of shell scripts. He made three points.

  • Debugging: MCP means digging through JSON logs. With a CLI, one line of jira issue view shows you the same result the agent saw.
  • Auth: MCP has to implement its own authentication scheme. A CLI reuses the auth that’s already there, like AWS SSO, GitHub CLI, and kubeconfig. No extra work whether a human or an agent is using it.
  • Operations: An MCP server needs a separate process running and state managed. A CLI runs the installed command and that’s it.

Survey results point the same way as Holmes. Claude Code, which topped the Pragmatic Engineer survey of 900 developers in early 2026, supports MCP, but its default behavior is to work with files and CLIs directly from the terminal. Among that survey’s respondents, the most used tool is one designed to run without MCP.

#A spec that doesn’t enforce auth

The auth numbers are worse. In July 2025 the security firm Knostic hand-verified 119 of the 1,862 MCP servers exposed on the internet. All 119 handed out their tool lists without authentication. The researchers noted that they didn’t actually execute the tools.

Three months later, in October 2025, Astrix analyzed 5,200 open-source MCP servers and found that 88% did require credentials. But 53% of the total leaned on long-lived secrets like static API keys and personal access tokens, and only 8.5% used OAuth. There’s auth, but it’s auth that swings wide open the moment a key leaks. These numbers count not how a client authenticates to an MCP server, but what kind of key the MCP server uses to connect to the backend service behind it, like GitHub or Postgres. The auth the spec covers is the front side, and for the back side it only notes the responsibility for storing third-party OAuth tokens, without standardizing how static keys are issued, rotated, or revoked.

As I see it, the zero on the front side isn’t ecosystem immaturity but the MCP spec leaving authentication optional for HTTP transport, and the 53% on the back side is there because the spec barely touches that spot. When the spec doesn’t require it, server builders leave it out or make do with a static key, and in an ecosystem where open-source servers pour out by the thousands, that result is the predictable one. It isn’t a problem that time resolves. The spec has to change.

#So is MCP dead

As 97 million downloads show, MCP is still in use. The prescription depends on who’s using it, though. As Charles Chen drew the line, an individual using a coding agent and an organization adopting a protocol are different problems.

For an individual developer using a coding agent, MCP is overhead. There’s no reason to spin up an MCP server for something gh pr create finishes. But “organizations need MCP” is too easy a conclusion as well. CLIs like gh, aws, and gcloud already support org-level SSO and audit logs, and being an organization doesn’t by itself make MCP necessary.

Holmes’s argument for the CLI holds for tools like git and curl that are already all over the training data, but a custom CLI built in-house is a tool the LLM has never seen, so the schema is needed again. The more custom tools an organization has, the less the CLI alone covers.

So the conditions that call for MCP are narrower still. Hundreds of people reaching dozens of in-house custom tools, with central auth and audit required, and a tool catalog that changes often. Even there, until the spec makes auth mandatory, MCP can only be used under limited conditions. The fact that the enterprise readiness items on the MCP 2026 roadmap are still in discussion ahead of a formal proposal shows this gap. The need is clear, but the spec isn’t there.

For an individual developer using a coding agent, MCP is already unnecessary. For organizations, MCP is still incomplete.

#References

Share this post