Is MCP Dead? No, It Turned Into Plumbing
In spring 2025 I posted a chart with a red line going nearly straight up, and made a call I had no business being confident about.
The red line was modelcontextprotocol/servers, the reference implementation for the Model Context Protocol, or MCP: a standard way for AI agents to talk to tools and data. My prediction: "by end of year, MCP becomes like OAuth, invisible infrastructure we take for granted."[1]
I want to be honest about where I started, because the starting point is the interesting part. I shrugged MCP off at first. I came up through the content-management world, where I watched a decade of universal data standards get announced and then die off. CMIS. If you know, you know.
So I was not predicting from enthusiasm. I was predicting against my own priors.
What changed my mind was watching it escape the trap that kills those standards. A standard needs adoption to be useful and needs to be useful to get adoption, and almost nothing breaks that circle. MCP broke it. It got useful enough to attract adopters, which made it more useful, which attracted more.
What actually happened to the numbers
The prediction cashed. When I posted, the reference repository had roughly 18,000 to 20,000 stars. Two months later I added a comment on my own post because the pace was absurd: "over 60k." As of this morning, it sits at 89,306.[2]

That is roughly twenty months from an empty repository to a number most infrastructure projects never see. It also outran the agent frameworks everyone was talking about at the time, which is the part I did not expect.
Why do people say MCP is dead?
Because for one increasingly common kind of agent, it genuinely is unnecessary. That is the argument, and it deserves to be taken seriously rather than swatted away.
The sharpest version I have seen recently came from Michael Rollins, who argues in an Instagram Reel that MCP is a dead end for serious agent systems, and says his team dropped it months ago without missing it.[3]
The reasoning holds up. If your agent can write and run code, it does not need a protocol to reach an interface. It can read a short description and write the integration on the spot, adapting to anything, spending a fraction of the tokens a full tool schema costs, with no server for anyone to maintain.
For that class of agent, the protocol is a middleman. I use MCP every day in this studio and I still think that critique is correct on its own terms.
So is MCP actually dead?
Apply the OAuth test. When did you last hear a team debate whether they need OAuth? You do not argue about plumbing. You argue about things that are still deciding what they are.
The reason power users can route around MCP is that it already did the standardizing it set out to do. The interfaces got described. The patterns got learned. A code-writing agent can skip the abstraction precisely because the abstraction won the argument about what talking to a tool looks like.
That is not a corpse. That is what mature infrastructure feels like from the inside: boring, assumed, and no longer worth a conference talk.
Nobody writes think pieces about the electrical outlet.
I want to be careful about what I am claiming here, because "I was right" is a boring thing to read. The prediction was that MCP would become invisible, and the current round of obituaries is that invisibility arriving on schedule.
Being taken for granted is the win condition for a protocol. It is a strange one, because it looks exactly like being discarded.
When does MCP still make sense?
When the agent cannot write code, or should not be allowed to. That single line covers most of the real disagreement, and it is where the "dead" framing falls apart. The honest version of this is a table, not a verdict:
The bottom four rows are where I part company with the obituaries. If an agent should reach exactly three systems with exactly these permissions and leave an audit trail, "let it write code" is the wrong answer, because code execution is precisely the thing you are trying to avoid. That is a trust boundary drawn by design rather than assumed.
Charles Chen made the organizational half of this case in March, and it is the clearest statement of it I have read:
For enterprise and org-level use cases, MCP is the present and future and teams need to be able to cut through the hype of the moment.
Notice that Chen and Rollins are not actually contradicting each other.[4] One is describing a developer with a capable agent in a sandbox. The other is describing an organization with many agents, many people, and auditors. Both are right about their own layer.
Pick the interface per job, not per trend
The debate reads as a fight because both sides say "MCP" and mean different systems. Strip the label off and the disagreement mostly dissolves into an architecture question: at which layer does this particular integration belong?
That question has a real answer per case, and it is the same skill as choosing the right interface for the place.
A trusted agent doing exploratory work in its own environment should write the integration. A fleet of agents touching customer data through a permissioned surface should go through a described, governed interface. Those are not competing philosophies. They are different layers of the same system.
The trend cycle will keep announcing the death of whichever layer has gone quiet.
The quiet layer is usually the one holding the weight.
AI can build anything, which is exactly why building the right thing now includes choosing what each piece should talk through. Sometimes that is a protocol. Sometimes it is fifteen lines of code the agent writes and throws away. Knowing which is the job.
References
Frequently asked
Is MCP (Model Context Protocol) dead?›No, but its role is narrowing. The argument against it is that an agent which can write and run code can integrate with any interface directly, no protocol server required, and often more cheaply.
Why do people say MCP is dead?›Because for agents that already write and run code, a short description of an interface lets the agent build the integration on the fly, using far fewer tokens than loading a full tool schema, and adapting to anything without someone maintaining a server.
When does MCP still make sense?›When the agent cannot or should not simply write code. Chat assistants with no place to run anything, smaller models, and any setting where you want a governed, audited, discoverable interface rather than arbitrary code execution.
Should we build MCP servers or let agents write their own integrations?›Both, for different jobs. Let trusted, code-writing agents integrate directly when speed and flexibility win.
Let’s build it together.
We turn clever prototypes into production systems people can rely on. If you’re building with agents and want a hand making it real, leave your email and we’ll be in touch.