Hacker News Reader

Comment by mikeocool | Hacker News Reader

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.

View on HN

Hah, I made that same point last December: 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.

Yeah, from a design perspective MCP upsets me, because it’s a poorly designed standard and creating a good one could have been much easier.

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.

I think the new 07-28 spec is quite decent

"without first having to solve the problem of effectively sandboxing Bash"

Hopefully this is easier as time goes on. Of course- also policy on the egress

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

Which solution do you recommend?

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

MCP is one of those things that is "too good enough".

Understood but it seems like effectively sandboxing cash is a very very important problem for the industry to solve!

Would be a much more robust and general solution of the problem of controlling and auditing agentic access to sensitive information.

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.

Honest question: which startups are trying to write a sandboxed-by-default easy to configure bash meant to be safely used by agents?

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.

What do you mean by sandboxing bash? Isn’t this about just having a tool like curl or Postman?

Implanting an MCP client in your agent code isn’t all that different from calling requests or whatever

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.

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

Pretty much, MCP is still a bad idea.

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.

How do you handle credentials safely?

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.

What about just handing the agent a token with limited time to live and constrained access permissions?

You mean oauth? API keys?

API gateway is a thing…

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

Or just write good API docs that humans can use too.

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.

Reply on news.ycombinator.com