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?
I still prefer MCP over skills
51–60 of 415 posts
Re: I still prefer MCP over skills
#52Re: I still prefer MCP over skills
#53This 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?
Re: I still prefer MCP over skills
#54Re: I still prefer MCP over skills
#55Re: I still prefer MCP over skills
#56This 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?
Re: I still prefer MCP over skills
#57Re: I still prefer MCP over skills
#58Earlier 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.
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
#59Earlier 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.
Re: I still prefer MCP over skills
#60This 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.