Between the end of February and the middle of March, a lot of people declared the Model Context Protocol dead. One was a developer whose post reached the top of Hacker News. Another was Perplexity's CTO, speaking from a conference stage.
Seven months on, MCP is still here. By the end of July, the official SDKs were pulling close to half a billion downloads a month. An MCP developer summit is running in Toronto this week, and another conference, AGNTCon + MCPCon, comes to San Jose on October 22 and 23.
Downloads don't prove a design is good, so that settles nothing by itself. The complaints, though, were specific, which means you can check them. Here they are, one by one.
What MCP is, briefly
MCP is an open protocol that Anthropic released in November 2024. It's a standard way for an AI app to talk to a server that exposes tools, data or prompts.
Before it, connecting N apps to M services meant N×M custom integrations. A shared protocol cuts that to N+M. OpenAI and Google added support in 2025, and in December 2025 Anthropic gave the project to the Linux Foundation's Agentic AI Foundation.
The case against MCP
"Just use a CLI"
Eric Holmes published "MCP is dead. Long live the CLI." on February 28. His case starts with training data. Models have seen enormous amounts of shell usage, so telling an agent to run gh pr view 123 just works. Putting that same tool behind an MCP server means paying to teach the model something it already knows.
He also complained about local servers that won't start, and about auth that can't reuse the logins a CLI already has.
For a developer at a terminal with a mature command-line tool, that argument holds.
Perplexity steps away
On March 11, at its Ask 2026 conference, Perplexity's CTO Denis Yarats said the company was moving away from MCP internally, toward plain APIs and command-line tools. He gave two reasons: the context cost of tool definitions, and authentication that was hard to live with.
It was an internal engineering call, and Perplexity still runs a public MCP server for anyone who wants one.
The context bill
Every server you connect advertises its tools, and those definitions get loaded into the model's context before any work starts. A number that went around says three servers can use about 72% of a 200,000-token window. Coverage disagrees on which servers were in that setup, so read it as a worst case, not a typical one.
The cost is real anyway. Tools take up room the task needs, and a long list is harder for a model to pick from.
Security
In April 2025, researchers at Invariant Labs showed that a malicious tool description can carry hidden instructions. The model reads them and the user never sees them. In their proof of concept against Cursor, a tool that seemed to add two numbers was used to leak SSH keys and the user's MCP configuration.
A year later, on April 15, 2026, OX Security published an advisory about the STDIO transport in the official SDKs. A configured command is handed to the operating system without sanitization, so anyone who can influence that configuration can run commands on the host. OX says it reported this to Anthropic in January.
Anthropic's stated position is that the behavior is expected and that validating input is up to the developers building on the SDK. It updated its security guidance to urge caution. OX wanted a protocol-level fix that would cover everyone downstream.
At least ten CVEs have been issued against individual projects. OX estimates up to 200,000 exposed servers, which is its own estimate.
Starting a local program is what a local server does, so some of that risk is built in. Still, a default that runs any command string it's handed is easy to get wrong.
What the July release changed
The maintainers released the 2026-07-28 specification on July 28. It's the largest revision since launch, and it breaks compatibility with earlier versions.
The big change is that sessions are gone. The initialize handshake and the Mcp-Session-Id header are removed, and every request carries its own protocol version, client info and capabilities. Any request can now hit any server instance behind a plain round-robin load balancer.
Method and tool names also go in Mcp-Method and Mcp-Name headers, so gateways and firewalls can route and authorize without opening the JSON body.
A tool that needs a confirmation or a missing value mid-call no longer holds a stream open. The server returns an "input required" result and the client retries with the answer attached. Tool and resource lists also carry cache hints and a fixed order.
On auth, clients now have to validate the issuer on authorization responses, and Dynamic Client Registration is deprecated in favor of client metadata documents.
Tasks, MCP Apps and Enterprise-Managed Authorization became official extensions. Roots, Sampling, Logging and the old HTTP+SSE transport are deprecated, and nothing can be removed for at least twelve months.
The release didn't shrink tool definitions. Cache hints keep clients from refetching lists and keep prompt caches stable, but the schemas still take up space. The fix for that is coming from clients.
Claude Code now defers MCP tool definitions by default and loads one when the model asks for it. Cloudflare's Code Mode goes a different way and has the agent write code against the tools rather than call each one directly.
Cloudflare says an MCP server can now run in an ordinary Worker, and that MCP itself no longer needs a Durable Object. Honeycomb said in the release announcement that nearly 20% of its monthly interactive queries now come from agents.
What the skeptics said next
Simon Willison had seen MCP get overshadowed by Skills, by his own account, once it was clear that an agent with a terminal and curl could do most of the same work more flexibly. On July 31 he wrote that the new spec had pulled him back, calling it "the most significant change to the MCP spec since it first launched."
His reason is security. An agent with a shell and internet access is risky and needs a strong model to drive it. MCP tools are easier to audit and control, and simple enough that small models on a laptop can use them reasonably well. He also found the stateless spec much easier to build against, and made three tools with it in the first week: mcp-explorer, datasette-mcp and an alpha llm-mcp-client.
Charles Chen's March 14 post, "MCP is Dead; Long Live MCP!", split the argument by transport. Over stdio, where the server runs next to the agent, he agreed MCP usually isn't worth the complexity. Over streamable HTTP he saw something else: one central server with OAuth and telemetry, and no API keys handed out to every developer.
On token savings, he said the CLI wins for tools already in the training data, like git, curl, jq and psql. For custom tools the gap closes, because the agent has to read help text over several turns to learn them.
So which one should you use?
flowchart TD
A[Agent needs to use a tool] --> B{Does a well-known CLI exist?}
B -- Yes --> C{Shell on a trusted machine?}
C -- Yes --> D[Use the CLI]
C -- No --> E[Use MCP]
B -- No --> F{Needs auth, audit trail or many users?}
F -- Yes --> E
F -- No --> G[Small API wrapper or a lightweight MCP server]The CLI is the better pick when the agent has a shell on a machine you trust and the tool is one the model has seen thousands of times. Wrapping gh or git in an MCP server mostly adds overhead.
MCP makes more sense when there's no CLI to use. Your internal ticketing system probably doesn't ship one. People using a desktop AI app often don't have a terminal. And if you need per-user sign-in, an audit trail and rate limits, a remote MCP server is just HTTP, so the gateways and monitoring you already run apply.
Skills and MCP also do different jobs. A skill teaches an agent a procedure and MCP gives it access to a system. Bloomberg launched its Enterprise MCP this week with workflow-focused skills alongside it.
What is still unresolved
Prompt injection is still open. Tool descriptions and tool results go into the model's context as text it tends to trust, and nothing in the July release targets that. The release hardened the transport and the auth flow.
The servers are another weak spot. A sound protocol doesn't stop people shipping sloppy implementations. This week a researcher reported the same kind of server-side request forgery bug in MCP servers run by Google, JPMorgan Chase, Weaviate, France's DINUM and an Indonesian city government. Those are fixed, but he says some US federal servers still have open findings.
Then there's the migration. The old spec keeps working through the deprecation window, but teams that relied on sessions have real work ahead.
The verdict
MCP isn't dead. What was declared dead in March, a stateful, local-first protocol that loaded everything up front and got pitched as the way to connect anything to anything, is mostly gone.
What's left is plainer: HTTP requests, standard auth and a short list of named tools. That's duller, but it suits the jobs MCP was always good at.
For a developer on their own in a terminal, the CLI crowd was right. For something other people will use, with sign-in, logging and more than one user, MCP is still a sensible default.
If you're adding servers today, check how much context their definitions use before you add the next one, connect only what the agent needs, and treat everything a server returns as untrusted input. Build new remote servers against the 2026-07-28 spec.
Sources
The 2026-07-28 Specification, Model Context Protocol Blog
The next generation of MCP, Cloudflare
Stateless MCP has recaptured my interest, Simon Willison
MCP is dead. Long live the CLI, Eric Holmes
MCP is Dead; Long Live MCP!, Charles Chen
MCP Security Notification: Tool Poisoning Attacks, Invariant Labs
By-Design RCE in the MCP SDK, Cloud Security Alliance
Tool search, Claude Code docs
Google, JPMorgan and two governments fixed the same MCP flaw, The Next Web
Model Context Protocol, Agentic AI Foundation
Comments (0)
Join the discussion by logging into your account.
No comments yet. Be the first to comment!