Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I still prefer MCP over skills

david.coffee

Post reply on HN
Print view View original

361–370 of 415 posts

Re: I still prefer MCP over skills

#361

Post by jonfw »

stingraycharles wrote: post #74
plandis wrote: post #10

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.

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

Re: I still prefer MCP over skills

#365

Post by jFriedensreich »

mikestorrent wrote: post #335
jFriedensreich wrote: post #326

Earlier quoted context omitted.

If your llm sees even a difference between local skill and remote MCP thats a leak in your abstraction and shortcoming of the agent harness and should not influence the decision how we need to build these system for the devs and end users. They way this comment thinks about building for agents would lead to a hellscape.

Do you know who you're responding to? > a difference between local skill and remote MCP A local skill is a text file with a bunch of explanations of what to do and how, and what pitfalls to avoid. An MCP is a connection to an API that can perform actions on anything. This is a pretty massive difference in terms of concept and I don't think it can be abstracted away. A skill may require an MCP be available to it, for…

Don't think its relevant who they are if they give advice that is based on outdated understanding of how agent harnesses are build and how to use MCP in an agent harness in the first place. You can serve agent skills via mcp or via text files accessed via local tools, if your harness makes this look different to the LLM in the end it is just a bad harness. The LLM should just see "ways to discover skills" and then "use the skills". If skills come from a folder or from an MCP is transparent implementation detail. This is more than just theoretical, if abstractions like the way skills are served leak into the context, this will measurably degrade agent performance, depending on model more or les severe!

Re: I still prefer MCP over skills

#368

Post by turlockmike »

nostrebored wrote: post #58
turlockmike wrote: post #51

Earlier quoted context omitted.

MCPs are basically just JSON-rpc. The benefit is that if you have applications that require an API key, you can build a server to control access (especially for enterprise). It's the same as REST apis, except by following a specific convention we can take advantage of generic tools (like the one I built) and means you don't need to rely on poor documentations to connect or train a model to use your very specific CLI.

But if you have customer facing APIs then all of these problems were already solved in an enterprise context. You can force an oauth flow from skills if you want. I don’t think that CLIs are the path forward either, but you certainly don’t have to teach a model how to use them. We’ve made internal CLIs that adhere to no best practices and expose limited docs. Models since 4o have used them with no issue. The amount o…

LLMs don't care about mcp vs CLI. CLIs enable LLMs to fetch/mutate data and build scripts with the same program. I think of it like a Linux dev in a box. Sometimes you want to just call a tool, sometimes you want to write a small program that calls that tool instead.

Re: I still prefer MCP over skills

#369

Post by TheTaytay »

Aperocky wrote: post #42
TheTaytay wrote: post #36

Earlier quoted context omitted.

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.

Re: I still prefer MCP over skills

#370

Post by TheTaytay »

usrbinbash wrote: post #316
lukewarm707 wrote: post #151

Earlier quoted context omitted.

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.

> what stops the agent from echoing the secure storage? The fact that it doesn't see it and cannot access it. Here is how this works, highly simplified: def tool_for_privileged_stuff(context:comesfromagent): creds = _access_secret_storage(framework.config.storagelocation) response = do_privileged_stuff(context.whatagentneeds, creds) return response # the agent will get this, which is a string This, in a much more com…

I think this is a good setup to prevent the secret from leaking into the agent context. I'm more concerned about the secret leaking into the exfiltration script that my agent accidentally runs. The one that says: "Quick! Dump all environment variables. Find all secrets in dotfiles! Look in all typical secrets file locations..."

Your agent process has access to those secrets, and its subprocesses have access to those secrets. The agent doesn't have to be convinced to read those files. Whatever malicious script it manages to be convinced to run could easily access them, right?

Post reply on HN