MCP has a great advantage over agent using cli: MCP is much easier to secure so that it's hardwired that the agent can only call the pre-configured MCP server. We run our agents so that they don't have access to public internet, so they could not run any cli commands. It's all either built-in agent tools, or 3rd party mcp servers. The agents never have access to any credentials, which makes them much more safe to use than a claude code running in yolo mode with fetching random cli binaries from the web.
MCP allows you to easily separate API requests from their access tokens, so that the LLM only has access to the requests part. Giving an LLM CLI access removes all boundaries, anything goes.
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.
The point is that you still need to expose a shell or a wrapper around exec to launch those commands. That is t appropriate when I want to lock the model down to working entirely from a sandboxed environment and expose some basic tools which are not “entire posix user space”.
MCP servers are not dead, they’re just overused in contexts they don’t really make sense in.
Another examole which is trivial with MCP but hard with cli binaries: blocking certain commands, such as write operations from the agent. With MCP your client can easily have a blocklist for commands, but with cli you would need to code custom logic for each cli separately.
Access control is the operating system's job, and modern OSes already provide plenty of great tools for doing that.
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.
With MCP your client can easily have a blocklist for commands, but with cli you would need to code custom logic for each cli separately.
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.
It is crazy how the preferred way or securing AI are vibe coded MCP servers which at the same time do access control, credentials handling and HTTP server/client boilerplate. Want to use a new API: just vibe code a new MCP you won't fully review. It is hardly better than yoloing. The security critical parts needs to leave MCP and be integrated with, or be in front of, the API in a way humans will understand and review.
The parent suggests MCP as a way to secure credentials and enforce guardrails, and sibling comments iterate on this. I might be reading a bit between the lines with my comment, but did not intend to derail the discussion.
But the parent who suggested MCP for security didn't say anything about vibe coding it. The person who talked about vibe coding an MCP was the one saying MCP isn't very useful.
To be devil’s advocate: if you are just running commands with bash or power shell or the like there is no protection. You might have some rules that ban
It is. The issue is all the weird constraints that usually come up with it. Like I want to use my favorite code editor, I want easy copy and paste, or I can’t bother setting up a separate user account on my computer.
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).
