Live data from Hacker News

I still prefer MCP over skills

david.coffee

51–60 of 415 posts

Re: I still prefer MCP over skills

#51

Or use both. Remote MCPs are secure, CLI allows for programmatic execution. Use bash to run remote MCPs. I built this to solve this exact problem. https://github.com/turlockmike/murl

What about remote MCPs lend themselves to security? For instance, do you think that it is more secure than a traditional endpoint?

MCPs are basically just JSON-rpc. The benefit is that if you have applications that require an API key, you can build a server to control access (especially for enterprise). It's the same as REST apis, except by following a specific convention we can take advantage of generic tools (like the one I built) and means you don't need to rely on poor documentations to connect or train a model to use your very specific CLI.

Re: I still prefer MCP over skills

#53

This author does not realize that skills can call APIs. The idea that you have to build dedicated CLI apps is not true at all and invalidates the entire article.

Can you clarify what exactly you mean? Skills are markdown files, so they definitely can't call APIs or CLIs. Are you saying that a skill can tell the agent to use curl to call web APIs? Or something different?

They almost certainly mean skills can tell the agent to use the api, and it can succeed at doing that.

Re: I still prefer MCP over skills

#55
My biggest gripe with skills is that even clear and explicit instructions are regularly ignored - even when the skill is brief (I’ll often see the agent saying it’s about to do something so I’ll stop it and ask “what does the xxx skill say about doing that?’ And it’ll go away and think and then say “oh, the skill says I should never do that”

Re: I still prefer MCP over skills

#56

This author does not realize that skills can call APIs. The idea that you have to build dedicated CLI apps is not true at all and invalidates the entire article.

Can you clarify what exactly you mean? Skills are markdown files, so they definitely can't call APIs or CLIs. Are you saying that a skill can tell the agent to use curl to call web APIs? Or something different?

Skills can bundle scripts. Skills can express how to use curl. Skills can integrate with your fips keys if you want them to.

Re: I still prefer MCP over skills

#58

Earlier quoted context omitted.

What about remote MCPs lend themselves to security? For instance, do you think that it is more secure than a traditional endpoint?

MCPs are basically just JSON-rpc. The benefit is that if you have applications that require an API key, you can build a server to control access (especially for enterprise). It's the same as REST apis, except by following a specific convention we can take advantage of generic tools (like the one I built) and means you don't need to rely on poor documentations to connect or train a model to use your very specific CLI.

But if you have customer facing APIs then all of these problems were already solved in an enterprise context. You can force an oauth flow from skills if you want.

I don’t think that CLIs are the path forward either, but you certainly don’t have to teach a model how to use them. We’ve made internal CLIs that adhere to no best practices and expose limited docs. Models since 4o have used them with no issue.

The amount of terminal bench data is just much higher and more predictable in rl environments. Getting a non thinking model to use an MCP server, even hosted products, is an exercise in frustration compared to exposing a cli.

A lot of our work is over voice, and I’ve found zero MCPs that I haven’t immediately wanted to wrap in a tool. I’ve actually had zero MCPs perform at all (most recently last week with a dwh MCP and opus 4.6, where even the easiest queries did not work at all).

Re: I still prefer MCP over skills

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

This is obviously not what it is. If I give you APIGW would you be able to implement an MCP server with full functionality without a large amount of middleware?

Re: I still prefer MCP over skills

#60
post #17

This author does not realize that skills can call APIs. The idea that you have to build dedicated CLI apps is not true at all and invalidates the entire article.

No, the point was that you don’t have access to a CLI in every environment.

You could have access to a web browser or web request tool instead.
Post reply on HN