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.
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.