Despite thinking this is AI-generated, I agree but everything has a caveat. Skills are good for instilling non-repeatable, yet intuitive or institutional knowledge. MCP’s are great for custom, repeatable tasks. After 5-10 runs of watching my LLM write the same exact script, I just asked it to hardcode the solution and make it a tool. The result is runs are way faster and repeatable.
> Skills are good for instilling non-repeatable, yet intuitive or institutional knowledge. Maybe I'm misinterpreting you, but can you explain this more? I've been using skills for repeatable tasks. Why an MCP instead?
I still prefer MCP over skills
21–30 of 415 posts
Re: I still prefer MCP over skills
#22I’ve gone the other way, and used MCP-CLI to define all my MCP servers and wrap them in a CLI command for agent use. This lets me easily use them both locally and in cloud agents, without worrying about the harness support for MCP or how much context window will be eaten up. I have a minimal skill for how to use MCP-CLI, with progressive disclosure in the skill for each of the tools exposed by MCP-CLI. Works great.
All that said, I do think MCP will probably be the standard going forward, it just has too much momentum. Just need to solve progressive disclosure (like skills have!) and standardize some of the auth and transport layer stuff.
Re: I still prefer MCP over skills
#23I 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.
Ok, but there are still many environments where an LLM will not have access to a CLI. In those situations, skills calling CLI tools to hook into APIs are DOA.
Re: I still prefer MCP over skills
#24I 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.
Ok, but there are still many environments where an LLM will not have access to a CLI. In those situations, skills calling CLI tools to hook into APIs are DOA.
Re: I still prefer MCP over skills
#25Re: I still prefer MCP over skills
#26The "only skills" people are usually non-technical and the "only CLI" people are often solo builders. MCP makes a lot of sense for enterprise IMO. Defines auth and interfaces in a way that's a natural extension of APIs.
I’d really love to get away from the SSE MCP endpoints we use, as the Claude desktop app can get really finicky about disconnects. I thought about distributing some CLIs with Skills instead. But, MCP can be easily updated with new tools and instructions, and it’s easy to explain how to add to Claude for non-technical people. I can’t imagine trying to make sure everyone in my company had the latest skill and CLI on their machine.
Re: I still prefer MCP over skills
#27I 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.
Ok, but there are still many environments where an LLM will not have access to a CLI. In those situations, skills calling CLI tools to hook into APIs are DOA.
Re: I still prefer MCP over skills
#28Re: I still prefer MCP over skills
#29I love the idea of MCP, but it needs a progressive disclosure mechanism. A large MCP from a provider with hundreds or even thousands of tools can eat up a huge amount of your context window. Additionally, MCPs come in a bunch of different flavors in terms of transport and auth mechanisms, and not all harnesses support all those options well. I’ve gone the other way, and used MCP-CLI to define all my MCP servers and w…
The article claims so:
> Smart Discovery: Modern apps (ChatGPT, Claude, etc.) have tool search built-in. They only look for and load tools when they are actually needed, saving precious context window.