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

391–400 of 415 posts

Re: I still prefer MCP over skills

#391

Post by fjellsystems »

Experimenting with something adjacent — torget.ai, idea is an agent/tool marketplace so enjoyed this discussion :)

What strikes me is that MCP vs Skills vs Bespoke are all answers to ‘how does an agent use a known capability.’ How does it find one (?) is where I’m experimenting.

Discovery and payment at the agent layer still feels like the missing primitive.

Also (food for thought) the local LLM angle keeps getting underweighted in many discussions. For someone running Gemma 4 locally, there’s no tool layer at all by default. Different problem than the cloud agent angle.

Re: I still prefer MCP over skills

#392

Post by lukewarm707 »

Aperocky wrote: post #258
lukewarm707 wrote: post #157

Earlier quoted context omitted.

i use mcp for security. you can have an airgapped agent that can still call online tools. for example, web search. however it can't get infected because there is no internet access. the worst you can do is put your secrets in the web search box

You can have that with CLI. MCP is just a wrapper on top, there are no inherent differences other than complexity on top. How do you think MCP work under the hood?

fair point

i would still have to make a proxy for the cli tool because i don't want the agent having secrets in its container

Re: I still prefer MCP over skills

#394

Post by jFriedensreich »

mikestorrent wrote: post #377
jFriedensreich wrote: post #365

Earlier quoted context omitted.

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 "u…

What if the MCP needs to actually do something, like make an API call? It's nice sometimes to have those credentials out-of-band from the AI itself so it can't access them and is forced to go through the lens of tooling.

You assume an MCP has to work a certain way that is not the case. MCP can work however you want, its just a protocol. The same answer applies to tools as applies to skills. A tool has to look exactly the same to the LLM no matter if its seved from a cli or an MCP or a js function framework level tool. Credentials have to be injected in the gateway in either case.

Re: I still prefer MCP over skills

#395

Post by blairharper »

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 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.

Re: I still prefer MCP over skills

#396

Post by theshrike79 »

tow21 wrote: post #324
theshrike79 wrote: post #271

Earlier quoted context omitted.

In an organisation we can’t limit MCP access. It’s all or nothing. Everything the user can touch, the MCP can touch. We can trust humans not to do stupid things. They might accidentally delete maybe two items by fat-fingering the UI. An Agent can delete a thousand items in a second while doing 30 other things. With bespoke CLI tools we can configure them so that they cannot access anything except specific resources,…

(everything I write about MCP means "remote MCP" by the way. Local MCP is completely pointless) MCP provides you a clear abstracted structure around which you can impose arbitrary policy. "identity X is allowed access to MCP tool Y with reference to resource pool Z". It doesn't matter if the upstream MCP service provides that granularity or not, it's architecturally straightforward to do that mapping and control all…

CLI provides all of that.

I have a configuration file that defines the exact resources the CLI can access. It programmatically checks and blocks access to any resource that's not whitelisted. There's no way for the Agent to get around that without some major fuckery.

The problem with your MCP example is that Identity X has access to most of the data, because humans need that. But when an agent uses MCP with Identity X credentials we need to be able to deterministically block it from accessing anything but very specific resources.

Re: I still prefer MCP over skills

#397

Post by theshrike79 »

BeetleB wrote: post #331
theshrike79 wrote: post #291

Earlier quoted context omitted.

These people aren’t doing bash loops, they’re regular non-technical people who just want to use an AI Agent to access services and aggregate data. If people accidentally delete stuff, they tend to notice it and we can roll back. If an agent does a big whoops, it’s usually BIG one and nobody notices because it’s just humming away processing stuff with little output. An accountant might have access to 5 different clien…

> These people aren’t doing bash loops, they’re regular non-technical people who just want to use an AI Agent to access services and aggregate data. Over the last few months, this pattern of discussion has become pervasive on HN. Point. Counterpoint. (Not finding a flaw with the counterpoint) "Yeah, but most people aren't smart enough to do it right." I see it in every OpenClaw thread. I see it here now. I also saw i…

My basic point is: why don't major multimillion dollar companies provide us with a way to limit MCP access? "With this ID, this specific MCP connection can only access database X in read-only mode" or "With this ID, this MCP connection can create new pages under this page, but cannot delete anything or modify pages it didn't create". Very very basic stuff.

I _can_ make a custom CLI, a custom MCP wrapper and whatever else to limit the things agents can access. But why do I need to? Am I the only one in the world who doesn't want to let ChatGPT run wild on our internal Notion without any hard limitations? We pay them ungodly amounts every month for the service and basic safeties aren't included unless we build them in.

Re: I still prefer MCP over skills

#398

Post by e12e »

_flux wrote: post #250
Marha01 wrote: post #224

Earlier quoted context omitted.

> 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.

In principle it could use e.g. the `gdb` and step until it gets the secret. Or it can know ahead where the app stores the cerentials. We could use suid binaries (e.g. sudo) to prevent that, but currently I don't think we can. Most anyone would agree that using a separate process, for which the agent environment provides a connection, is a better solution.

Seperate process as a seperate os user, and/or namespace.

Re: I still prefer MCP over skills

#400

Post by TurtleBoxPlus »

Skills can be seen as custom-made MCPs that wrap them in a way readily useful for a niche audience. What is provided for in the package is not only the original service but also the business logic and workflow of the industry. So, sometimes they target audiences at different positions of the stream.
Post reply on HN