4 ms·
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 agen
by drdexebtjl 2mo ago
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?
- firasd 2mo agoI 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)
- drdexebtjl 2mo agoBecause 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.
- firasd 2mo agoThe 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 ..
- drdexebtjl 2mo agoIn 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 :)
- Eldodi 2mo ago- 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
- sippeangelo 2mo agoNone 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.
- brabel 2mo agoShow me then how to convert my MCP, including auth, behind a CLI like interface. I don’t think that’s even possible.
- joombaga 2mo agoCan you link it?
- vidarh 2mo ago"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.
- moduspol 2mo agoI'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