Live data from Hacker News

I still prefer MCP over skills

david.coffee

71–80 of 415 posts

Re: I still prefer MCP over skills

#71
post #39

Earlier quoted context omitted.

Why are they not calling APIs directly with strictly defined inputs and outputs like every other internal application? The story for MCP just makes no sense, especially in an enterprise.

MCP is an API with strictly defined inputs and outputs.

Does MCP support authentication, SSO?

Re: I still prefer MCP over skills

#72
post #52

I still use vanilla Claude Code without MCP or skills, am I in the minority? Not trying to be a luddite.

I would guess the top 10% of actual performers do the same - the people who talk about harnesses and chain multiple systems together etc will be mid table somewhere

Re: I still prefer MCP over skills

#74
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 often just put direct curl commands in a skill, the agent uses that, and it works perfectly for custom API integrations. Agents are perfectly capable of doing these types of things, and it means the LLM just uses a flexible set of tools to achieve almost anything.

Re: I still prefer MCP over skills

#75

Earlier quoted context omitted.

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.

A CLI can just be a RPC call to a daemon, exact same pattern apply. In fact my most important CLI based skill are like this.. a CLI by itself is limited in usefulness.

In other words, a wrapper around an MCP that's less verbose.

Re: I still prefer MCP over skills

#76
100% MCPs truly give the agent tools and allow the agent to make better informed decisions given you can have configured the right MCP tools. Skills are good for knowledge and general guidelines. They give context to the agent, and I have seen some skills being excessively long that could into eat into the context window of the agent. This tool https://protomcp.io/ helps a lot with testing MCP servers before integrating into the agent workflow. You can even see the agent call different tools in real time and view the trace.

Re: I still prefer MCP over skills

#77
I use both and don't feel they're mutually exclusive.

E.g. if I have some ElasticSearch cluster, I use a skill to describe the data, and if I ask the LLM to write code that queries ElasticSearch but to test it first it can use a combination of skill + MCP to actually run a query.

I think this model works nicely.

Re: I still prefer MCP over skills

#78
SKILLS.md or AGENTS are good concepts but they miss two crucial things that will make them much more usable. I predict that this will happen.

Each SKILLS.md will come with two hooks:

1. first for installing the SKILL itself - maybe install the CLI or do some initial work to get it working

2. Each skill may have dependencies on other skills - we need to install those first

Expressing these two hooks in a formal way in skills would help me completely replace MCP's.

My concrete prediction is that this will happen soon.

Wrote more about it here: https://simianwords.bearblog.dev/what-agent-skills-misses-no...

Re: I still prefer MCP over skills

#79
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 often just put direct curl commands in a skill, the agent uses that, and it works perfectly for custom API integrations. Agents are perfectly capable of doing these types of things, and it means the LLM just uses a flexible set of tools to achieve almost anything.

I think this is the best of both worlds. Design a sane API (that is easy to consume for both humans and agents), then teach the agents to use it with a skill.

But I agree with the author on custom CLI tooling. I don’t want to install another opaque binary on my machine just to call some API endpoints.

Post reply on HN