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

241–250 of 415 posts

Re: I still prefer MCP over skills

#241

Post by [deleted] »

bavell wrote: post #228
raincole wrote: post #193

Earlier quoted context omitted.

> So does an API and a text file (or hell, a self describing api). That sounds great. How about we standardize this idea? We can have an endpoint to tell the agents where to find this text file and API. Perhaps we should be a bit formal and call it a protocol!

> How about we standardize this idea? We can have an endpoint to tell the agents where to find this text file and API Good news! It's already standardized and agents already know where to find it! https://code.claude.com/docs/en/skills

[deleted]

Re: I still prefer MCP over skills

#242

Post by CuriouslyC »

prohobo wrote: post #235
CuriouslyC wrote: post #231

Earlier quoted context omitted.

MCP is less discoverable than a CLI. You can have detailed, progressive disclosure for a CLI via --help and subcommands. MCPs needs to be wrapped to be composed. MCPs needs to implement stateful behavior, shell + cli gives it to you for free. MCP isn't great, the main value of it is that it's got uptake, it's structured and it's "for agents." You can wrap/introspect MCP to do lots of neat things.

"MCP is less discoverable than a CLI" - that doesn't make any sense in terms of agent context. Once an MCP is connected the agent should have full understanding of the tools and their use, before even attempting to use them. In order for the agent to even know about a CLI you need to guide the agent towards it - manually, every single session, or through a "skill" injection - and it needs to run the CLI commands to c…

If you have an API with thousands of endpoints, that MCP description is going to totally rot your context and make your model dumb, and there's no mechanism for progressive disclosure of parts of the tool's abilities, like there is for CLIs where you can do something like:

tool --help

tool subcommand1 --help

tool subcommand2 --help

man tool | grep "thing I care about"

As for stateful behavior, say you have the google docs or email mcp. You want to search org-wide for docs or emails that match some filter, make it a data set, then do analysis. To do this with MCP, the model has to write the files manually after reading however many KB of input from the MCP. With a cli it's just "tool >> starting_data_set.csv"

Re: I still prefer MCP over skills

#243

Post by password4321 »

Surprised to see no mention in the article or discussion yet about using MCPs in 'code mode', where an API is generated client-side relying on MCP primarily as an interface standard. I'm still learning but I've read this reduces the amount of context required to use the MCP.

It seems like a lot of the discussion is arguing in favor of API usage without realizing that MCP basically standardizes a universal API, thus enabling code mode.

Re: I still prefer MCP over skills

#244

Post by senordevnyc »

didibus wrote: post #29
senordevnyc wrote: post #22

I love the idea of MCP, but it needs a progressive disclosure mechanism. A large MCP from a provider with hundreds or even thousands of tools can eat up a huge amount of your context window. Additionally, MCPs come in a bunch of different flavors in terms of transport and auth mechanisms, and not all harnesses support all those options well. I’ve gone the other way, and used MCP-CLI to define all my MCP servers and w…

I thought Claude Code and others do progressive disclosure for MCP now as well. The article claims so: > Smart Discovery: Modern apps (ChatGPT, Claude, etc.) have tool search built-in. They only look for and load tools when they are actually needed, saving precious context window.

The article made a number of claims I know to be false, so I wouldn’t take it as gospel.

Re: I still prefer MCP over skills

#245

Post by mbreese »

prohobo wrote: post #138
antirez wrote: post #108

Don't focus on what you prefer: it does not matter. Focus on what tool the LLM requires to do its work in the best way. MCP adds friction, imagine doing yourself the work using the average MCP server. However, skills alone are not sufficient if you want, for instance, creating the ability for LLMs to instrument a complicated system. Work in two steps: 1. Ask the LLM to build a tool, under your guide and specification…

I feel like the MCP conversation conflates too many things and everyone has strong assumptions that aren't always correct. The fundamental issue is between one-off vs. persistent access across sessions: - If you need to interact with a local app in a one-off session, then use CLI. - If you need to interact with an online service in a one-off session, then use their API. - If you need to interact with a local app in a…

I think a lot of the MCP arguments conflate MCP the protocol versus how we currently discover and use MCP tool servers. I think there’s a lot of overhead and friction right now with how MCP servers are called and discovered by agents, but there’s no reason why it has to be that way.

