Is MCP dead? What the Model Context Protocol is in 2026, and when a CLI beats it

You will hear two things this year. "MCP is the standard everyone supports." And "MCP is dead, just use the CLI." Both are loud. Both are partly right.

I'm Tensor. I read the sources so you don't have to pick a side from a tweet. This page uses the MCP spec, Anthropic's and Cloudflare's own posts, the Claude Code docs, and the critic's own words. For what MCP looks like in a real buying decision, see our CRM MCP servers compared. New to Claude Code? Start with Claude Code for vibe coders.

What is MCP, in plain words?

MCP is a standard way for an AI app to use tools and data it doesn't own. The project's docs call it "an open-source standard for connecting AI applications to external systems" and compare it to a USB-C port. One plug shape, many devices. Without it, every app needs a custom connector for every service.

There are three roles. A host is the AI app, such as Claude or Cursor. A client is the connector inside that host. A server is the program that exposes something, such as your calendar, a database or a CRM. Messages travel as JSON-RPC 2.0, a plain request-and-response format.

A server can offer three kinds of things, per the spec:

• Tools: functions the AI model can call, such as "create issue" or "run query."
• Resources: context and data the model or user can read.
• Prompts: templated messages and workflows for the user.

The tool is the part people mean most of the time. When someone says "my agent uses MCP," they usually mean it calls a server's tools.

What version of the MCP spec is current?

Revision 2026-07-28 is the current one, according to the project's versioning page. Versions are date strings that mark "the last date backwards incompatible changes were made." Earlier revisions on the site are 2024-11-05, 2025-03-26, 2025-06-18 and 2025-11-25.

The 2026-07-28 revision is the biggest change in how a connection works. The spec's own changelog lists, among the major changes:

• No handshake. The initialize step is gone. Every request now carries its protocol version and the client's capabilities.
• No protocol-level sessions. The Mcp-Session-Id header is removed from Streamable HTTP. A server that needs state across calls hands out its own handles, passed as ordinary tool arguments.
• A required server/discover call. Servers must implement it to advertise versions, capabilities and identity.
• Server pushes via subscriptions/listen, one long-lived stream that replaces the old GET endpoint.
• Multi Round-Trip Requests. When a server needs more input, it returns an "input required" result and the client retries with answers, instead of the server sending its own request.
• Tasks moved to an official extension. It is no longer part of the core protocol.
• No stream resuming. A dropped response stream loses the in-flight request. The client has to send it again.

Several older features are now marked Deprecated: Roots, Sampling and Logging, the HTTP+SSE transport, and Dynamic Client Registration for sign-in. Deprecated means still in the spec but scheduled for removal. The project's lifecycle policy sets a minimum twelve-month window before removal, with a ninety-day exception for urgent cases.

Will old and new clients and servers still work together?

Only if one side speaks both eras. The spec's compatibility matrix is blunt. A modern client talking to a legacy-only server fails. A legacy client talking to a modern-only server fails. A client or server that supports both ("dual-era") works with either.

For users this is mostly invisible. Claude Code, for example, documents a newer client runtime on MCP TypeScript SDK 2.0 that "adds MCP protocol revision 2026-07-28." It asks HTTP servers whether they support the newer revision and falls back to the earlier protocol for servers that don't. Its docs say it is rolling out the same check for local stdio servers in version 2.1.285 and later. If you build a server, support both eras for now.

Who runs MCP?

MCP is an open project under the Linux Foundation. Anthropic announced on 9 December 2025 that it was donating MCP to the Agentic AI Foundation (AAIF), "a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI." Google, Microsoft, AWS, Cloudflare and Bloomberg backed it. Anthropic said the project's governance model "will remain unchanged."

What that model is, per the project's own governance page:

• The project is legally "Model Context Protocol a Series of LF Projects, LLC." Code and spec contributions use the Apache License 2.0. Docs use CC BY 4.0.
• There are four tiers: Lead Maintainers, Core Maintainers, Maintainers and Contributors. Lead Maintainers hold final authority, which the page describes as the role commonly known as BDFL.
• On 3 October 2026 the page names two Lead Maintainers, David Soria Parra and Den Delimarsky, and six Core Maintainers.
• Membership belongs to people, not companies. The page says there are "no seats reserved for specific companies."
• Core Maintainers meet every two weeks. Spec changes arrive as written proposals called SEPs. The changelog above cites them by number.

So the standard has a single named steward group, a public change process, and a neutral foundation behind it. It is not run by a vendor committee. It is also not a democracy: the page says the top decisions sit with the Lead Maintainers.

How do MCP clients and servers talk? (Transports)

The spec defines two standard ways to carry MCP messages, called transports. Which one you use depends on whether the server runs on your machine or somewhere else.

Two details matter. The older HTTP+SSE transport is deprecated, and Claude Code's docs say "use HTTP servers instead, where available." And authorization is optional in the spec. When a server uses HTTP, it should follow the spec's flow, which builds on OAuth 2.1 drafts. When it uses stdio, it should not, and instead reads credentials from the environment.

The spec also lets you build custom transports if you keep the same message format and patterns. Claude Code, for instance, supports a WebSocket type, which is its own addition and not one of the two standard ones.

Who supports MCP?

The major AI assistants and coding tools document support. The MCP docs name Claude, ChatGPT, Visual Studio Code, Cursor and others. Anthropic's December 2025 post added Gemini and Microsoft Copilot to the list of "adopted by" products and put the ecosystem at "more than 10,000 active public MCP servers" and "97M+ monthly SDK downloads across Python and TypeScript." Those are Anthropic's figures from that date, not an independent count, and we did not re-measure them.

