Comment by tow21
7 days ago
This argument always sounds like two crowds shouting past each other.
Are you a solo developer, are you fully in control of your environment, are you focused on productivity and extremely tight feedback loops, do you have a high tolerance for risk: you should probably use CLIs. MCPs will just irritate you.
Are you trying to work together with multiple people at organizational scale and alignment is a problem; are you working in a range of environments which need controls and management, do you have a more defensive risk tolerance ... then by the time you wrap CLIs into a form that are suitable you will have reinvented a version of the MCP protocol. You might as well just use MCP in the first place.
Aside - yes, MCP in its current iteration is fairly greedy in its context usage, but that's very obviously going to be fixed with various progressive-disclosure approaches as the spec develops.
Context usage is a client problem - progressive disclosure can be implemented without any spec changes (Claude/code has this built in for example). That being said the examples for creating a client could be massively expanded to show how to do this well
In an organisation we can’t limit MCP access. It’s all or nothing. Everything the user can touch, the MCP can touch.
We can trust humans not to do stupid things. They might accidentally delete maybe two items by fat-fingering the UI.
An Agent can delete a thousand items in a second while doing 30 other things.
With bespoke CLI tools we can configure them so that they cannot access anything except specific resources, limiting the possible blast radius considerably.
> In an organisation we can’t limit MCP access.
Why not? I'd imagine that you could grant specific permissions upon MCP auth. Is the issue that the services you're using don't support those controls, or is it something else?
I haven’t seen a single major MCP provider that would let us limit access properly
Miro, Linear, Notion etc… They just casually let the MCP do anything the user can and access everything.
For example: Legal is never letting us connect to Notion MCP as is because it has stuff that must NEVER reach any LLM even if they pinky swear not to train with our stuff.
-> thus, hard deterministic limits are non-negotiable.
6 replies →
(everything I write about MCP means "remote MCP" by the way. Local MCP is completely pointless)
MCP provides you a clear abstracted structure around which you can impose arbitrary policy. "identity X is allowed access to MCP tool Y with reference to resource pool Z". It doesn't matter if the upstream MCP service provides that granularity or not, it's architecturally straightforward to do that mapping and control all your MCP transactions with policies you can reason about meaningfully.
CLI provides ... none of that. Yes, of course you can start building control frameworks around that and build whatever bespoke structures you want. But by the time you have done that you have re-invented exactly the same data and control structures that MCP gives you.
"Identity X can access tool Y with reference to resource pool Z". That literally is what MCP is structured to do - it's an API abstraction layer.
CLI provides all of that.
I have a configuration file that defines the exact resources the CLI can access. It programmatically checks and blocks access to any resource that's not whitelisted. There's no way for the Agent to get around that without some major fuckery.
The problem with your MCP example is that Identity X has access to most of the data, because humans need that. But when an agent uses MCP with Identity X credentials we need to be able to deterministically block it from accessing anything but very specific resources.
maybe make an mcp that has whatever limitations you need baked in?
But we pay ungodly amounts of money to services, why can't they bake in limitations? I'm a 100% sure we're not the only ones wondering why MCPs have to be all or nothing.
> We can trust humans not to do stupid things. hold my beer
I can definitely delete a thousand items with a typo in my bash for loop/pipe. You should always defend against stupid or evil users or agents. If your documents are important, set up workflows and access to prevent destructive actions in the first place. Not every employee needs full root access to the billing system; they need readonly access to their records at most.
These people aren’t doing bash loops, they’re regular non-technical people who just want to use an AI Agent to access services and aggregate data.
If people accidentally delete stuff, they tend to notice it and we can roll back. If an agent does a big whoops, it’s usually BIG one and nobody notices because it’s just humming away processing stuff with little output.
An accountant might have access to 5 different clients accounts, they need to do their work. They can, with their brain, figure out which one they’re processing and keep them separate.
An AI with the same access via MCP might just decide to “quickly fix” the same issue in all 5 accounts to be helpful. Actually breaking 7 different laws in the process.
See the issue here?
(Yes the AI is approved for this use; that’s not the problem here)
2 replies →
[dead]
agree I don't get this discussion anyways Those are two different things, and actually they work well together..
[dead]