5 ms·
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 a
by plandis 6mo 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.
- woeirua 6mo agoOk, 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.
- hansonkd 6mo agoidk, just have a standard internet request tool that skills can describe endpoints to. like you could mock `curl` even for the same CLI feel
- yawnxyz 6mo agoskills can have code bundled with them, including MCP code
- egeozcan 6mo agoWhat 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?
- daemonologist 6mo agoObvious 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.)
- nostrebored 6mo agoWhy are they not calling APIs directly with strictly defined inputs and outputs like every other internal application? The story for MCP just makes no sense, especially in an enterprise.
- ok_dad 6mo agoMCP is an API with strictly defined inputs and outputs.
- nostrebored 6mo agoThis is obviously not what it is. If I give you APIGW would you be able to implement an MCP server with full functionality without a large amount of middleware?
- notpushkin 6mo agoSorry, could you rephrase that?
- TheTaytay 6mo agoI 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.
- Aperocky 6mo agoA 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.
- linkregister 6mo agoIn other words, a wrapper around an MCP that's less verbose.
- throwup238 6mo agoMCP is a wrapper around it. The CLI-daemon RPC pattern is much older and is used all over the place in modern systems.
- otabdeveloper4 6mo ago"MCP" here is not needed.
- TheTaytay 6mo agoThat 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.
- stingraycharles 6mo agoI 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.
- notpushkin 6mo agoI 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.
- stingraycharles 6mo agoObviously 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.
- jonfw 6mo agoWith 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
- lll-o-lll 6mo agoCool 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.
- mstipetic 6mo agoAlso 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.
- friendzis 6mo ago> 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?
- lll-o-lll 6mo ago> 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?
- Marha01 6mo ago> If the cli can access the secrets, the agent can just reverse it and get the secret itself. What do you mean by this? How "reverse it"? The CLI tool can access the secure storage, but that does not mean there is any CLI interface in the tool for the LLM to call and get the secret printed into the console.
- zaphirplane 6mo agoThis 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
- Aperocky 6mo agoThe 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.
- zaphirplane 6mo agoHow ? Have you used these things when they are blocked and try to get around the block
- rimliu 6mo agowhat you want and what works may be very different things.
- blairharper 6mo ago> 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.