MCP has a MUCH BIGGER scope than Skills

I was recently a guest on Apollo's "The MCP 2026 Forecast" livestream. We zoomed in on a subtle but important distinction: AI Agent Skills and the Model Context Protocol (MCP) are related, but they are not competing tools solving the same problem. Much of the "which is better?" debate comes from people comparing different use cases.

This post is my response to recent conversations on 𝕏 (including Aiden Bai, Nathan Flurry, David Cramer, and Camsoft) and longer-form takes like David Cramer's "MCP, Skills, and Agents" and Philipp Schmid's "MCP is Not the Problem, It's your Server". The through-line is the same: we're often arguing past each other.

The mismatch that fuels the debate

In the livestream, I pointed out a recurring pattern: people are talking about different scopes. Some developers love Skills because they are perfect for one-off tasks and personal workflows. If your goal is to automate something in your daily routine, a Skill can be the quickest and most approachable solution. In that context, MCP can feel like overkill.

Camsoft put it bluntly: "Stop Treating Skills and MCPs as Competing Ideas." I agree. Saying "MCPs are bad, Skills are all you need" is a category error, and it misses the very real overlap and tradeoffs in both directions (Camsoft).

But I'm thinking about a bigger canvas: consumer and enterprise ecosystems where multiple services need to integrate, and where you want an agent to operate across those systems without bespoke integration work every time. When you compare those two perspectives, it's easy to conclude that one tool is "better" when in reality they're aimed at different jobs.

Skills as a friendly on-ramp

My most important point is that Skills are not in competition with MCP, they're complementary. Skills can be a low-friction way to encode domain knowledge and workflows, especially for people (and agents) who don't already have that domain knowledge. They can also provide an orchestration layer on top of MCP servers, specifying the order of operations or the "business recipe" for getting a job done.

This is why Skills can feel empowering even in a world where MCP exists. A Skill can say, "When I need to do X, call this MCP server, then that one, then combine the results." Or Skills can completely ignore MCP and tell the agent to simply cURL the API directly or use a CLI tool (though things get hairy with auth and distribution). Skills package institutional knowledge in a way that's immediately useful. That overlaps a bit with what an MCP server could do, but the primary use case is different: Skills focus on workflow; MCP focuses on interoperability.

David Cramer captures this well by describing Skills as reusable prompts with progressive disclosure. The metadata is tiny, and the full instructions are only loaded when relevant. That makes Skills great for encapsulating a repeatable workflow or a team convention, especially when you want to keep context usage light (cra.mr).

I want to note here that MCP is absolutely capable of progressive disclosure, but I have yet to see an agent which does this though I believe it's coming.

David's post captures a pragmatic angle here: there's huge value in making these workflows feel human-first and low-friction. Whether that orchestration lives in a Skill or in a custom integration, the point is that people need a simple mental model for how agents should behave. MCP doesn't replace that; it gives you reliable building blocks to plug into it.

Camsoft also highlights the hidden costs of Skills at scale: a flood of overlapping Skills from unknown sources, non-deterministic selection between similar Skills, and giant prompt files that dump context unnecessarily. On top of that, Skills can be a maintenance burden, fragmented across clients with inconsistent installation and versioning. Those are real drawbacks to plan for, not reasons to dismiss the approach (Camsoft).

I'm not saying those problems are fundamentally unsolveable, but rather that Skills have early days problems just like MCP servers do (and as usual, it's often the implementation of the Skill/MCP server that's the problem, not the protocol/pattern itself). So these things will improve.

MCP's strength: service exposure and integration

Where MCP shines is at the boundary between services and agents. I describe it as a way to take an existing service and expose it so any agent or user can use it. This is the difference between "here's a product, install this SDK and follow these steps" and "here's a URL, your agent can just use it."

In the live stream, I use a business analogy: if you sell a product, you don't want to tell customers to copy files or configure a bunch of local settings. You want the path of least resistance. MCP offers that by making services discoverable and consistent. Over time, the expectation becomes: "I can ask my general-purpose agent to use Expedia," and the service just works without bespoke integration steps.

