This article entirely misses the value that MCP brings today.
Sure, there's almost no reason to use MCPs if you are running a full-blown terminal agent (Claude Code, Codex, Meta Muse, OpenClaw etc) with unfettered internet access - just let it call APIs directly.
If you want to operate something that's less YOLO than that, you'll find yourself wanting:
1. Control over exactly which external services it can access
2. A way to handle authentication that doesn't allow the agent to directly access API keys
3. A sensible UI to allow users to connect and authenticate further services
4. Strong audit logging for what's going on
MCP makes all of that so much easier to provide.
Thinking MCP is obsolete because full coding agents don't need it misses out on all of the other things we might want to build.
All of these things are perfectly possible with a plain REST API with an Open API spec and using some standard auth options, and an AI client that implements a reasonable “make api request tool” (just like the AI clients implement MCP today).
I think the real value of MCP is that it allowed companies to say “we’re doing AI!” When they built an MCP server. Just saying “use our api” was a lot less exciting.
Giving it a different name probably also helped cut through politics at companies where non-technical people didn’t want to open up user data with an API, but they did want to do AI.
Hah, I made that same point last December: <a href="https://simonwillison.net/2025/Dec/31/the-year-in-llms/#the-only-year-of-mcp" rel="nofollow">https://simonwillison.net/2025/Dec/31/the-year-in-llms/#the-...
> For a while it also felt like MCP was a convenient answer for companies that were under pressure to have “an AI strategy” but didn’t really know how to do that.
I've since come back to MCPs, because I want to build my own agents without first having to solve the problem of effectively sandboxing Bash.
> without first having to solve the problem of effectively sandboxing Bash
"Sandboxing bash" is a problem that has been solved a zillion years ago already. Take your pick of any of the dozens of battle-proven solutions.
Bonus points if it's available on both macOS and Linux and doesn't come from a random unmaintained GitHub repository with a note in the README that says "don't run this in production".
"Battle-proven" until an LLM decides it really needs to escape the sandbox you put it in and eventually succeeds.
For personal work, I run Codex in a VM that contains only what's necessary to do software development. Could it escape the VM? Sure, if there's a zero-day in VMWare Workstation.
Yeah, I'm using a pile driver when I really probably just need a hammer, but I've seen too many horror stories, and I don't trust guard rails. Even if there was an option to limit Bash calls to read-only operations, I would be 0% surprised to eventually run into "You're absolutely right! `rm -rf / --no-preserve-root` was a write operation! That's totally on me."
It's such an important problem that it is sucking all available VC money into an exponentially-growing number of startups promising to make sandboxed agents safe and usable. In other news, MCP exists.
It's not "bash", it's containers/VMs/whatever that are isolated from the host and run the agent, which can access a shell to do work.
I mean the ability to have an agent run commands in a Bash shell without allowing them access to any file or environment variable visible to the user on that computer, and without allowing them uncontrolled internet access.
Program specific permissions (separate from the user operating them) are part of the Linux permissioning system already right? That doesn’t seem like an issue to me.
I guess the main problem would be finding an API client that can easily plug into your harness, with a nice UI for turning specific APIs on and off.
it's mostly true but the mcp also installs the knowledge of that REST API in a standard way so that a user can ask "what's projected revenue this month?" and it'll know how to hit your company brain and answer
most users i'm dealing with are not doc-reading developers. even getting them to tell claude to use tool X is pretty hit or miss whereas claude already knowing what tool to use is 100% hit with correct mcp tool descriptions.
Just leak them to the inference providers, obviously /s
If you have self hosted models and/or self hosted APIs, maybe you don’t need MCP to provide a gateway to a secure resource.
If neither of those things are true, you need an authenticating gateway/proxy or a target API that supports single use credentials (and get the model to generate a call to use them).
We can argue whether MCP is a good authenticating middle layer, but not whether one is required.
> For a while it also felt like MCP was a convenient answer for companies that were under pressure to have “an AI strategy” but didn’t really know how to do that.
MCP was a convenient answer for companies that had spent the last few years shutting down APIs because allowing API access bad.
simonw · · focus · HN ↗
Sure, there's almost no reason to use MCPs if you are running a full-blown terminal agent (Claude Code, Codex, Meta Muse, OpenClaw etc) with unfettered internet access - just let it call APIs directly.
If you want to operate something that's less YOLO than that, you'll find yourself wanting:
1. Control over exactly which external services it can access
2. A way to handle authentication that doesn't allow the agent to directly access API keys
3. A sensible UI to allow users to connect and authenticate further services
4. Strong audit logging for what's going on
MCP makes all of that so much easier to provide.
Thinking MCP is obsolete because full coding agents don't need it misses out on all of the other things we might want to build.
mikeocool · · focus · HN ↗
I think the real value of MCP is that it allowed companies to say “we’re doing AI!” When they built an MCP server. Just saying “use our api” was a lot less exciting.
Giving it a different name probably also helped cut through politics at companies where non-technical people didn’t want to open up user data with an API, but they did want to do AI.
simonw · · focus · HN ↗
> For a while it also felt like MCP was a convenient answer for companies that were under pressure to have “an AI strategy” but didn’t really know how to do that.
I've since come back to MCPs, because I want to build my own agents without first having to solve the problem of effectively sandboxing Bash.
mikeocool · · focus · HN ↗
But you’re right, since clients don’t have a nicely sandboxed “make api request” tool, it’s basically the way to go for a lot of use cases.
rsalus · · focus · HN ↗
agentdev001 · · focus · HN ↗
Hopefully this is easier as time goes on. Of course- also policy on the egress
otabdeveloper4 · · focus · HN ↗
"Sandboxing bash" is a problem that has been solved a zillion years ago already. Take your pick of any of the dozens of battle-proven solutions.
simonw · · focus · HN ↗
Bonus points if it's available on both macOS and Linux and doesn't come from a random unmaintained GitHub repository with a note in the README that says "don't run this in production".
Sohcahtoa82 · · focus · HN ↗
For personal work, I run Codex in a VM that contains only what's necessary to do software development. Could it escape the VM? Sure, if there's a zero-day in VMWare Workstation.
Yeah, I'm using a pile driver when I really probably just need a hammer, but I've seen too many horror stories, and I don't trust guard rails. Even if there was an option to limit Bash calls to read-only operations, I would be 0% surprised to eventually run into "You're absolutely right! `rm -rf / --no-preserve-root` was a write operation! That's totally on me."
indymike · · focus · HN ↗
jimbokun · · focus · HN ↗
Would be a much more robust and general solution of the problem of controlling and auditing agentic access to sensitive information.
tadfisher · · focus · HN ↗
jimbokun · · focus · HN ↗
tadfisher · · focus · HN ↗
JambalayaJimbo · · focus · HN ↗
Implanting an MCP client in your agent code isn’t all that different from calling requests or whatever
simonw · · focus · HN ↗
JambalayaJimbo · · focus · HN ↗
I guess the main problem would be finding an API client that can easily plug into your harness, with a nice UI for turning specific APIs on and off.
rgbrgb · · focus · HN ↗
jimbokun · · focus · HN ↗
rgbrgb · · focus · HN ↗
what-the-grump · · focus · HN ↗
LLMs perform significantly better and faster when you strap them to plain old apis/and an open api spec with a search tool.
My current MCP design is… grab a fastapi spec shove it into fastmcp, shallow wrapper, search tool for the full schema.
Oh boy so exciting I just wrapped an api spec for no reason and have to host infra for the translation layer. If only we invented api gateways.
But I am Mr. AI now.
isbvhodnvemrwvn · · focus · HN ↗
SgtBastard · · focus · HN ↗
If you have self hosted models and/or self hosted APIs, maybe you don’t need MCP to provide a gateway to a secure resource.
If neither of those things are true, you need an authenticating gateway/proxy or a target API that supports single use credentials (and get the model to generate a call to use them).
We can argue whether MCP is a good authenticating middle layer, but not whether one is required.
jimbokun · · focus · HN ↗
what-the-grump · · focus · HN ↗
API gateway is a thing…
blitzar · · focus · HN ↗
MCP was a convenient answer for companies that had spent the last few years shutting down APIs because allowing API access bad.