alt Hacker NewsI still prefer MCP over skills
Comments
I think the key problem is that usage of MCP servers is not 'baked' into the LLM training - but API's and CLI's are already a part of training. So to use your MCP server, the LLM has to use additional intelligence which could have been used to do the actual work instead.
Skills are static; MCP servers is dynamic. Skills codify info and workflows, help decrease redundant instructions, and increase consistent outcomes. MCP servers allow access to changing resources across systems.
You may dislike MCP, and there are certainly valid arguments to be made there, but that doesn't mean you can replace it with skills. If you could replace a given MCP server with a skill it would only indicate that someone misunderstood the assignment and chose the wrong tool in the first place. It wouldn't indicate the superiority of one thing over the other.
This whole article, and it's current rank on HN (#5), is making me feel like I took crazy pills this morning. A colleague suggests this Skills vs MCP discourse is big on Twitter, so maybe I lack the necessary background to appreciate this, but aren't these different tools, solving for different things, in different ways? Is this parody? Am I falling into a bot engagement trap by even responding to this? The article certainly reads like LinkedIn drivel, with vague, emphatic opinions about nothing.
Different techniques appropriate in different situations, I would decide on what's appropriate given the goals you have. Whichg is nearly always the answer to X is a better way than Y arguments.
>>>The core philosophy of MCP is simple: it’s an API abstraction.
That's exactly the problem. As agents become better and can read API documentation themselves, WHY do you need an API abstraction?
Having developed mantyx.io, I believe that rest apis are still champion. MCP is nothing more than rest wrappers most of the time and skills are cli wrappers which in turn are rest wrappers.
I think skills are just a marketing ploy. There is nothing preventing a MCP from serving skills.
People in the comments still confused about “agentic development” vs. “agentic development”. One uses the cli best, while the other cannot use a cli very well.
The first is using agents locally to develop.
The second is developing an agent. Not necessarily for coding, mind you. Not even for just text sometimes.
They are different cases, MCP is great for the latter.
I still use vanilla Claude Code without MCP or skills, am I in the minority? Not trying to be a luddite.
CLI is massively superior to MCP in my experience. First, because I also understand what's going on and do it myself if necessary. Second because it's so much cheaper in terms of tokens it's not even funny
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
I think both will stick around because they solve two different problems. 1) what are you able to do (skills) 2) which tools you have to do it (mcp)
Huh, I think the author might be deliberately ignoring how MCP works?
- "CLIs need to be published, managed, and installed" -- same for MCP servers which you have to define in your config, and they frequently use some kind of "npx mcp-whatever" call.
- "Where do you put the API tokens required to authenticate?" -- where does an MCP server put them? In your home folder? Some .env file? The keychain? Same like CLI tools.
- "Some tools support installing skills via npx skills, but that only works in Codex and Claude Code, not Claude Cowork or standard Claude" -- sure, but you also can't universally define MCP servers for all those tools. You have to go ahead and edit the config anyway.
- "Using a skill often requires loading the entire SKILL.md into the LLM’s context window, rather than just exposing the single tool signature it needs" -- yeah, but it's on-demand rather than exposing ALL MCP servers' tool signatures. Have you ever tried to use playwright MCP?
I just don't buy the "without any setup" argument.
Nice someone who actual works with the systems. Thank you.
I think so,I like only use Claude Code by MCP,let it connect
Like saying I prefer websites over CLI, or bicycles over canoes. Chisels over planes. Depends what you are trying to achieve.
the best agent framework in my opinion is Pi. Pi avoids MCP thats a good thing. why assume that the planet will migrate from HTTP to MCP? no, instead lets assume we have client code we can call. we already have a rich ecosystem of HTTP services and packages. and if we assume a rewrite for agents we probably wouldn't come up with MCP but something more powerful.
This skills obsession is a Claude/anthropic fanboy thing imo. Goodbye sweet karma
The whole article serves just to promote his SaaS.
Not same tools, different purpose from my opinion
AI tools for non technical users that can work on browsers and mobile app will be super powerful. I think MCPs are currently the best way to reach this audience.
Different 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?
Remote MCP solve the delivery and update issues just like saas and browsers did for human users. Not much more to it really
Complete in synch with the author MCP and A2A for the win.
Use both. These do different things.
MCP pollutes the context, if you dont care about wasting context token for all MCP tools, go ahead and use MCP, but you should know that cli tool+skill can perfectly replace it with less token overhead and better matching due to skill's front matter
I've remained leaning a bit towards MCP until lately. Both have pretty easy ways to call the other (plenty of cli API callers, and tools like mcp-cli for the reverse https://github.com/philschmid/mcp-cli). Skills have really made progressive discovery if cli-tools much better, and MCP design has adapted likewise. I've lightly preferred MCP for formalism, for it feeling more concrete as a thing.
But what really changed my mind is seeing how much more casual scripting the LLMs do these days. They'll build rad unix pipes, or some python or node short scripts. With CLI tools, it all composes: every trick it learns can plug directly into every other capability.
Where-as with MCP, the LLM has to act as the pipe. Tool calls don't compose! It can read something like this tmux skill then just adapt it in all sorts of crazy ways! It can sort of do that with tool calls, but much less so. https://github.com/nickgnd/tmux-mcp
I'd love to see a capnproto capnweb or some such, with third party handoff (apologies Kenton for once again raising 3ph), where a tool call could return a result and we could forward the result to a different LLM, without even waiting for the result to come back. If the LLM could compose tool calls, it would start to have some parity with the composability of the cli+skill. But it doesn't. And as of very recently I've decided that is too strong a selling point to be ignored. I also just like how the cli remains the universe system: if these are so isomorphic as I keep telling myself, what really does the new kid on the block really bring? How much is a new incarnation better if their capabilities are so near? We should keep building cli tools, good cli tools, so that man and machine benefit.
That said I still leave the beads mcp server around. And I turn on the neovim MCP when I want to talk to neovim. Ah well. I should try harder to switch.
I prefer peanut butter over jelly.
skills and mcp help with entirely different things. sure most products add a skill on using their mcp so that model's tool calling works good.
They seem like fundamentally different things.
Seriously, the only drawback of MCP is its name. If it were named "API discovery protocol" (which is what it is) none of these debates would have existed.
API vs MCP sounds like a real debate, but it really isn't. It's "API vs API discovery protocol." See how asinine it sounds if we call things for what they are.
We had a contention between MCP / Skills for our product and ended up offering both. We built a CLI tool that could interface with the MCP server [1]. It seems redundant but our app is a coding app on iOS (Codea), and the issue with offering a plain MCP server meant that the agentic coding harness found it harder to do its job.
With the CLI the agent could check out the project, work on it locally with its standard file editing / patching / reading tools, then push the work back to device. Run and debug on device, edit locally, push.
With MCP the agent had to query the MCP server for every read and write and was no longer operating in its normal coding loop. It still works, though, and as a user you can choose to bypass the CLI and connect directly via MCP.
The MCP server was valuable as it gave us a consistent and deterministic language to speak. The CLI tool + Skill was valuable for agentic coding because it allowed the coding work to happen with the standard editing tools used by agents.
The CLI also gave us device discovery. So the agent can simply discover nearby devices running Codea and get to work, instead of a user having to add a specific device via its IP address to their agent.
MCP versus Skills -> wrong debate. MCP versus CLI -> real debate.
this is very good and correct
> Skills are great for pure knowledge and teaching an LLM how to use an existing tool. But for giving an LLM actual access to services, the Model Context Protocol (MCP) is the far superior, more pragmatic architectural choice.
There's your answer. If you want to use local tools, use Skills. If you want to use services, use MCP. Or, you know, whatever works best for your scenario.
Am I the only one who doesn't trust remote servers?
Can someone more enlightened in this area explain how this is used?
Is MCP for in-house LLMs or can it work with ChatGPT as well? As far as I know it's a server with small self-contained task scripts. But don't get how the coordination works and how it's used.
They’re different things. You can have skills using MCP.
MCP is too thristy
> Using a skill often requires loading the entire SKILL.md into the LLM’s context window, rather than just exposing the single tool signature it needs.
Isn't this, like, the exact thing MCP is the worst at? You need to load the entire MCP into the context even if you're not using the MCP's relevant functions. Which is why some people put them on subagents, which is like, equivalent to putting the MCP behind a CLI function, at which point, why not just have the CLI function and selectively load it when yo- OH WAIT, THERE'S A NAME FOR THAT!
> Skills are great for pure knowledge and teaching an LLM how to use an existing tool. But for giving an LLM actual access to services, the Model Context Protocol (MCP) is the far superior
That's it. For some things you need MCP, for some things you need SKILLs - these things coexist.
Yesterday I accidentally stumbled on a place where I could really appreciate MCP's.
I wanted to connect my Claude account to my Notion account. Apparently all you need to do is just submit the notion MCP and log in. That's it! And I was able to interact with my Notion data from my Claude account!
Imagine how hard this would be with skills? It is literally impossible because with skills, you may need to install some local CLI which Claude honestly should not allow.
If not CLI, you need to interact with their API which again can't happen because you can't authenticate easily.
MCP's fill this narrow gap in my opinion - where you don't own the runtime and you want to connect to other tools like plugins.
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...
I 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 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.
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.
why not both
auth
i feel like giving an agent shell access and internet is batshit crazy.
that's just me i guess.
[dead]
Don't they both solve different problems? This tribalism makes no sense.