Philipp Schmid summarizes the design shift with a line I keep coming back to: "MCP is a User Interface for AI agents" (philschmid.de). The protocol isn't the problem; the servers are. Good servers optimize for outcomes, not raw operations: fewer tools, flatter arguments, better instructions, and curated responses. That makes the agent faster, more reliable, and far less likely to hallucinate.

This is a structural shift. It reframes services from "things you integrate manually" into "things that are interoperable by default." That is the core value proposition of MCP, and it's something Skills don't directly solve. Skills can explain how to use a service; MCP makes it possible to use the service everywhere.

There's also a lifecycle advantage: MCP servers are installable, versionable, and long-lived. They're stateful processes that can handle auth, permissions, and even closed-source integrations. Skills are often plain text and copied around, which makes distribution and upgrades harder in practice.

Longevity and limits

My view is that Skills will stick around, but their impact is narrower. They are great for capturing workflows, internal processes, or personal automation. But MCP creates a foundation for cross-service interoperability. That foundation is bigger in scope and more durable in the long run.

This is also where some of the 𝕏 conversations land: people ask whether Skills are "enough." The answer is: enough for what? For a personal workflow, probably yes. For a world where services are inherently accessible to any agent without setup, no. That's the long game MCP is aiming for. Or, as Cramer puts it in another framing, "RIP MCP. Long live skills!" is a fun headline, but it doesn't match how these pieces actually fit together (cra.mr).

A better way to frame the discussion

Instead of "Skills vs. MCP," think "Skills and MCP." Use Skills to capture domain knowledge and workflows. Use MCP to make services accessible to any agent, in any context, without bespoke integration steps. If you're building for individuals or internal teams, you might lean on Skills. If you're building a service meant to be used by anyone's agent, MCP is the platform-level move.

The debate gets simpler when you state the goal first. Are you automating a personal task? Or are you enabling interoperability at scale? Once you answer that, the tool choice usually becomes obvious.

If you're interested in the broader vision, check out the livestream for the more context: "The MCP 2026 Forecast". And if you're following the ongoing conversation, the posts from Aiden, Nathan, and David are worth reading as snapshots of the questions people are asking right now.

So I wanted to give my two cents on the MCP versus skills debate that's been going on. So first of all, just so we're all talking about the same thing, skills are these markdown files that you typically as a developer you put in your project with the skills.md and it's just going to describe how to do a particular thing almost like you are talking to an actual person explaining a workflow or explaining a domain so that the agent can then take that knowledge and apply it to whatever task you're asking it to do. MCP is about service interoperability. So you have a service. You're going to build an MCP server that allows an agent to make tool calls, to perform those mutations, or to retrieve data, or whatever.

And there is some overlap because you can have a skill that says hit this URL to get this updated information or whatever. But there's some really critical problems with skills or limitations with skills and with MCP granted that make these things not so competitive but actually more complementary. And For me, actually, the primary reason for the debate is because we have different scopes and different use cases that we're thinking about when we're talking about MCP versus skills. So with skills, it's really focused on developers, productivity. You could definitely use skills, and there are agents for using skills for non-developer related tasks, but primarily the user experience of installing them and everything just kind of caters more toward the developer use case.

Whereas MCP, most or many developers only are narrowed in or thinking about the developer use cases, like connecting to your context seven thing so you can get the latest documentation or getting information from GitHub or whatever. And you're thinking, well, there's a GitHub CLI. Why can't we just use that instead, have a skill that tells it what to use from the GitHub CLI, or the models trained on the GitHub CLI, whatever. And so if you're just focused on the developer use cases, you look at MCP and you're like, this is way too complicated. It's not all that useful.

But even in the developer realm, there's a lot of things that MCP can do that you can't get from just a CLI or you can't get just from a skill. And this is kind of what I wanna talk about. So first, like let's talk about skills, strengths. They're low friction, really, really easy. You can just write one up really quick and easy.

