MCP Is the MDX of the AI Era
MCP is the worst kind of quick-and-dirty abstraction the industry has produced in a while. It is half-baked, nearly impossible to vet, and somehow every productivity influencer on the timeline is telling you to install fifteen of them off random GitHub repos. We are speedrunning a security disaster and calling it developer experience.
I keep coming back to the same line in my head: MCP is the MDX of the AI era. A clever idea that sounds great in a demo, gets adopted way too fast, and quietly turns into a mess everyone has to live with.
The Trust Problem Is Not Solvable
Researchers have been flagging the obvious for months. Credential theft. Prompt injection. Tool poisoning. Lookalike servers quietly replacing the trusted ones you thought you installed. Anthropic’s response has effectively been “secure-by-default is the developer’s responsibility,” which is the kind of thing you say when you have shipped an abstraction that cannot actually be secured by default.
And the audience installing these things is not a security researcher. It is a vibe coder following a YouTube tutorial. They are running npx some-random-mcp-server and handing it their filesystem, their GitHub token, and their Slack workspace because someone with a ring light told them it would 10x their workflow. There is no signing story. There is no real review process. There is no sandbox. There is a JSON config file and a lot of trust nobody earned.
Roughly 89% of MCP tool descriptions have documented “smells” - unstated limitations, missing usage guidelines, opaque parameters. That is not a rough edge. That is the whole surface.
It Blows Out Your Context for No Reason
Here is the part that bothers me as an engineer rather than a security person. MCP servers stuff your context window full of tool definitions whether you are using them or not. You connect to a server with forty tools because you wanted one of them, and now every message you send is paying for the description of the other thirty-nine.
This is not a small tax. It compounds across every server you have connected. People wonder why their agents feel sluggish and confused, and a chunk of the answer is that they have loaded a phone book of tool descriptions into the prompt before the conversation even starts.
A good abstraction should be cheap when you are not using it. MCP is expensive when you are not using it. That is backwards.
Half-Baked When You Actually Try to Use It
Even when the security concerns and the context bloat are not biting you, MCP just feels unfinished when you sit down and use it. Tools that do not behave the way their descriptions claim. Parameters the model has to guess at. Flaky transports. Authentication flows that feel duct-taped on. Error messages the agent cannot meaningfully recover from.
Every individual rough edge is forgivable. The sum total tells you the protocol shipped before it was ready. Which, fine, that happens. The problem is that it shipped, the ecosystem latched onto it, and now we are all going to be dragging it around for years.
CLIs Are a Stop-Gap
The industry, sensing MCP is not it, has started drifting toward CLIs and bash tools as the lingua franca for agents. Give the model a shell, give it access to common tools, let it figure things out. This works surprisingly well. Better than MCP for most things I actually want to do.
But CLIs are also a stop-gap. They were designed for humans sitting at a terminal. The conventions, the flag parsing, the help text, the exit codes, all of it was shaped by decades of human use. Agents can use them, but they are using them the way a tourist uses a phrasebook. Functional, not native.
We are reaching for CLIs because they are the closest thing to a stable, well-documented, broadly available interface that already exists. That is a good reason to use them today. It is not a reason to believe they are the endpoint.
We Need Something Agent-Native
What agents actually need is an interface designed for them from the start. Not a protocol bolted onto JSON-RPC. Not a wrapper around tools meant for humans. Something purpose-built. Something where the constraints, the affordances, the error model, the discovery story, all of it was shaped by what an agent actually does.
The reason we do not have it yet is not that the AI is not smart enough. The AI is more than capable. The reason is that we, the humans, have not agreed on the spec of what we actually need. What does discovery look like? What does authorization look like? How do you describe a tool such that another tool can compose with it without burning a thousand tokens? What does state look like across a long-running task? Nobody has nailed this down.
This is an engineering problem, not an AI problem. Once the spec exists, the AI will build its own interface to it very quickly. Everyone will rush to that surface and the current generation of MCP servers will look like the CGI scripts of 1998. We just have to figure out what it actually needs to do first.
Stop installing random MCP servers. Stop pretending the abstraction is fine. Build the spec.