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

371–380 of 415 posts

Re: I still prefer MCP over skills

#371

Post by pojzon »

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 how I work with my agent harness. Also have skills for writing tools and skills.

And I still think ppl dont understand why MCPs are still needed and when to use them.

Its actually pretty simple.

Re: I still prefer MCP over skills

#372

Post by pojzon »

jjice wrote: post #320
theshrike79 wrote: post #315

Earlier quoted context omitted.

That’s what we’re doing, but it’s annoying. Why can’t they just let us limit access for the official MCP easily?

Agreed. Sounds like a failure of the services, but not MCP. Can't believe in 2026 we don't have better permissions on systems like this.

“Communism can work we just did not see a good implementation of it”. If majority of implementations fail at it -> protocol is defined incorrectly. With security first approach it would not be the case.

Re: I still prefer MCP over skills

#374

Post by upcoming-sesame »

lll-o-lll wrote: post #102
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.

Cool cool. Except. What about auth? Authn and authz. Agent should be you always? If not, every API supports keys? If so, no fears about context poisoned agents leaking those keys? One thing an MCP (server) gives you is a middleware layer to control agent access. Whether you need that is use-case dependent.

That's not a limitation of CLIs, they can work with a different auth as well.

they are just a superior tool to MCP because the agent can write code that invokes, pipes and do many other things with the tool

Re: I still prefer MCP over skills

#375

Post by nextaccountic »

dvcrn wrote: post #142
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 un…

> Claude Code for example does discovery in subagents.

but this still burns tokens needlessly in the subagent. if the agent could filter the mcp output using a cli (often jq, but sometimes something else), it could be more economical

maybe anthropic wants you to burn those tokens though

Re: I still prefer MCP over skills

#376

Post by SOLAR_FIELDS »

xyzzy123 wrote: post #202
prohobo wrote: post #159

Earlier quoted context omitted.

Right, that feels like something you'd do with a script and some API calls. MCP is more for a back and forth communication between agent and app/service, or for providing tool/API awareness during other tasks. Like MCP for Jira would let the AI know it can grab tickets from Jira when needed while working on other things. I guess it's more like: the MCP isn't for us - it's for the agent to decide when to use.

I just find that e.g. cli tools scale naturally from tiny use cases (view 1 ticket) to big use cases (view 1000 tickets) and I don't have to have 2 ways of doing things. Where I DO see MCPs getting actual use is when the auth story for something (looking at you slack, gmail, etc) is so gimped out that basically, regular people can't access data via CLI in any sane or reasonable way. You have to do an oauth dance invo…

The auth angle is pretty interesting here. I spend a fair amount of time helping nontechnical people set up AI workflows in Claude Cowork and MCP works pretty well for giving them an isolated external system that I can tightly control their workflow guardrails but also interestingly give them the freedom to treat what IS exposed as a generic api automation tool. That combined with skills lets these non technical people string together zapier like workflows in natural language which is absolutely huge for the level of agency and autonomy it awards these people. So I find it quite interesting for the use case of providing auth encapsulated API access to systems that would normally require an engineer to unlock. The story around “wrap this REST API into a controlled variant only for the end users use case and allow them to complete auth challenges in every which way” has been super useful. Some of my mcp servers go through an oauth challenge response, others provide them guidance to navigate to the system and generate an api key and paste it into the server on initial connection.

Re: I still prefer MCP over skills

#377

Post by mikestorrent »

jFriedensreich wrote: post #365
mikestorrent wrote: post #335

Earlier quoted context omitted.

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…

Don't think its relevant who they are if they give advice that is based on outdated understanding of how agent harnesses are build and how to use MCP in an agent harness in the first place. You can serve agent skills via mcp or via text files accessed via local tools, if your harness makes this look different to the LLM in the end it is just a bad harness. The LLM should just see "ways to discover skills" and then "u…

What if the MCP needs to actually do something, like make an API call? It's nice sometimes to have those credentials out-of-band from the AI itself so it can't access them and is forced to go through the lens of tooling.

Re: I still prefer MCP over skills

#378

Post by throwpoaster »

tim-projects wrote: post #306
throwpoaster wrote: post #206

Earlier quoted context omitted.

Skills and MCP are useful for when you need to repeat specific processes, perpetually. Without them the task description and reasoning falls out of the context window, or is compressed, and the process fails. An agent will eventually forget, or hallucinate, guardrails and requirements. Yes to AGENTS.md, but when you're actively managing the whole context window in a long-running task you don't want to just keep jammi…

AGENTS.md doesn't fall out of the context window so you just put whatever commands you use in there. Every time it gets too big you rewrite it. Never had an issue doing this

How long have you had an agent performing the same task, or trying to improve performance towards the same outcome?

I’m not really talking about coding. I’m talking about autonomy.

Re: I still prefer MCP over skills

#380

Post by aulin »

Aperocky wrote: post #38

Occams Razor spares none. Everything will go to the simplest and most convenient, often both, despite the resistance of the complexity lovers. Sorry MCP, you are not as simple as CLI/skill/combination, and no, you are not more secure just because you are buried under 3 level of spaghetti. There are no reason for you to exist, just like Copilot. I don't just wish, but know you'll go into obscurity like IE6.

What did poor copilot do now?
Post reply on HN