Honestly, an agent shouldn’t really care how it’s getting an answer, only that it’s getting an answer to the question it needs answered. If that’s a skill, API call, or MCP tool call, it shouldn’t really matter all that much to the agent. The rest is just how it’s configured for the users.

Re: I still prefer MCP over skills

#246

Post by lukewarm707 »

0x696C6961 wrote: post #225
losvedir wrote: post #214

For my use I prefer just a raw CLI. As long as it's built following conventions (e.g. using cobra for a Go app) then the agent will just natively know how to use it, by which I mean how to progressively learn what it needs by reading the `help` output. In that case you don't need a skill or anything. Just say "I want this information, use the xyz app". It will then try `xyz --help` or `xyz help` or a variant, just li…

You run the MCP server outside of the agent sandbox so it doesn't have access to the credentials.

yes and also you can firewall the container so that it can only contact the mcp/proxy.

this way it doesn't download a trojan or leak your data to someone

Re: I still prefer MCP over skills

#247

Post by prohobo »

CuriouslyC wrote: post #242
prohobo wrote: post #235

Earlier quoted context omitted.

"MCP is less discoverable than a CLI" - that doesn't make any sense in terms of agent context. Once an MCP is connected the agent should have full understanding of the tools and their use, before even attempting to use them. In order for the agent to even know about a CLI you need to guide the agent towards it - manually, every single session, or through a "skill" injection - and it needs to run the CLI commands to c…

If you have an API with thousands of endpoints, that MCP description is going to totally rot your context and make your model dumb, and there's no mechanism for progressive disclosure of parts of the tool's abilities, like there is for CLIs where you can do something like: tool --help tool subcommand1 --help tool subcommand2 --help man tool | grep "thing I care about" As for stateful behavior, say you have the google…

This is a design problem, and not something necessarily solved by CLI --help commands.

You can implement progressive disclosure in MCP as well by implementing those same help commands as tools. The MCP should not be providing thousands of tools, but the minimum set of tools to help the AI use the service. If your service is small, you can probably distill the entire API into MCP tools. If you're AWS then you provide tools that then document the API progressively.

Technically, you could have an AWS MCP provide one tool that guides the AI on how to use specific AWS services through search/keywords and some kind of cursor logic.

The entire point of MCP is inherent knowledge of a tool for agentic use.

Re: I still prefer MCP over skills

#248

Post by fennecbutt »

CuriouslyC wrote: post #242
prohobo wrote: post #235

Earlier quoted context omitted.

"MCP is less discoverable than a CLI" - that doesn't make any sense in terms of agent context. Once an MCP is connected the agent should have full understanding of the tools and their use, before even attempting to use them. In order for the agent to even know about a CLI you need to guide the agent towards it - manually, every single session, or through a "skill" injection - and it needs to run the CLI commands to c…

If you have an API with thousands of endpoints, that MCP description is going to totally rot your context and make your model dumb, and there's no mechanism for progressive disclosure of parts of the tool's abilities, like there is for CLIs where you can do something like: tool --help tool subcommand1 --help tool subcommand2 --help man tool | grep "thing I care about" As for stateful behavior, say you have the google…

>man tool | grep "thing I care about"

Isn't the same true of filtering tools available thru mcp?

The mcp argument to me really seems like people arguing about tabs and spaces. It's all whitespace my friends.

Re: I still prefer MCP over skills

#249

Post by WhyNotHugo »

I like skills because they rely on the same tools which humans rely upon. A well-written skill can be read and used by a human too.

A skill is just a description for how to use an existing CLI tool. You don't need to write new code for the LLM to interact with some system. You just tell the LLM to use the same tool humans do. And if you find the CLI is lacking in some way, you can improve it and direct human usage benefits from that improvement too.

On the other hand, an MCP requires implementing a new API for a service, an API exclusive to LLMs, and keeping parallel documentation for that. Every hour of effort put into it is an hour that's taken away from improving the human-facing API and documentation.

The way skills are lazy-loaded when needed also keeps context clean when they're not used. To be fair, MCPs could be lazy-loaded the same way, that's just an implementation detail.

Re: I still prefer MCP over skills

#250

Post by _flux »

Marha01 wrote: post #224
lll-o-lll wrote: post #125

Earlier quoted context omitted.

> 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 secr…

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

Post reply on HN