[rcarmo]

This feels misguided. MCP is still one of the best ways to execute deterministic sub-flows (i.e., stepwise processes) and secure tooling that an LLM would either lose itself while executing or should never access directly.

[singularity2001]

state. i'm not sure if they had that in mind but one keyword that is important here is: state. Sure CLI tools can also affect state, but in MCP service it's somewhat more natural?

[plufz]

Im still struggling with understanding when MCP works better. I move everything to cli after a while. Can you give me more concrete examples? Because I don’t doubt you, I just don’t understand.

[fastball]

Most APIs and CLIs are not setup with clear separation of permissions, and when they have those permissions are mostly designed around human access patterns and risks, not LLM ones. The primary example of course being read-only vs write access.

MCPs have provided any easy way to side-step that baggage.

e.g. in an MCP, you have tools, those tools are usually binned into "read" vs "write". Given that, I can easily configure my tooling to give an LLM (e.g. Claude Code) unlimited read access to some system (by allowing all read-only tools) without likewise giving the LLM write/destructive access.

Obviously you can design APIs/CLIs with this in mind, but up until now that has not been a primary concern so they haven't.

[x3n0ph3n3]

It's the security layer that I'm most interested with MCPs. Granting full access to the CLI feels super dangerous and maybe there are options to certain commands that I want to restrict from LLM usage.