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

341–350 of 415 posts

Re: I still prefer MCP over skills

#341

Post by throwanem »

prohobo wrote: post #333
throwanem wrote: post #314

Earlier quoted context omitted.

Sure thing! That probably won't take more than a couple years at 10-20 hours a week of tutelage, and although my usual rate for consulting of any stripe is $150 an hour, for you I'm willing to knock that all the way down to just $150 an hour.

Just give us a taste of what we'd be paying for? I'm sure you're an expert but before I commit to 2+ years of consultation I'd like to see your approach.

I've already pointed this out as the silly, purposeless argument it's become. (Or more become.) Even I at this point can't figure out who is advocating what or why, other than for the obvious ego reasons. You're bikeshedding at each other and wasting all the time and effort it requires, because no one else is enjoying it any more than you two are: if anything you have left your audience more confused than we began, but I see I repeat myself.

Show me you can stop doing that, and I'll happily mediate a technical version of this conversation that proceeds respectfully from the two of you each making a clear and concise statement of your design thesis, and what you see as its primary pros and cons.

For that I'll take a flat $150 for up to 4 hours. I usually bill by the 15-minute increment, but obviously we would dispense with that here, and ordinarily I would not, of course, offer such a remarkable discount. But it doesn't really take $150 worth of effort to remind someone that he should take better care to distinguish his engineering judgment and his outraged insecurity.

Re: I still prefer MCP over skills

#343

Post by coldtea »

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…

>"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 check them.

Knowledge about any MCP is not something special inherent in the LLM, it's just an agent side thing. When it comes to the LLM, it's just some text injected to its prompting, just like a CLI would be.

Re: I still prefer MCP over skills

#345

Post by neosat »

The juxtaposition of MCP vs Skills in the article is very strange. These are not competing ways to achieve something. Rather skills is often a way to enable an optimization on top of MCPs.

A simplified but clarifying way to think about it is that MCP exposes all the things that can be done, and Skills encode a workflow/expertise/perspective on how something should be done given all the capabilities.

So I'm not sure why the article portrays one to be conflicting with the other (e.g. "the narrative that “MCP is dead” and “Skills are the new standard” has been hammered into my brain. Everywhere I look, someone is celebrating the death of the Model Context Protocol in favor of dropping a SKILL.md into their repository.").

You can just not choose to use a skill if it's not useful. But if it's useful a skill can add to what an MCP alone can do.

Re: I still prefer MCP over skills

#346

Post by Aperocky »

BeetleB wrote: post #338
Aperocky wrote: post #50

Earlier quoted context omitted.

MCP is just CLI wrapped in boxes. CLI is the same API in more concise format. At minimum, the same amount of context overhead exist for MCP, but most of the time more because the boxes have size. CLI can be secure, AWS CLI is doing just fine. You can also play simple tricks to hide secret in a daemon or run them remotely, and all of them are still smaller than a MCP.

I've always wondered: Doesn't the fact that the MCP input/output is more structured lead to higher reliability? With MCP you declare the types for input (string, int, list, etc) and output. As part of our product, we have an MCP server. Since many of our MCP tools are expensive, for our tests we simply give the LLM all the tool descriptions (but in text form, not structured) and ask it which tool it would call for a…

This maybe one of the area that MCP are ok-ish, however at huge cost to context.

Re: I still prefer MCP over skills

#347

Post by mvkg »

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…

If the tool fails for some reason, couldn't an overly eager agent attempt to fix what's blocking it by digging into the tool (e.g. attaching a debugger or reading memory)? I think the distinction here is that skill+tool will have a weaker security posture since it will inherently run in the same namespaces as the agent where MCP could impose additional security boundaries.

Re: I still prefer MCP over skills

#349

Post by smusamashah »

BatteryMountain wrote: post #215
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…

This is exactly what I do too. Works very well. I have a whole bunch of scripts and cli tools that claude can use, most of them was built by claude too. I very rarely need to use my IDE because of this, as I've replicated some of Jetbrains refactorings so claude doens't have to burn tokens to do the same work. It also turns a 5 minute claude session into a 10 second one, as the scripts/tools are purpose made. Its rea…

> I've replicated some of Jetbrains refactorings

How? Jetbrains in a Java code baes is amazing and very thorough on refactors. I can reliably rename, change signature, move things around etc.

Re: I still prefer MCP over skills

#350

Post by BeetleB »

Aperocky wrote: post #346
BeetleB wrote: post #338

Earlier quoted context omitted.

I've always wondered: Doesn't the fact that the MCP input/output is more structured lead to higher reliability? With MCP you declare the types for input (string, int, list, etc) and output. As part of our product, we have an MCP server. Since many of our MCP tools are expensive, for our tests we simply give the LLM all the tool descriptions (but in text form, not structured) and ask it which tool it would call for a…

This maybe one of the area that MCP are ok-ish, however at huge cost to context.

As I and others have pointed out: The context problem with MCP is mostly solved.

See https://news.ycombinator.com/item?id=47719249 for an example I gave.

Post reply on HN