Skills in MCP
Skills are in and MCP is out. At least, that's what you'd believe if you spent some time scrolling LinkedIn or Twitter in recent months. We create and consume Skills every day in the development of BoltMCP, and they're awesome. Skills are portable and they provide immediate value to agents, without sacrificing tokens upfront.
Read the previous blog to understand what makes Skills good.
Many have interpreted the popularity of Skills as a eulogy for MCP, and proof that developers wanted something different all along. "Simple markdown files beat over-engineered protocols". It's easy to understand the disillusionment with MCP. It was hyped as transformational, and the day-to-day reality for most hasn't matched. Why is that?
The problem with MCP
Almost every criticism of MCP we've seen in the Skills vs MCP debate boils down to these two points, and we agree with them wholeheartedly:
- Most MCP server implementations in the wild pre-load too many tools into context, don't make use of static context and don't follow best auth practices
- The MCP client ecosystem is still immature, with most clients not yet supporting basic features from the protocol
But these are implementation problems, not fundamental protocol problems. The flak MCP is getting is largely based on misconceptions about what it is, most prevalently that MCP = pre-loading many tools into context.
Pitching Skills against MCP is like pitching recipes against kitchens
If Skills are recipes, developers are currently reaping the rewards of investing in good home recipes. And because of their portability, there's been an explosion in the sharing of those recipes online.
That portability is useful, but requiring Skills to live as physical files on the same machine as your agent limits their potential. Here's a secret: they don't have to. I'm not speaking hypothetically, I'm talking about now. You can serve Skills through MCP on a remote server with auth controls. Don't believe me? Here's a demo:
When to keep Skills in local files
Often it makes sense to keep Skills as local files and that's great - it's nice to cook for one on a camping stove occasionally (don't worry, I'm abandoning this analogy now). My rule of thumb is to keep Skills locally if both of these are true:
- The Skill was written by you or someone you trust and doesn't contain sensitive company data
- The Skill is only relevant to one or two file-based projects on your machine
For developers working with coding agents, these are often true. It can be super useful to author custom Skills for your repositories, instructing agents how to interact with particular parts of the codebase. These kinds of Skills naturally live in the respository itself as files, just like the rest of your documentation and code.
But if the same Skill starts getting used across many projects, or if the Skill contains sensitive data, it could be better off hosted remotely.
Why serve Skills over MCP?
Traditional Skills are just files on the same machine as the agent. Drop them into the agent's Skills folder and the agent will happily ingest any of the contents. As one engineering manager recently put it to me, using a third party Skill is effectively prompt injecting yourself. So far, the only people really using Skills at scale are software developers, who should be aware of the risks. They're comfortabe authoring markdown files and downloading things from the command line. But the potential for Skills is so much bigger than that. We're just scratching the surface of where Skills will be useful.
Access control
Some Skills will contain sensitive company data, and you don't want that living on every employee's laptop alongside their agents. You probably don't want it stored in git. Different Skills should be curated for different roles. Maybe some Skills will be shared across roles, but contain content customized according to the identity of the user/agent.
Oversight & Observability
As Skills become more prevalent throughout your organization, you'll want company-wide oversight over what content is being exposed to your agents. Maybe you'll want to scan them for vulnerabilites like prompt-injection. Finally, you'll want to keep track of how Skill content is being consumed by your agents, with observability and tracing built in.
On-prem MCP running over HTTP allows us to do all these things and more.
Skills aren't opposed to MCP, the two are complimentary. Skills are folders of files + a pattern of disclosing context to agents. By implementing them in MCP we get an efficient way to disclose context to our agents, as well as oversight and access control applied to that context.