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

141–150 of 415 posts

Re: I still prefer MCP over skills

#141

Post by ReDeiPirati »

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…

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

I noticed that LLMs will tend to work by default with CLIs even if there's a connected MCP, likely because a) there's an overexposure of CLIs in training data b) because they are better composable and inspectable by design so a better choice in their tool selection.

Re: I still prefer MCP over skills

#142

Post by dvcrn »

nextaccountic wrote: post #90

> Context Bloat: Using a skill often requires loading the entire SKILL.md into the LLM’s context window, rather than just exposing the single tool signature it needs. It’s like forcing someone to read the entire car’s owner’s manual when all they want to do is call car.turn_on(). MCP has severe context bloat just by starting a thread. If harnesses were smart enough to, during install time, summarize the tools provide…

> MCP has severe context bloat just by starting a thread

Hi, author here. The “MCP has severe context bloat” problem has already been solved with tool discovery. Modern harnesses don’t load every single tool + their descriptions into the context on load, but use tool search to discover the tools lazily when they’re needed. You can further limit this by telling the LLM exactly which tool to load, the rest will stay unloaded / invisible

> But a worse problem is that the output of MCP goes straight into the context of the agent, rather than being piped somewhere else

This is semi-solved as agents and harnesses get smarter. Claude Code for example does discovery in subagents. So it spawns a sub-agent with a cheaper model that explores your codebase / environment (also through MCP) and provides a summary to the parent process. So the parent won’t get hit with the raw output log

Re: I still prefer MCP over skills

#144

Post by _pdp_ »

Scanning through the comments here I am almost certain the majority of people in this thread run coding agents on-device. Skills that access already available resources is then more convenient and you can easily make the argument that it is more agronomic.

That being said, majority of users on this planet don't use AI agents like that. They go to ChatGPT or equivalent. MCP in this case is the obvious choice because it provides remote access and it has better authentication story.

In order to make any argument about pro/con of MCP vs Skills you first need to find out who is the user.

Re: I still prefer MCP over skills

#146

Post by pavelbuild »

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…

[dead]

Re: I still prefer MCP over skills

#147

Post by pavelbuild »

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…

[dead]

Re: I still prefer MCP over skills

#148

Post by pavelbuild »

TheTaytay wrote: post #36
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 keep getting hung up on securely storing and using secrets with CLI vs MCP. With MCP, you can run the server before you run the agent, so the agent never even has the keys in its environment. That way. If the agent decides to install the wrong npm package that auto dumps every secret it can find, you are less likely to have it sitting around. I haven’t figured out a good way to guarantee that with CLIs.

[dead]

Re: I still prefer MCP over skills

#149

Post by williamdclt »

friendzis wrote: post #116
daemonologist wrote: post #31

Earlier quoted context omitted.

Obvious example is a corporate chatbot (if it's using tools, probably for internal use). Non-technical users might be accessing it from a phone or locked-down corporate device, and you probably don't want to run a CLI in a sandbox somewhere for every session, so you'd like the LLM to interface with some kind of API instead. Although, I think MCP is not really appropriate for this either. (And frankly I don't think ch…

> and you probably don't want to run a CLI in a sandbox somewhere for every session You absolutely DO want to run everything related to LLMs in a sandbox, that's basic hygiene

You're missing their point, they're saying that you'd need a sandbox -> it'd be a pain -> you don't want to run a CLI _at all_

Re: I still prefer MCP over skills

#150

Post by dvcrn »

alierfan wrote: 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.

Hi, author here! I fully agree with your comment here and that’s exactly my point in the post: Different tools that work great for different tasks. If anything, the post is a take against treating Skills + CLI as a zero-sum replacement for MCP, and calling MCP dead/outdated

Especially portability is just not possible with Skills+CLI (yet). I can use the same MCP servers through remote MCP on my phone, web, iPad, in ChatGPT, Perplexity, Claude, Mistral and so on, which I can’t do with Skills.

Post reply on HN