Hacker News Reader

Comment by drdexebtjl | Hacker News Reader

I don’t think the “just use a CLI” crowd really are assuming you’re a developer in a coding harness.

All of those use cases you mentioned benefit from the agent having access to a temporary virtual machine with a set of standard CLI tools and the ability to write and execute arbitrary code.

Most already do. ChatGPT has been running Python in the cloud to answer questions before we even had functional coding harnesses.

So why not augment their repertoire of CLI tools instead of a completely new protocol?

View on HN

- CLI tools don't have standardized auth, nor do they have granular tool permissions. MCP does

- CLI tools need to access your secrets in your .env. With MCP the model never sees the secrets and refresh tokens.

- CLI tools don't have auditing and telemetry. MCP provides all this for free.

- CLI tools imply full bash access, a nightmare in terms of security and very costly if you have to spin up a machine for every request for billions of users.

- etc

None of this is true. The point of "just CLI" is that LLMs are infinitely more trained on working CLI tools. There doesn't need to be real CLI tools behind the harness, as long as the interface is CLI-like.

Show me then how to convert my MCP, including auth, behind a CLI like interface. I don’t think that’s even possible.

Can you link it?

"claude -p"

All of the main agent CLI's provides a demonstration that it is possible because they're all callable as a CLI. Several of them, like Codex, Kimi CLI, Pi, OpenCode are open source and so you could obviously strip out the MCP host and client from them and turn them into a CLI. Doing so in a way that keeps auth outside the agents sandbox is trickier and you might end up with a proxy which partly defeats the point but at least still keeps the composability of a CLI.

I'm not especially a fan of MCP but it also offers:

- Standardized input and output schemas for each tool

- Standardized annotations that indicate how potentially dangerous each tool can be (e.g. read-only, idempotent, publishes data visible to third parties)

- Extensions for UI widgets

Can you elaborate on the auditing and telemetry. I'm wondering what you mean by that and how it comes for free any differently from an cli

> CLI tools don’t have standardized auth

EPERM, POSIX ACLs and execute bits.

> CLI tools need to access your secrets in your .env

They can access whichever secret store you want. There are dozens of projects offering valid solutions nowadays for the local tool call space, and they’re equally useful in this scenario.

> CLI tools don’t have auditing and telemetry

They’ve had it for much longer than MCP.

> A nightmare in terms of security

We know how to secure shells. Git over SSH is a hardened, public shell that works all the way up to GitHub scale. You just offer a limited toolset. No escape, unless there’s a vulnerability, which is just as likely with MCP.

> Very costly

It’s a rounding error in comparison to token costs.

I guess if the agent is strongly trained to reach for the container then maybe

But let’s take my MCP clock for example if you ask ChatGPT what’s the time in Tokyo it’s not even gonna think of booting up the code interpreter. It’s gonna just do web search and give you the wrong time (I just tried it and there may be an OpenAI built in widget it pops up now—but again that’s a specific tool call with an iframe output not arbitrary code)

Because there’s probably a tool call for web search, and a tool call for arbitrary code. There’s no discovery for the CLI tools it has available unless it has already chosen to run arbitrary code.

The point is that even web search should be a CLI tool, and all ChatGPT would know to do other than talk to you is how interact with a shell.

Then if you ask it what’s the time in Tokyo, it would likely reach for the POSIX date command, instead of web search, because both would be equally visible.

The amusing thing here though is that if we do high frequency container usage like you’re suggesting eventually we’re gonna reimplement MCP right. Cause then it’s like npx thiscommand —help (aka MCP tools/list) and then OAuth and all that ..

In the same vein, if we do evolve MCP to support composable tool calls and more tools, eventually we’ll reimplement Bash.

The difference is that we already have Bash :)

Reply on news.ycombinator.com