[tow21]

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.

[joshwarwick15]

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

[theshrike79]

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.

[jjice]

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

[theshrike79]

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.

[pjm331]

it's straightforward to spin up a custom MCP wrapper around any API with whatever access controls you want

the only time i reach for official MCP is when they offer features that are not available via API - and this annoys me to no end (looking at you Figma, Hex)

[BeetleB]

Indeed, ever since MCPs came out, I would always either wrap or simply write my own.

I needed to access Github CI logs. I needed to write Jira stories. I didn't even bother glancing at any of the several existing MCP servers for either one of them - official or otherwise. It was trivial to vibe code an MCP server with precisely the features I need, with the appropriate controls.

Using and auditing an existing 3rd party MCP server would have been more work.

[theshrike79]

That’s what we’re doing, but it’s annoying. Why can’t they just let us limit access for the official MCP easily?

[jjice]

Agreed. Sounds like a failure of the services, but not MCP. Can't believe in 2026 we don't have better permissions on systems like this.

[tow21]

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

[theshrike79]

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.

[dec0dedab0de]

maybe make an mcp that has whatever limitations you need baked in?

[theshrike79]

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.

[morgaesis]

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

[theshrike79]

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)

[BeetleB]

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

Over the last few months, this pattern of discussion has become pervasive on HN.

Point.

Counterpoint.

(Not finding a flaw with the counterpoint) "Yeah, but most people aren't smart enough to do it right."

I see it in every OpenClaw thread. I see it here now.

I also saw it when agents became a thing ("Agents are bad because of the damage they can do!") - yet most of us have gotten over it and happily use them.

If your organization is letting "regular non-technical" people download/use 3rd party MCPs without understanding the consequences, the problem isn't with MCP. As others have pointed out in this thread, you can totally have as secure an MCP server/tool as a sandboxed CLI.

Having said that, I simply don't understand yours (and most of others') examples on how CLI is really any different. If the CLI tool is not properly sandboxed, it's as damaging as an unsecured MCP. Most regular non-technical people don't know how to sandbox. Even where I work, we're told to run certain agentic tools in a sandboxed environment. Yet they haven't set it up to prevent us from running the tools without the sandbox. If my coworker massively screws up, does it make sense for me to say "No, CLI tools are bad!"?

[theshrike79]

My basic point is: why don't major multimillion dollar companies provide us with a way to limit MCP access? "With this ID, this specific MCP connection can only access database X in read-only mode" or "With this ID, this MCP connection can create new pages under this page, but cannot delete anything or modify pages it didn't create". Very very basic stuff.

I _can_ make a custom CLI, a custom MCP wrapper and whatever else to limit the things agents can access. But why do I need to? Am I the only one in the world who doesn't want to let ChatGPT run wild on our internal Notion without any hard limitations? We pay them ungodly amounts every month for the service and basic safeties aren't included unless we build them in.

[exossho]

agree I don't get this discussion anyways Those are two different things, and actually they work well together..