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

121–130 of 415 posts

Re: I still prefer MCP over skills

#121

Post by chris_ivester »

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.

This is exactly right, and I'd add one more layer that the thread is mostly missing: this combination matters most when the agent itself is hosted in the cloud rather than running locally. Skills + MCP is the architecture for cloud-hosted agents - Skills give the agent its context and workflow, MCP tools give it reach into external services without the agent needing to manage credentials or runtime dependencies.

Re: I still prefer MCP over skills

#122

Post by choam2426 »

This tracks with my experience.

I started out building an MCP server for an internal wiki, but ended up replacing it with a simple CLI + skill because the wiki had no access control and the simpler setup was good enough in practice.

I think that's the important boundary, though: once access control, auth, or per-user permissions enter the picture, I'd much rather have MCP as the interface than rely on local tooling conventions.

Re: I still prefer MCP over skills

#123

Post by alexhans »

This frames MCP vs Skills as an either/or, but they operate at different layers. MCP exposes capabilities and Skills may shape how capabilities are used.

Both are useful to different people (and role families) in different ways and if you don't feel certain pain points, you may not care about some of the value they provide.

Agent skills are useful because they're standardized prompt sharing but more than that, because they have progressive disclosure so you don't bloat your context with an inefficietly designed MCP and their UX is very well aligned such that "/SkillBuilder" skills are provided from the start and provide a good path for developers or non traditional builders to turn conversations into semi or full automation. I use this mental model to focus on the iteration pattern and incremental building [1].

[1] https://alexhans.github.io/posts/series/evals/building-agent...

Re: I still prefer MCP over skills

#124

Post by rimliu »

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.

what you want and what works may be very different things.

Re: I still prefer MCP over skills

#125

Post by lll-o-lll »

friendzis wrote: post #112
lll-o-lll wrote: post #102

Earlier quoted context omitted.

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.

> If not, every API supports keys? How would MCP help you if the API does not support keys? But that's not the point. The agent calls CLI tools, which reads secrets from somewhere where the agent cannot even access. How can agent leak the keys it does not have access to? You ARE running your agents in containers, right?

> How would MCP help you if the API does not support keys?

Kerberos, OAuth, Basic Auth (username/password), PKI. MCP can be a wrapper (like any middleware).

> But that's not the point. The agent calls CLI tools, which reads secrets from somewhere where the agent cannot even access. How can agent leak the keys it does not have access to?

If the cli can access the secrets, the agent can just reverse it and get the secret itself.

> You ARE running your agents in containers, right?

Do you inject your keys into the container?

Re: I still prefer MCP over skills

#126

Post by tomaytotomato »

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…

Although the author is coming from a place of security and configuration being painful with Skills, I think the future will be a mix of MCP, Agents and Skills. Maybe even a more granular defined unit below a skill - a command...

These commands would be well defined and standardised, maybe with a hashed value that could be used to ensure re-usability (think Docker layers).

Then I just have a skill called:

- github-review-slim:latest - github-review-security:8.0.2

MCPs will still be relevant for those tricky monolithic services or weird business processes that aren't logged or recorded on metrics.

Re: I still prefer MCP over skills

#127

Post by bachback »

the best agent framework in my opinion is Pi. Pi avoids MCP thats a good thing. why assume that the planet will migrate from HTTP to MCP? no, instead lets assume we have client code we can call. we already have a rich ecosystem of HTTP services and packages. and if we assume a rewrite for agents we probably wouldn't come up with MCP but something more powerful.

Re: I still prefer MCP over skills

#128

Post by rakamotog »

There is one area where MCP typically has challenges - Not a technical challenge but a practical challenge.

Imagine you are creating an asset which requires multiple API calls and your UI is designed to go through a 10-12 step setup process for that asset. In practice even if we give one tool for LLM to one-shot it, or even if we break it down into 10-12 tools the points of hallucinations are much higher.

Contrast this with "skills" and CLI.

Re: I still prefer MCP over skills

#129

Post by exossho »

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…

agree I don't get this discussion anyways Those are two different things, and actually they work well together..

Re: I still prefer MCP over skills

#130

Post by seriousmountain »

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]
Post reply on HN