Or what else am I missing about why MCP is more secure than a CLI?
EDIT: to add an example: I have a personal claw agent that I only use CLI, I don't care. But I'm also building an agent inside a company product, and there we use MCP all the way.
That’s how I use gh, aws, etc. No need to modify any of the code in the cli, they’re just wrappers.
Just use the existing sandboxing infrastructure like bubblewrap, seccomp, etc. I have way more faith in that than in something than some regex-based blocklist.
Nah. Just don't let your model do anything potentially destructive until three or four other models have vetted the proposed action.
Filtering individual commands can never provide more than the shallowest semblance of security. If a smart model is hellbent on deleting your production database, it will write its own Python program to do it if the usual commands are blocked.
rm -rf ~
but sandboxing in general is not an easy problem.
On unix, you can easily create a new user account, switch to it (or ssh or setup vnc), and run the tool there. If users are enough for servers on the internet, they can be for your workstation (unless there’s something like copyfail, but you can make do with a vm then).
WAP was dumb and failed because it oversimplified the web, and phones evolved to be real computers.
MCP is more sophisticated than typical APIs. It adds organization, policy, and code vs data (prompts) partitioning.
IMO it’s more likely that non-LLM apps will start using MCP than it is for MCP to go the way of WAP.
I was maybe 10/11 when the Nokia 3330 came out, and being able to use the internet while not in front of a computer just felt like magic
Why would it? Do you see any agents or models use that? No, instead vibe coders at Anthropic vibe-designed a bespoke protocol that sidesteps and ignores the last 60 years of API development and integrations.
Yes, MCP is a hack that could have been carefully built on prior art, and it would have been better for it.
Yes, MCP is capable of expressing that prior art, and you can do semantic web concepts even if the wire protocol looks different.
Reminds me a lot of Microsoft’s WS-disaster of the early 2000s except the latter was thought through a little better.
To be fair a while back I did design an API for a general purpose model trainer which was absolutely atrocious for a few reasons, my own ignorance was a factor but the problem of accommodating everything from “model that can be trained in 30 seconds on a small machine” to “model that takes 30 days of training on a cluster” problematized it.
It would have made so much more sense to build a standard for documenting ordinary API endpoints and CLIs.
That's at least my experience with my current project: the traditional json, coding oriented API feels out of place, I maintain it out of habit. The real API is the MCP server, which is not designed like a traditional API would; understandability of the output for an LLM prevails instead of searchng for exhaustiveness, orthogonality etc.
The reason I'm asking those questions is that a customer of mine has a service with a JSON API, a Vue frontend and a score of customers using that JSON API. We know that the newest ones are using bots to code their clients (and they are using them wrong, by the mistakes they do.) I don't see a near future in which all those third party apps become LLMs that would benefit from a MCP server and we retire the API.
But yes I agree with your point: for a simpler app with a more traditional web UI it's likely the API used by the front-end would largely overlap with the user-oriented API. Then indeed the REST API has to be maintained for as long as humans continue to use the front-end.
It’s like saying APIs are dead because you can just use HTTP. They’re not the same thing, though of course you can hand-roll the higher layer in the lower one. It’s just more work, less standard, less valuable.
I don’t think models will ever prefer a low level API to a decorated index of API features and how to use them, same way developers will never prefer a list of HTTP endpoints and bespoke headers + query strings + POST bodies over a structured API.
It’s like asking why we needed browsers when we had BBSes; they serve a different but similar purpose and are build on different abstraction levels.
You have a client, the client uses the SDK, talks to endpoint x. Endpoint x tells it very efficient that they are now talking protobuf and rpc over quick or http15 and thats it.
Why don't we have this? Right because of people.
Its always people problem.
MCP is now here, it might stay.
Should it? I think it can be very useful to constrain what your AI can do (e.g. read files but don’t delete them). MCP is a way to do that.
For example try giving a local LLM read access to specific folders in your email account
LLMs are much more proficient with bash and --help than they are with bespoke API protocols.
Treat LLMs like you would a junior programmer - keep things as generic and obvious as you can.
I've heard this one before
(Maybe it'll be the first time that a temporary workaround stays around longer than expected then)
And you’ll also often see CISO-offices that are managed by checklists and yet more committees.
Asking for MCP access is generally easier than asking for an API for several reasons:
1. MCP supports OAuth, so your access conform with numerous CIS (et al) compliance checklists (short lived secrets, MFA, user-specific credentials, user access managed by centralised directory services and thus can have business rules applied, etc)
2. MCP is something a business can make a cooperate decision on. And then you can refer to that decision each time you need an access to new service. Whereas API access isn’t. In some cases APIs are governed by LLDs, and then you have an extra layer of “fun” having to update documentation to describe, in detail, the technical specifications too.
3. MCP defines the interaction better. If you need to request access to an API then the inevitable question from the committee is “where is this code running from?” and so on and so forth. Whereas saying “MCP access for AI to assist the project team with development” is a lot easier conversation to have.
In short: Enterprises are a very different beast to your average business.
Not everything in the real world will expose an MCP server so AI can interact with it.
Eventually, AI will need to move beyond MCP and interact with the real world the same way humans do: by observing, interpreting, reasoning, and taking action in messy, imperfect environments.
MCP tries to organize our messy word to make interaction part with the world easier in the near term, and it will help accelerate very early progress. But ultimately, MCP is a temporary bridge. Not the final destination.
I give it max 3 to 6 years and it will just die.
The menial task of updating the interfaces when the code changes is something AI should be really good at, so it's essentially little to no actual programmer time waste
> So the current situation is basically that I used Claude to write an MCP server on top of our API. And then I need to occasionally tell it update it match the public doc.
> And my reaction is: really? It is not like our API docs are not public. Claude Code created our MCP server with zero instructions beyond what is publicly available. I just told it to read the docs from the net.
Updating MCP by AI is one time effort.
Having AI re-create what MCP would do for every piece of code that uses a service is massively wasted effort in comparison
It's not question of "model limitation" but of cost effectiveness.
> And my reaction is: really? It is not like our API docs are not public. Claude Code created our MCP server with zero instructions beyond what is publicly available. I just told it to read the docs from the net.
My reaction to this is.. really? Presumably your API and API docs have a release process. Hopefully an automated one. Why isn't the "hey Claude, update the MCP server" step a part of it?
It's adding another failure point to the process for no gain.