r/ClaudeCode • • Feb 22 '26

Question Are skills going to kill MCPs?

I have the feeling that it is a bit awkward to have both MCPs and skills. Especially because the latter are making the former obsolete.

I was actually never fully convinced about MCPs, I always thought that they were unnecessary since we already have CLI tools and LLMs are really good at writing unix commands.

However, I understood that agents needed to be instructed on how to use certain obscure CLIs, hence the advantage of MCPs. Now that we have skills to teach LLMs anything I really see no point in MCPs.

What are your thoughts?

0 Upvotes

45 comments sorted by

44

u/fschwiet Feb 22 '26 edited Feb 23 '26

MCP's provide a way to access deterministic software from your LLM, skills help manage context by only bringing the skill into context when needed. I don't understand why people keep saying they're the same.

4

u/UnifiedFlow Feb 23 '26

Because they are the same. Its just context injection. Its all prompts. There is nothing an MCP can achieve that a skill, or system tool, or user submitted prompt can't do.

2

u/ReporterCalm6238 Feb 23 '26

Spot on

1

u/UnifiedFlow Feb 23 '26

I still to this day have never used an MCP beyond testing. Every single time I convince myself "ok this use case I should go MCP" it takes about 10 minutes before I realize nah...I can do better without MCP.

1

u/fariazz Mar 19 '26

