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.
I still prefer MCP over skills
71–80 of 415 posts
Re: I still prefer MCP over skills
#72I still use vanilla Claude Code without MCP or skills, am I in the minority? Not trying to be a luddite.
Re: I still prefer MCP over skills
#73Different tools for different jobs man... I prefer the right tool for the job, and both skills and MCP seem necessary. Do you also prefer forks over spoons?
On the 8th day god created the spork.
Re: I still prefer MCP over skills
#74I 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.
Re: I still prefer MCP over skills
#75Earlier 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.
Re: I still prefer MCP over skills
#76Re: I still prefer MCP over skills
#77E.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
#78Each 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
#79I 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.
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.