I’ll just say it plainly. MCP is dead technology, and I don’t think it’s particularly close. There’s a whole group full of people arguing about this exact question right now, and I told them the same thing I’m about to tell you: I don’t think MCP survives contact with what agents are actually capable of today. Here’s my reasoning, and I’ll try to lay it out properly instead of just ranting.
Why I think this
Start from one fact. A properly harnessed agent, meaning one that has a real execution environment and can actually run code, can write whatever integration it needs on demand. Give it an API, give it credentials, and it will figure out the request format, handle the response, and move on.
It doesn’t need a pre-built tool sitting between it and the API. It just needs the ability to write and execute a script, which is table stakes for any serious coding agent at this point.
That’s the whole argument, really. MCP exists to solve a problem that harnessed agents don’t have anymore.
We stopped using MCP internally something like six or seven months ago. Not gradually, just stopped, and never went back. Our AI agents build their own integrations as they go, on the fly, for whatever the task needs. I genuinely can’t remember the last time someone on the team brought it up as something we were missing.
Where I think it still earns its keep
To be honest, I want to be fair here, because “dead” doesn’t really mean “useless in every context of the technology,” and I think a lot of the loudest takes on both sides skip this part.
If you’re working with an unharnessed model where people don’t understand code, meaning plain chat with no code execution, no sandbox, nothing, MCP is doing real work here. It’s the only way that kind of model reaches outside its own context window.
The same logic applies to smaller open models in the 7B to 15B range, in theory, since they’re not always paired with strong coding ability. Though in practice, most people running models that size are running them specifically for code generation, which puts you right back in the harnessed-agent camp and here’s the part that the argument collapses again.
So the honest version of my position isn’t “MCP has zero use cases.” It’s “MCP’s use cases are shrinking every time agent harnessing gets better,” and harnessing is getting better fast every single day.
The part people bring up that’s worth taking seriously
The pushback I hear most often isn’t really about whether an agent can write a script to hit an API. It’s about everything around that call.
Auth flows, token refresh, rate limits, session state that needs to persist across turns, none of that goes away just because the AI agent is capable of writing raw HTTP requests.
A maintained MCP server handles a lot of that plumbing once, so nobody has to reinvent it per task, per agent, or per API.
That’s a fair point and I don’t think it fully cancels out my argument, but it does narrow it. My read is that this plumbing problem is exactly the kind of thing agents are going to get better at handling themselves, the same way they got better at writing their own integrations in the first place. It’s not something MCP gets to keep forever, it’s just a temporary one.
There’s also a standardization argument worth naming, honestly. Even if a capable agent could write a bespoke client every time, a shared protocol means someone builds the integration once and everyone reuses it, instead of every team writing the same Stripe or Slack client from scratch.
That’s a real efficiency gain at the ecosystem level, separate from whether any single agent technically needs it.
Where I land
None of this is a moral judgment on the people building MCP servers or the teams relying on them today. If you’re not running harnessed, code-executing agents, or you’re building for an audience that isn’t, MCP is a reasonable tool and probably the right one for your situation right now.
But if you’re asking me where the trend line is pointing, I think it points toward MCP mattering less every quarter, not more.
Harnessed agents are getting cheaper, more capable, and more common, and every one of those movements shrinks the slice of the market where MCP is actually necessary rather than just convenient.
Make your own call on this one.
I’ve been wrong before and I’ll be wrong again. But that’s where I stand right now, for whatever that’s worth.
Top comments (1)
Writing the integration on demand works until the agent has to pick which API to write it against. That's the part we kept MCP for at ApyHub (I co-founded it): four tools (catalog, search, spec, call) over 1,500+ endpoints and counting, behind one subscription, so the auth plumbing you list at the end is already handled. What does your harness do when the API it picked needs a signup first?