MCP is dead or MCP vs Skills — revisited
TL’DR: MCP got supporting important things right and skills got wrong.
Finally explained to myself why the “MCP is dead, skills killed it” talk is probably wrong. Mostly from tinkering with making skills work in claude.ai web interface for non dev users.
This post is about what I believe MCP got right, what skills do better, and why I think in the future we’ll see (at least some) convergence.
MCP is bloated, too many MCP connected, and there goes your context, full of endless tokens describing tools you might never need. This part is right, and yes, it’s a big problem.
It’s not inherent in the protocol, but most MCP implementations today eagerly inject full tool schemas, which can bloat context.
Skills got that part right. The models get only a thin description and some metadata coded in the frontmatter YAML, and a “progressive disclosure” discovery by referenced files (that can reference more files)
I believe the “bloated MCP” issue is a solvable problem. A different schema, that allows “tool discovery” separate from full “all tools detailed params” and the ability to lazy load on demand those tools isn’t rocket science. (It might mean a change in the spec, but again, not a heavy lift, and a lot of it is doable by today’s spec). Some agents already have their own version of MCP lazy loading implemented (probably not good enough, as long as they need to deal with a monolithic JSON, but..).
What MCP got right
But MCP got something important right, and that’s AUTH. the protocol has auth, especially OAuth baked into it, which means we don’t need to support “always fresh tokens”, we don’t need to provide single api token that can do anything — but we let it use the user’s own Oauth to a service (e.g SAAS service such as Jira, Monday, Github, Atlas, etc) , via their own login screens and security and automatically get a token with the users specific credentials for the specific service.
Get Alon Nisser’s stories in your inbox
Join Medium for free to get updates from this writer.
Skills, on the other hand, just don’t have a built-in way to do that. A lot of skills I see require some “global” api key to work, which renders it almost impractical in enterprise setups for non-developers, environments where there is no way you can provide those. You can’t even provide “envs” with secrets in Chatgpt/Claude.ai regular web interfaces if you use a skill there. Some tools work around this limitation by wrapping their own CLI tool, which in turn handles authentication, ideally via OAuth. This works for local dev tooling, but again, not for skills being used through web interfaces. with MCP connection, this works out of the box, as long as the MCP provider supports this.
How to vs Autonomous discovery
Another important distinction is explaining how to use the tools. A common shortfall of models using MCP is that they need to “learn” each time how to use the myriad of tools provided by multiple MCP servers. Sometimes I laugh myself to tears watching a model trying to use MCP tools, a monkey randomly trying stuff until it succeeds in getting something that looks plausible enough.
Skills do the explanation — “this is the flow you need to follow, step by step”, those are the tools, this is how it’s all connected.
And that’s probably better, until you need to scale this into “lots” of different tools that you’re supposed to use in lots of different scenarios. where what you really want is the agents figuring out what and how to use, and we won’t be able to provide detailed specs and runbooks for every scenario. Not only that, as everyone of us who ever wrote technical documentation knows, docs are already dead and deprecated as they hit the door. and skills are mostly just “yet another variant” of technical docs with all their pain. I believe the models/harnesses are getting better at this, and eventually, as we scale and as models get better, it might just work. Maybe self-discovery of the right “patterns” scales better and was the right way, just too soon?
Where we’re going
Currently, I see “skills” accompanying “MCP” — explaining the “patterns” and providing the “know-how”. I also see teams that don’t bother providing a good MCP, “as it’s bloated anyway” instead of fixing it with the limitation of “just point the model at the API”.
So where are we going with this? My current guess is that we’ll eventually see some convergence. We’ll see real “just in time” nested lazy loading for tools, and a way to provide the runbooks and important patterns. We might also see OAuth support being added to skills more natively, albeit not sure how that works with “it’s just markdown” approach (I guess it would be a combination of frontmatter field and a standard way to save token locally). The more we’ll want to move skill usage from local to sandboxed cloud environment, some of the challenges of MCP would also need to be solved for skills.
I’m sure this space is really getting interesting.
