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

271–280 of 415 posts

Re: I still prefer MCP over skills

#271

Post by theshrike79 »

tow21 wrote: 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, limiting the possible blast radius considerably.

Re: I still prefer MCP over skills

#272

Post by jsw97 »

From the article: "Sandboxing: Remote MCPs are naturally sandboxed. They expose a controlled interface rather than giving the LLM raw execution power in your local environment."

I think this is underappreciated. CLI access gives agents a ton of freedom and might be more effective in many applications. But if you require really fine granularity on permissions -- e.g., do lookups in this db and nothing else -- MCP is a natural fit.

Re: I still prefer MCP over skills

#273

Post by fny »

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 covered well in the article too. See "The Right Tool for the Job" and "Connectors vs. Manuals."

Perhaps the title is just clickbait. :)

Re: I still prefer MCP over skills

#274

Post by jjice »

theshrike79 wrote: post #271
tow21 wrote: 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,…

> In an organisation we can’t limit MCP access.

Why not? I'd imagine that you could grant specific permissions upon MCP auth. Is the issue that the services you're using don't support those controls, or is it something else?

Re: I still prefer MCP over skills

#275

Post by robot-wrangler »

siva7 wrote: post #179
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…

> MCP adds friction, imagine doing yourself the work using the average MCP server. Why on earth don't people understand that MCP and skills are complementary concepts, why? If people argue over MCP v. Skills they clearly don't understand either deeply.

> clearly don't understand either deeply

No appetite for that. The MCP vs Skills debate has gradually become just a proxy war for the camps of AI skeptics vs AI boosters. Both sides view it as another chance to decide about more magic vs less, in absolute terms, without doing the work of thinking about anything situational. Nuance, questions, reasoning from first principles, focusing on purely engineering considerations is simply not welcome. The extreme factions do tend to agree that it might be a good idea to attack the middle though! There's no changing this stuff, so when it becomes tiresome it's time to just leave the HN comment section.

Re: I still prefer MCP over skills

#276

Post by theshrike79 »

jjice wrote: post #274
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,…

> In an organisation we can’t limit MCP access. Why not? I'd imagine that you could grant specific permissions upon MCP auth. Is the issue that the services you're using don't support those controls, or is it something else?

I haven’t seen a single major MCP provider that would let us limit access properly

Miro, Linear, Notion etc… They just casually let the MCP do anything the user can and access everything.

For example: Legal is never letting us connect to Notion MCP as is because it has stuff that must NEVER reach any LLM even if they pinky swear not to train with our stuff.

-> thus, hard deterministic limits are non-negotiable.

Re: I still prefer MCP over skills

#277

Post by richardlblair »

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've found makefiles to be useful. I have a small skill that guides the LLM towards the makefile. It's been great for what you're talking about, but it's also a great way to make sure the agent is interacting with your system in a way you prefer.

Re: I still prefer MCP over skills

#278

Post by simonw »

lewisjoe wrote: post #48

> ChatGPT can’t run CLIs. Neither can Perplexity or the standard web version of Claude. Unless you are using a full-blown compute environment (like Perplexity Computer, Claude Cowork, Claude Code, or Codex), any skill that relies on a CLI is dead on arrival. Incorrect observation. Claude web does support skills upload. I guess claude runs code_interpreter tool and filesystem in the background to run user uploaded ski…

Yeah, regular web chat Claude and ChatGPT both have full container access (even on the free version, at least for ChatGPT) which can run CLI tools.

Both of them can even install CLI tools from npm and PyPI - they're limited in terms of what network services they can contact aside from those allow-listed ones though, so CLI tools in those environments won't be able to access the public web.

... unless you find the option buried deep in Claude for enabling additional hosts for the default container environment to talk to. That's a gnarly lethal trifecta exfiltration risk so I recommend against it, but the option is there!

More notes on ChatGPT's ability to install tools:

- https://simonwillison.net/2026/Jan/26/chatgpt-containers/

Re: I still prefer MCP over skills

#279

Post by morgaesis »

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 my life motto. Progressive exploration, codifying, use your codified workflows.

> for each desired change, make the change easy (warning: this may be hard), then make the easy change - Kent Beck

https://x.com/KentBeck/status/250733358307500032

Re: I still prefer MCP over skills

#280

Post by kordlessagain »

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…

Nobody said anything about an API with thousands of endpoints. Does that even exist? I've never seen it. Wouldn't work on it if I had seen it. Such is the life of a strawman argument.

Further, isn't a decorator in Python (like @mcp.tool) the easy way to expose what is needed to an API, if even if all we are doing is building a bridge to another API? That becomes a simple abstraction layer, which most people (and LLMs) get.

Writing a CLI for an existing API is a fool's errand.

Post reply on HN