Post

Den
@den.dev

CLIs are definitely not more secure. That’s actually why we recommend developers build more remote MCP servers than local ones (unless necessary, like Ghidra MCP) because the whole idea of “install something locally with full machine access” to get some potential integration is kind of bad.

This post is unavailable.

4 reposts20 likes

Victor Santelé
@vsantele.dev

In tools like claude code. Using cli might be easier to use. But we can't easily block the agent to do write actions for instance. Because the tool call is just a string. One of my dream: mcp uses Auth token from the cli. We keep control but don't need to provide token or Auth twice!

Den
@den.dev

There’s a bit of an auth boundary mismatch that needs to be rationalized (i.e., I gave access to the CLI but not the MCP server), but it’s a valid scenario.

Pavel Anni
@pavelanni.dev

I think this whole CLI vs. MCP discussion completely misses a much larger audience: normal users who don't want to hear about CLI. I'm sure this audience plays a more important role in the outcome.

Reilly Wood
@reillywood.com

I think some of this comes down to "coding agent with an expert user driving it semi-interactively" vs "fully automated agent". Lotta people praise CLIs for the former without thinking about what it takes to sandbox one and avoid auth exfiltration

Den
@den.dev

Oh totally. Even then - let’s teach everyone in the imaginable universe about proper sandboxing vs. just give me a URI 🤷

Reilly Wood
@reillywood.com

Agreed. After that, feels like the remaining objection to MCP is mostly around token usage; fancy agents like Claude Code and Cursor handle this well with tool search and writing big tool results to disk, but, well, "the future is not evenly distributed"

Den
@den.dev

I would actually posit that client-based tool subfiltering is the future - you heard it here first.