You even have an agent make one for you. And it's, there's progressive disclosure. Most agents are going to be able to look at, oh, there's a skill for that. I don't need that. So I'm gonna move on to this next one and it doesn't pollute the context window.

It's really good for team workflows because you're right in Git and everything. And so you can commit it right to the repo. But there are a couple of problems with this and maintaining it over time, especially if you're borrowing skills from somebody else and copying them into your project, they're not versioned. So how do you get that? And also a lot of the skills that I have seen are actually really big.

So there is still a problem with context bloat. And so, okay, now we got to split them up. Seems like a maintenance nightmare, not very fun. And so, and then on top of that, like distribution issues. Are we gonna have like a CLI?

Oh my goodness, we actually do have a CLI for adding and doing skills. That's not necessarily a bad thing. There are problems with early things and I don't see these problems as being foundational. So I think that skills are still really useful. They don't have to be perfect right now to be useful.

And I think that lots of those problems will go away. On the MCP side of things though, there's some really, really nice things that you get from MCP that you're not going to get from skills. So for one, they're installable, whether that's using the NPM or NPX or whatever to install it locally on your machine, to run it locally, like you would with the Sentry. Well, actually, no, the Sentry one is hosted on HTTP, like you might do with a Context7, as an example, or if it's hosted. So Sentry is hosted.

And then I've got my Epic Workshop, which is a local one. So that distribution model is already kind of solved because it's kind of writing on the back of existing protocols, whether that be installing it from a registry or just using a URL. And with that comes versioning. So if you're putting it up on the web, everybody's gonna get the latest version all the time. You could even version that if you wanted to.

If you're publishing that to NPM, like there's an existing versioning mechanism for that. The other thing that this has way beyond what a skill can do is authentication. So if you want to do authentication with GitHub, then yeah, OK, you can have the GitHub CLI. You can have it logged in. And everything is just fine.

But if you want to have something that's distributed across different users' machines or something and allow them all to be authenticated to their own thing, there's a lot of setup that they have to do to get to that process. And every single service that you want to integrate has to have its own bespoke mechanism for doing authentication. Having a standard authentication mechanism means that you just set yours up to do that, and then all the agents know exactly what to do when it says, oh, it's not authenticated. Let me take you through the OAuth flow. And that's really powerful.

And of course, beyond that, now you don't have to worry about having tokens on the local machine that are going to be stolen or whatever. It's all just using OOP. Additionally, if you have a really good, well-written MCP server, then those tools can be really outcome focused and that's what makes the MCP servers really good. So then on the other side of things, like a lot of the problems that people have with MCP are just because the MCP server implementation is bad. And that is something that we're working on in general.

And we have the same problem with skills. You can have skills implementations that are also really bad. The nice thing is that a bad skill implementation is actually relatively easy to fix. Like, you can test it out locally, run it yourself, and just test things out and make sure that things are good. We're still trying to figure out what makes a really good server implementation.

I've seen some really, really good ones. The Sentry server implementation is open source, and it's super good. So that would be a good one to look at. There are a bunch of others. So anyway, my take is that you should use both.

You pick the good one or the goods from each one of these things and combine them in interesting ways. You can have a skill that says, use the Sentry MCP server to get information on the issue and associate that to the GitHub issue or whatever with the GitHub CLI. And then you go and implement it. And if you need to look up documentation, use the Context 7 server or whatever. So all of these things can kind of be intermixed.

I think that this is, in both cases, these things are going nowhere. We're going to always have skills. We're going to have MCP servers for the foreseeable future. So it's worth getting good at both of them. But don't write off MCP servers because it's for just so much more than just software development.

It is, in my mind, it's even more important for the consumer side of things. And we're seeing some really exciting advancements in this space, in particular within ChatGPT and Cloud. And I think that in the very near future, we're going to have some really interesting use cases that is really only supported by MCP. For example, you're not going to get a user to install a CLI on their phone so that your agent can use that CLI. MCP is really, really good for solving that particular problem.