Comment by plandis
7 days ago
I could not agree any less with the author. I don’t want APIs, I want agents to use the same CLI tooling I already use that is locally available. If my agents are using CLI tooling anyways there is no need to add an extra layer via MCP.
I don’t want remote MCP calls, I don’t even want remote models but that’s cost prohibitive.
If I need to call an API, a skill with existing CLI tooling is more than capable.
I often just put direct curl commands in a skill, the agent uses that, and it works perfectly for custom API integrations. Agents are perfectly capable of doing these types of things, and it means the LLM just uses a flexible set of tools to achieve almost anything.
I think this is the best of both worlds. Design a sane API (that is easy to consume for both humans and agents), then teach the agents to use it with a skill.
But I agree with the author on custom CLI tooling. I don’t want to install another opaque binary on my machine just to call some API endpoints.
Obviously opaque binaries are hardly an improvement over MCP, but providing a few curl + jq oneliners to interact with a REST API works great in my experience. Also means no external scripts, just a single markdown file.
With a good CLI, an agent may be able to do something outside of the scope of it's skill fairly easily, by running help commands or similar. With even a well written API it is not as easy.
I suppose that curl + API docs could replace a CLI but that's really token inefficient
I keep getting hung up on securely storing and using secrets with CLI vs MCP. With MCP, you can run the server before you run the agent, so the agent never even has the keys in its environment. That way. If the agent decides to install the wrong npm package that auto dumps every secret it can find, you are less likely to have it sitting around. I haven’t figured out a good way to guarantee that with CLIs.
A CLI can just be a RPC call to a daemon, exact same pattern apply. In fact my most important CLI based skill are like this.. a CLI by itself is limited in usefulness.
That was the same conclusion I reached! However, this also gave me some evidence that maybe I wanted MCP? I realized that my pattern was going to be:
Step 1) run a small daemon that exposes a known protocol over a unix socket (http, json-rpc, whatever you want), over a unix socket. When I run the daemon, IT is the only that that has the secrets. Cool! Step 2) Have the agent run CLI that knows to speak that protocol behind the scenes, and knows how to find the socket, and that exposes the capabilities via standard CLI conventions.
It seems like one of the current "standards" for unix socket setups like this is to use HTTP as the protocol. That makes sense. It's ubiquitous, easy to write servers for, easy to write clients for, etc. That's how docker works (for whatever it's worth). So you've solved your problem! Your CLI can be called directly without any risk of secret exposure. You can point your agent at the CLI, and the CLI's "--help" will tell the agent exactly how to use it.
But then I wondered if I would have been better off making my "daemon" an MCP server, because it's a self-describing http server that the agent already knows how to talk to and discover.
In this case, the biggest thing that was gained by the CLI was the ability of the coding agent to pipe results from the MCP directly to files to keep them out of its context. That's one thing that the CLI makes more obvious and easy to implement: Data manipulation without context cluttering.
In other words, a wrapper around an MCP that's less verbose.
2 replies →
Just wrap it with a script that handles the auth for you and the AI doesnt realize auth is even needed. I put my creds in ~/.config/ and write bash wrappers that read those and proxy the values into the api calls as needed.
And in a skill, I can store the secret in the skill itself, or a secure storage the skill accesses, and the agent never gets to see the secret.
Sure, if I want my agents to use naked curl on the CLI, they need to know secrets. But that's not how I build my tools.
what stops the agent from echoing the secure storage?
what i see is that you give it a pass manager, it thinks, "oh, this doesn't work. let me read the password" and of course it sends it off to openai.
4 replies →
[dead]
[dead]
This has been hashed to death and back. The mcp allows a separation between the agent and the world, at its most basic not giving the agent your token or changing a http header , forcing a parameter.
Well yes you don’t need those things all the time and who knows if the inventor of mcp had this idea in mind but here we are
The separation is being oversold as if only MCP can do it, which is laughable. Any CLI can trivially do exactly what MCP do in terms of separation.
How ? Have you used these things when they are blocked and try to get around the block
> I don’t want APIs, I want agents to use the same CLI tooling I already use that is locally available.
I do not want agents using the same elevated auth I have via my CLI tooling. One hallucination with your gh cli and the blast radius is every repo you have write (or worse, admin) access to.
MCP lets you scope tokens down (on supported platforms), or at minimum gives you something you can revoke independently.
Ok, but there are still many environments where an LLM will not have access to a CLI. In those situations, skills calling CLI tools to hook into APIs are DOA.
What are the advantages of using an environment that doesn't have access to a CLI, only having to run/maintain your own server, or pay someone else to maintain that server, so AI has access to tools? Can't you just use AI in the said server?
The advantage is that I can have it in my pocket.
2 replies →
Obvious example is a corporate chatbot (if it's using tools, probably for internal use). Non-technical users might be accessing it from a phone or locked-down corporate device, and you probably don't want to run a CLI in a sandbox somewhere for every session, so you'd like the LLM to interface with some kind of API instead.
Although, I think MCP is not really appropriate for this either. (And frankly I don't think chatbots make for good UX, but management sure likes them.)
18 replies →
[dead]
idk, just have a standard internet request tool that skills can describe endpoints to. like you could mock `curl` even for the same CLI feel
Now you’ve replicated MCP but with extra steps and it’s harder to debug.
1 reply →
skills can have code bundled with them, including MCP code
The agent still doesn’t have an execution environment. It can’t execute the code!
2 replies →
Cool cool. Except.
What about auth? Authn and authz. Agent should be you always? If not, every API supports keys? If so, no fears about context poisoned agents leaking those keys?
One thing an MCP (server) gives you is a middleware layer to control agent access. Whether you need that is use-case dependent.
Also resources - which are by far the coolest part of MCP. Prompts? Elicitation? Resource templates? If you think of MCP as only a replacement for tool calls I can see the argument but it's much more than that.
That's not a limitation of CLIs, they can work with a different auth as well.
they are just a superior tool to MCP because the agent can write code that invokes, pipes and do many other things with the tool
> If not, every API supports keys?
How would MCP help you if the API does not support keys?
But that's not the point. The agent calls CLI tools, which reads secrets from somewhere where the agent cannot even access. How can agent leak the keys it does not have access to?
You ARE running your agents in containers, right?
> How would MCP help you if the API does not support keys?
Kerberos, OAuth, Basic Auth (username/password), PKI. MCP can be a wrapper (like any middleware).
> But that's not the point. The agent calls CLI tools, which reads secrets from somewhere where the agent cannot even access. How can agent leak the keys it does not have access to?
If the cli can access the secrets, the agent can just reverse it and get the secret itself.
> You ARE running your agents in containers, right?
Do you inject your keys into the container?
5 replies →
what you want and what works may be very different things.