Live data from Hacker News

I still prefer MCP over skills

david.coffee

331–340 of 415 posts

Re: I still prefer MCP over skills

#331

Earlier quoted context omitted.

> We can trust humans not to do stupid things. hold my beer I can definitely delete a thousand items with a typo in my bash for loop/pipe. You should always defend against stupid or evil users or agents. If your documents are important, set up workflows and access to prevent destructive actions in the first place. Not every employee needs full root access to the billing system; they need readonly access to their reco…

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 it when agents became a thing ("Agents are bad because of the damage they can do!") - yet most of us have gotten over it and happily use them.

If your organization is letting "regular non-technical" people download/use 3rd party MCPs without understanding the consequences, the problem isn't with MCP. As others have pointed out in this thread, you can totally have as secure an MCP server/tool as a sandboxed CLI.

Having said that, I simply don't understand yours (and most of others') examples on how CLI is really any different. If the CLI tool is not properly sandboxed, it's as damaging as an unsecured MCP. Most regular non-technical people don't know how to sandbox. Even where I work, we're told to run certain agentic tools in a sandboxed environment. Yet they haven't set it up to prevent us from running the tools without the sandbox. If my coworker massively screws up, does it make sense for me to say "No, CLI tools are bad!"?

Re: I still prefer MCP over skills

#332

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…

Feels to me like the toolchain for using LLMs in various tasks is still in flux (i interpret all of this as "stuff in different places like .md or skills or elsewhere that is appended to the context window" (i hope that is correct)). Shouldnt this overall process be standardized/automated? That is, use some self-reflection to figure out patterns that are then dumped into the optimal place, like a .md file or a skill?

too early for standardization. resist the urge. Let a bunch of ideas flow, then watch the Darwinian process of the best setup will be found. Then standardize.

Re: I still prefer MCP over skills

#333

Earlier quoted context omitted.

You're clearly very intelligent and a real software engineer, maybe you can explain where I'm wrong?

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.

Re: I still prefer MCP over skills

#334
post #12

Despite thinking this is AI-generated, I agree but everything has a caveat. Skills are good for instilling non-repeatable, yet intuitive or institutional knowledge. MCP’s are great for custom, repeatable tasks. After 5-10 runs of watching my LLM write the same exact script, I just asked it to hardcode the solution and make it a tool. The result is runs are way faster and repeatable.

> Skills are good for instilling non-repeatable, yet intuitive or institutional knowledge. Maybe I'm misinterpreting you, but can you explain this more? I've been using skills for repeatable tasks. Why an MCP instead?

Saying "non-repeatable" was probably wrong. "Unique" might be better. Things LLMs arent naturally able to do or infer.

Re: I still prefer MCP over skills

#335

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…

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 instance, if it's written that way.

Antirez' advice is what I've been doing for a year: use AI to write proper, domain-specific tools that you and it can then use to do more impressive things.

Re: I still prefer MCP over skills

#336

Despite thinking this is AI-generated, I agree but everything has a caveat. Skills are good for instilling non-repeatable, yet intuitive or institutional knowledge. MCP’s are great for custom, repeatable tasks. After 5-10 runs of watching my LLM write the same exact script, I just asked it to hardcode the solution and make it a tool. The result is runs are way faster and repeatable.

You could hardcode the script as a file within a skill too right? Skills can contain code, not just markdown files.

Have not tried, but interesting. I guess my concern would be the Skill still takes up context space, where as MCP is just using CPU.

Re: I still prefer MCP over skills

#337
post #139

Despite thinking this is AI-generated, I agree but everything has a caveat. Skills are good for instilling non-repeatable, yet intuitive or institutional knowledge. MCP’s are great for custom, repeatable tasks. After 5-10 runs of watching my LLM write the same exact script, I just asked it to hardcode the solution and make it a tool. The result is runs are way faster and repeatable.

I would go further than this. Call the script yourself (or via some other mechanism/program) and then give the results to the LLM. The majority of processes don't need nearly as many decision making points as an agent could deal with and look somewhat like this: 1. gather raw information => script 2. turn it into structured data => script 3. produce an actionable plan => script/user/agent (depends) 4. validate the pl…

There's definitely some optimization that can occur, like an orchestrator or Ralph.

Re: I still prefer MCP over skills

#338
post #7

This isn't a zero-sum game or a choice of one over the other. They solve different layers of the developer experience: MCP provides a standardized, portable interface for external data/tools (the infrastructure), while Skills offer project-specific, high-level behavioral context (the orchestration). A robust workflow uses MCP to ensure tool reliability and Skills to define when and how to deploy those tools.

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 given query and assert on the response.

The tests are flaky. In practice, I've always seen the LLM make the right tool call with the proper formatting of args, etc. In the tests (same LLM model), it occasionally makes mistakes on the argument types and it has to try again before it gets it right.

My assumption was that the structure MCP provides was the reason there was a discrepancy.

Re: I still prefer MCP over skills

#339
post #163

Despite thinking this is AI-generated, I agree but everything has a caveat. Skills are good for instilling non-repeatable, yet intuitive or institutional knowledge. MCP’s are great for custom, repeatable tasks. After 5-10 runs of watching my LLM write the same exact script, I just asked it to hardcode the solution and make it a tool. The result is runs are way faster and repeatable.

> Despite thinking this is AI-generated, I agree but everything has a caveat. Definitely not AI generated. I wrote this during a non-internet flight. :)

Haha sorry for the callout! Saw the M-dash and auto-assumed. Nice write up and thanks for sharing :)

Re: I still prefer MCP over skills

#340
post #114

This argument always sounds like two crowds shouting past each other. Are you a solo developer, are you fully in control of your environment, are you focused on productivity and extremely tight feedback loops, do you have a high tolerance for risk: you should probably use CLIs. MCPs will just irritate you. Are you trying to work together with multiple people at organizational scale and alignment is a problem; are you…

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

maybe make an mcp that has whatever limitations you need baked in?
Post reply on HN