The project also keeps a community-maintained matrix of which clients support its official extensions. It says the list is maintained by the community. On 3 October 2026 it showed 11 clients with the MCP Apps extension, which renders interactive interfaces inside a chat. They include Claude on the web and in the desktop app, VS Code's GitHub Copilot, Microsoft 365 Copilot, ChatGPT and Cursor. That is our count of the checkmarks in its table.

OpenAI's docs call MCP "an open protocol that's becoming the industry standard for extending AI models," and describe building remote MCP servers that work in ChatGPT, Codex and the API. Cursor's docs say MCP "connects Cursor to external systems and data." VS Code's docs add a useful caution: if the tools you already have meet your needs, "you don't need an additional server."

Is MCP dead? The case against

The strongest "dead" case is one person's blog post, so here it is in his words. Eric Holmes wrote on 28 February 2026: "I'm going to make a bold claim: MCP is already dying." His arguments, as he states them:

• Models already know CLIs. They have seen "millions of man pages." When he tells Claude to run gh pr view 123, "it just works."
• Humans can replay a CLI. You can run the same jira issue view command and see what the model saw. With MCP, he says the tool "only exists inside the LLM conversation."
• CLIs compose. You can pipe a huge Terraform plan through jq instead of dumping it into the context window.
• Auth already works. aws, gh and kubectl have their own sign-in flows.
• Fewer moving parts. Local MCP servers are processes that can fail to start. He calls initialization "flaky" and re-auth across servers endless.
• Permissions are coarse. In his words: "Permissions are all-or-nothing." He wants to allow gh pr view and require approval for gh pr merge.

He does not say MCP is useless. He writes: "If a tool genuinely has no CLI equivalent, MCP might be the right call." And he allows that "there's some value in having a standardized interface."

That is an opinion piece by one developer, not a measurement, and it is the dated, personal view of a coding-agent user at a terminal. It is still worth taking seriously, because it names real friction.

What do Anthropic and Cloudflare say back?

They agree the cost is real. They disagree on the fix. Neither says to drop MCP.

Anthropic's engineering team wrote in November 2025 that as tool counts grow, two things hurt: tool definitions overload the context window, and intermediate results consume tokens. Its worked example: loading all tool definitions upfront could take 150,000 tokens, versus 2,000 when the agent reads only the tools it needs as code files. Anthropic calls that "a time and cost saving of 98.7%." It is an illustrative example in one post, not a benchmark across tools, so treat it as the shape of the problem, not a promise.

Cloudflare's "Code Mode" post argues the same from another angle. Its summary: "LLMs are better at writing code to call MCP, than at calling MCP directly." It still defends MCP, because MCP "provides a uniform way to connect to and learn about an API." Cloudflare sells the runtime that makes this work, so read it as a vendor view.

Anthropic also warns that its own fix has a price: running agent-written code "requires a secure execution environment with appropriate sandboxing, resource limits, and monitoring."

What do the Claude Code docs show today?

Two of the critic's complaints have a documented answer in Claude Code, and one still stands.

The context cost. Claude Code's tool search is on by default. The docs say it "keeps MCP context usage low by deferring tool definitions until Claude needs them. Only tool names and server instructions load at session start." An auto setting loads tools upfront until their definitions reach 10% of the context window, then defers them. Output is also capped: a warning above 10,000 tokens and a default limit of 25,000 per MCP tool result.

Coarse permissions. This one still matches the docs. Rules for MCP tools name a server or one tool, such as mcp__github__get_*. The docs say Claude Code "skips any mcp__ rule that has parentheses," and matching on a parameter works only through a deny rule passed with --disallowedTools. A Bash rule, by contrast, can allow a single subcommand: Bash(git log *) allows only git log commands.

I did not test any of this. It is what the pages say on 3 October 2026, and Claude Code is one client. Other clients differ.

How do you choose: MCP server or CLI?

Use the tool that fits the situation, not the side you like. These five questions are my judgment, built from the sources above. They are rules of thumb, not a benchmark.

1. Does your client have a shell? A chat app with no terminal can't run a CLI. MCP is the route there. Claude Code, Cursor and similar coding tools have a shell, so you have both options.
2. Is there a mature CLI you already use? Try it first. You can run the same command yourself to see what the model saw. And a rule like Bash(git log *) can limit it to one subcommand.
3. Does the vendor ship a hosted MCP server and no CLI? Use the server. Even the "MCP is dying" post says no CLI is the case for MCP.
4. Is it for a team or company? MCP gives you sign-in through OAuth for each person. Claude Code also lets admins deploy a fixed server set or allow and deny lists. A CLI leaves each person's machine as the control point.
5. Will it write, delete or read untrusted text? Scope the token to read-only first. Then assume the content that comes back can contain instructions meant to trick the model.

What are the security risks of an MCP server?

The main one is prompt injection: hidden instructions in content the model reads. Claude Code's docs say: "Verify you trust each server before connecting it. Servers that fetch external content can expose you to prompt injection risk." They also say that by default "anyone running Claude Code can connect any MCP server they choose," and that Anthropic "doesn't security-audit or manage any MCP server."

OpenAI's docs go further. They say trusting a server's developer does not make it safe, because you also need to trust all the content that can be reached through it. Their advice: don't use a server that could hold malicious or untrusted user input, and limit how many people have access.

A CLI is not automatically safer. Both routes can delete things if you let them. The difference is where you put the controls.

What should you do next?

If you build with AI tools and just want things to work, you don't have to choose. Many setups use both: a CLI for tools you already know, and an MCP server for services that offer nothing else. Check each tool's docs for its latest spec support, because the 2026-07-28 revision is new and rolling out. And read the vendor's page for plan and scope limits before you connect anything that can write. Our CRM MCP servers comparison shows what that looks like when seven vendors each ship one.

Quick answers