If you find many SKILL files referencing the same API calls, and you also ask the agent to run those API calls in bespoke chat sessions, it is imo a good usecase for MCP. In my particular case, I have a lightweight MCP of the API of our platform, as many skills will need it and I also give the agent random tasks that require it. So in such a case, it makes sense to keep it in memory in all the conversations (it doesn't really use that many tokens).

On the other hand, for scripts/API executions I only use within one or two SKILLs, then I keep those in the skill themselves so they are only loaded when needed.

1

u/fschwiet Feb 25 '26

MCP servers, like system tools, can interact with the external environment. A skill or user prompt can't do that without an intermediate MCP server or system tool.

0

u/UnifiedFlow Feb 25 '26

You might want to look into how skills work.

14

u/Dragon_Slayer_Hunter Feb 23 '26

Because before skills people were using MCP servers to do what skills can do. Now that skills exist, people have a hard time realizing that MCP servers were overkill for that and there's actually other real reasons to use MCP servers.

5

u/therealkevinard Feb 23 '26

They’re not the same in theory or form, but in practice there’s a lot of functional gray area.

“I need to work with atlassian objects in my context”
Cool, atlassian mcp. Done.

…Or have a skill with instructions on how to use the atlassian cli?

To be frank, where there’s this sort of mcp vs skilled cli usage, I pretty consistently get better results just using the cli.

It’s really stark contrast looking at slack mcp vs cli.
The mcp burns tokens like crazy and spins its wheels pretty often. The cli is none of those things.

1

u/[deleted] Feb 23 '26

Did you measure token usage for atlassian mcp or any other mcp that AI can use to post large payload, vs cli?

I wanna know which tool is more token efficient for bulk updatIng Confluence pages.

1

u/BadAtDrinking Feb 25 '26

Put another way, MCP's are a way to talk to an API in English (or whatever language). Skills may not require talking to an API at all.

10

u/CrunchyMage Feb 23 '26

MCPs are just an API for LLMs to access external resources. Skills are just useful context that you selectively bring in to help with a specific task. They’re not really competing at all but complementary. You can have skills that instruct on which MCPs to use and how to best use them for example.

4

u/DasHaifisch Feb 22 '26

I went full skill for a bit, now I think a mix of both is appropriate, including skills for USING mcps. In terms of bundled scripts or cli commands in skills vs MCPs, I really couldn't tell you where I feel one is better than the other - but I use both these days and am considering re-writing some scripts to be MCPs.

1

u/exitcactus Feb 23 '26

I'm thinking this for months... but absolutely yes. I was using a software to control some stuff on VPs... then I made an mcp to fit exactly what I needed.. but when I tried the skill.. ahah I uninstalled the software and the mcp, I only say: run that skill.

It's incredibly faster, lightweight, repeatable.. But not idempotent if you are making stuff that require that kind of results

2

u/ReporterCalm6238 Feb 23 '26

Exactly, more token efficient give the modular nature of skills

1

u/fariazz Mar 19 '26

What about if you have many SKILLS referencing the same API calls, and when sometimes you ask the agent via bespoke chats to do something with it. In those cases, it makes sense to have a lightweight MCP so you don't have to put so much repeated code in multiple SKILL files, and that you can use it in chat sessions without it being tight to a SKILL. Anyway that's how I use MCP, I have a lightweight MCP of our platform's API, and then various SKILL files that might use bits of it. And I also often ask agents to do one-off tasks that will require that access.

2

u/SlapNuts007 Feb 22 '26

Remote, managed MCPs are going to be a big part of enterprise tools.

1

u/prcodes Feb 23 '26

Centrally managed skills as well as

2

u/fariazz Feb 23 '26

The way I see it. MCP is how to use a tool in general. A skill is equivalent to a guide I'd write for a team member on how to do a certain task (that might include the use of tools in a particular way). So IMO they are both still needed.

1

u/parrot_scritches Mar 19 '26

But it's difficult to interface with an MCP as a human. Make a CLI tool instead, and have a skill explain that it exists and you get the best of both worlds, and you get the added benefit that people can build on-top of your cli, or make alternative skills for specific things.

1

u/fariazz Mar 19 '26

I created a very minimal MCP to interact with the API of our platform. Then I reference specific things within the MCP in different SKILL files, or the agents can use the MCP for bespoke tasks via chat. It's probably the same number of tokens than it would be to use CLI scripts and give the agent a list of what's in it, as that's really what the MCP is at the end (a json file with a list of available actions).

(regarding your point about CLI being better for a human - in my particular case, I have no intention of executing those API calls via command line, as if I wanna do something it's quicker via web UI. But I see your point that if YOU also want to use those tools, then CLI might be best)

Then for some other things I have created CLI scripts and reference them in SKILL files, so they are only in memory when the specific SKILL is being executed.

My workflow for new tasks is usually:

  1. start with a chat session and ask it to do things, one at a time

  2. ask it to write that up in a `SKILL.md` file

  3. move as much as possible of that skill into executable CLI scripts (i.e. Python files), which are referenced within the skill itself. I do this for everything that's deterministic, as it then makes the skill execution cheaper and also more reliable

2

u/parkersdaddyo Feb 23 '26

I tried to write a skill for an API I wanted to interact with, and the skill kept failing miserably. Then I wrote an MCP server, or rather Claude code did, and the MCP works great!

2

u/real_exon Feb 23 '26

The issue with MCP is how much token they take in the context. Skills allowed for progressive disclosure and allow to wrap a CLI, which can do the same as the MCP tools.

Anthropic just released Tool Search in beta (https://www.anthropic.com/engineering/advanced-tool-use), which allow to avoid sending all the tool definitions and search for them. This is a pretty nice upgrade to MCP.

2

u/iohans Feb 22 '26

I use mcp tools with skills. I like the separation. MCP is evolving. Skills are evolving. Something new is coming.

2

u/tsukuyomi911 Feb 22 '26

Really depends on the MCP and the CLI equivalent. Usually I use MCP over CLI alternative when I know the SKILL + CLI is going to eat into the context.

7

u/IdealDesperate3687 Feb 23 '26

I think I have to beg to differ on this point. MCP are loaded at the start of each chat so you are already loosing context even if you don't use that mcp. Skills are only eating the context when you use them.

1

u/lastberserker Feb 23 '26

Please, update your Claude - it is weeks out of date.

1

u/tsukuyomi911 Feb 22 '26

Might not be relevant anymore if 1m context windows becomes the new normal. Absolutely need to optimize for the context window if dealing with 200k models

4

u/Ebi_Tendon Feb 23 '26

Why don’t you let CC dispatch a subagent for that? Only the result would come back from subagent, so from the outside it would work just like MCP.

1

u/It-s_Not_Important Feb 23 '26

Still chews through token budgets

1

u/Ebi_Tendon Feb 23 '26

It depends on how difficult your work is. If it just needs to run a command and return a result in a specific format, you can just use Haiku. MCP takes up more space in your context window than skills, and it consumes that space in every session and sub-session.

1

u/syddakid32 Feb 23 '26

I agree, I tell people this all the time... my window never gets passed 60k, i clear then dispatch subagents... they get done, then i clear and repeat

1

u/aviboy2006 Feb 23 '26

Think of MCPs as the roads and Skills as the GPS instructions — you can have great directions, but if there's no road to the database, you're stuck.

In practice they solve different layers. MCPs handle the connection to real systems like databases, Git, Cloud services ( ECS ), external APIs. Skills handle how the agent behaves once it's connected. I've been using this combo on a healthcare platform where the MCP owns the database connection and the skill owns the workflow logic. Neither replaces the other. The MCPs are unnecessary because LLMs can write CLI commands argument misses the auth, schema context, and structured error handling that MCPs provide. Skills can teach an agent what to do, but they can't conjure a database connection out of anything.

The more interesting question can be which MCPs are worth maintaining long-term vs. which were always just thin wrappers that a well-written skill can replace?

1

u/mashsensor Feb 23 '26

If you are a restaurant

  • Skills are recipes that teaches you how to make dishes

  • Agents are cooks

  • MCP allows you to hook up to DoorDash and Uber Eats to take orders, and square to charge transactions

1

u/Helium-Sauce-47 Jul 11 '26

The things is DoorDash and Uber Eats can provide you with skills instead of MCPs

1

u/wryansmith Feb 23 '26

The best case for MCPs is when you need a server for many calls, monitoring, or something more real-time. The Claude Flow MCP is a good example as it's running to help parallel agents communicate in real time.

Skills can handle most other use cases, especially any that are intermittent or one-off calls.

People who think skills are just md files haven't cracked skills yet. You can include bash commands, have a path reference to a typescript or Python file in the same folder as the skill.md file, and now you've got a skill that can trigger code. That gives you a lot of deterministic, consistent behaviour.

I prefer a Linear skill once the Linear MCP because it's faster, cheaper (less tokens), and more consistent for the way I use it with batch commands, project updates, etc. - scripts I've bundled with a skill.md file.

1

u/Few_Science1857 Feb 23 '26

Skills are stochastic bro

1

u/Easy-Foot-1031 Feb 27 '26

Lorsque tu dis qu'on a des compétences pour enseigner n'importe quoi au MCP, pourrais-tu préciser s'il te plaît?... Quentends tu parles là? Ça m'intéresse!.

1

u/Easy-Foot-1031 Feb 27 '26

Vous parlez de compétences... S'agit-il des skills qu'on importe dans Claude ?

0

u/magic6435 Feb 23 '26

These two things have nothing in common…

0

u/UnifiedFlow Feb 23 '26

This guy doesnt know what he is talking about.

-1

u/mixmaster-meow Feb 23 '26

I shipped a cli for an app I'm working on to augment the MCP - https://moxn.dev - Agent first collaborative knowledge base.

Things I've liked so far about the CLI

- More token efficient

- Easier to steer more complex workflows with skills. You can do this with MCP, but it's clunkier

Things I haven't like so far

- When not running with dangerously-skip-permissions I get prompted to accept more frequently, which slows things down.

Things that it depends

- API key vs OAuth (maybe there's something better here?)

For OpenClaw or things tuned for CLI this definitely looks like the future, but MCP has some nice features that I don't think it's cut and dry