A team I was advising had built themselves a beautiful MCP server for their internal deploy tooling, then started asking me why their agent kept doing code review inconsistently — sometimes checking for SQL injection, sometimes not, depending on what mood the model seemed to be in that session. They didn't need another tool. There was nothing external to connect to; the agent already had a shell and could already read a diff. What they needed was a documented, repeatable procedure the agent would reliably follow, and no MCP server on earth was going to give them that. That's the conversation that made the line between these two things click for me, and it's worth drawing precisely, because I keep seeing teams reach for one when they need the other.
I've written about building production MCP servers in depth already, so I'm not re-deriving the protocol here — go there for transports, OAuth, and the primitives. This piece is about something narrower and, I think, more useful in mid-2026: MCP and Anthropic's Agent Skills get lumped together in conversation as "ways to extend an agent," but they answer different questions, and conflating them leads to genuinely bad architecture decisions.
What is MCP, in one paragraph?
The Model Context Protocol is an open specification for connecting an agent to external tools, data, and systems over a standard interface — a Jira instance, a data warehouse, a ticketing system, a filesystem on another machine. An MCP server is a separate running process with its own runtime, its own filesystem access, and its own credential scope; the agent talks to it over a defined transport (stdio locally, streamable HTTP remotely) and the server exposes tools, resources, and prompts the agent can use. Practically, once an agent connects to an MCP server, that server's tool definitions sit in the agent's context for the rest of the session — the model sees them on every single turn, whether or not that turn needs them. MCP is the agent's interface to things it has no other way to reach.
What is an Agent Skill?
A Skill is a folder — a `SKILL.md` file plus, optionally, bundled reference docs and executable scripts — that teaches an agent how to perform a specific, repeatable task well. Anthropic introduced the concept in 2025 and opened the format as a standard in December of that year; by mid-2026 several other coding-agent CLIs read the same `SKILL.md` shape, which is a reasonable sign it's converging into a real convention rather than a one-vendor gimmick. A Skill isn't a connection to anything. It's closer to a procedural playbook: "here's how we do database migrations here," "here's our code review checklist," "here's the exact sequence for cutting a release." The agent could, in principle, already do most of what a Skill describes — read files, run commands, reason about a diff — it just does it inconsistently without one written down.
The architectural idea that actually matters is progressive disclosure. A Skill's full instructions do not sit in context the way an MCP tool schema does. What's resident at all times is just the skill's name and a short description — enough for the model to recognize "this task matches a skill I have" — and only when the agent decides to invoke that skill does the `SKILL.md` body actually load into context. If the skill needs more depth than fits comfortably in one file, it can point to additional reference files that load only when that specific sub-path is needed. The bulk of the content is there, on disk, the whole time; it just doesn't cost you anything in context budget until the moment it's actually relevant.
graph TD
subgraph MCP["MCP: always resident"]
M1["Connect to server"] --> M2["All tool schemas load
into context immediately"]
M2 --> M3["Every turn carries
every tool's schema
whether needed or not"]
end
subgraph SKILLS["Agent Skills: progressive disclosure"]
S1["Skill folder exists on disk"] --> S2["Only name + short description
resident in context"]
S2 -->|"task matches description"| S3["Full SKILL.md body
loads on demand"]
S3 -->|"if needed"| S4["Bundled reference files
load only when that
sub-path is hit"]
end
MCP tool schemas are a fixed tax paid on every single turn once you're connected, regardless of relevance. A Skill library is closer to an index: cheap to hold a hundred entries of, expensive only for the one you actually open.
Why does progressive disclosure actually matter for cost and reliability?
It changes the economics of having a large library of specialized capabilities. Connect an agent to fifteen MCP servers each exposing a dozen tools, and you've put roughly 180 tool schemas in front of the model on every turn, whether the current task touches one of them or none. That's real token cost paid every single call, and past a certain tool count it also degrades tool selection quality — the model has more plausible-looking options to choose wrong between. I've seen agents start mis-selecting tools purely because the surface got too wide, not because any individual tool was badly designed.
A hundred Skills sitting in a library cost you almost nothing until one gets invoked, because the only thing resident is the short description used for matching. This is the genuinely different value proposition: MCP tool count is a standing tax, Skill count is closer to free until used. If your agent needs occasional access to forty different specialized procedures — one for security review, one for database migrations, one for writing release notes, one for a particular customer's API quirks — packaging those as Skills instead of stuffing all forty sets of instructions into a system prompt (or exposing forty MCP tools that don't actually need live connections) is the difference between a context window that's usable and one that's mostly overhead before the task even starts.
Is a Skill's bundled script as safe as an MCP server?
No, and this is the part people gloss over. An MCP server can run as a genuinely separate, sandboxed process with credentials scoped narrowly to what that server needs — a read-only database role, a ticketing API token with no delete permission, nothing else the agent's own execution environment can reach. That's a real isolation boundary: even a fully compromised or badly-prompted agent session can't do more through that server than the server's own scoped credentials allow.
A Skill's bundled script has no equivalent boundary by default. It typically executes with whatever permissions the agent's own harness already has, in the same environment the rest of the session runs in. If your harness gives the agent broad filesystem and shell access, a Skill's script inherits that same broad access — it isn't a separate security perimeter, it's more instructions running inside the perimeter that already exists. That's not necessarily a problem; it's just a different trust model, and worth naming precisely instead of assuming a Skill gets the same sandboxing story as an MCP server for free. If a Skill needs to reach a genuinely external, credential-bearing system, the honest pattern is for its script to call an MCP tool to do that — the Skill supplies the "how," the MCP connection supplies the scoped "reach."
| Dimension | MCP | Agent Skills |
|---|---|---|
| What it is | Live connection to an external system | Packaged instructions for a repeatable task |
| Context footprint | Always resident once connected (every tool schema, every turn) | Progressive disclosure — only name/description resident, full body loads on demand |
| Runtime | Separate process, own runtime and filesystem | Runs inside the agent's own harness/environment |
| Credential model | Independently scoped credentials, real isolation boundary | Inherits the harness's existing permissions — not a separate boundary |
| Standardization | Formal open spec, broad multi-vendor server ecosystem | Newer open format (opened Dec 2025), conventions still settling |
| Typical use case | Reach a system the agent has no other way to touch | Do a task the agent can already technically do, consistently and well |
| Cost of a large library | Grows every turn's context linearly with tool count | Grows disk usage; context cost stays near-flat |
Are MCP and Skills actually complementary, or competing?
Complementary — they're not answers to the same question. A Skill structures the agent's reasoning: what steps to take, in what order, what to check before declaring a task done, what the team's actual conventions are that no amount of general training data would encode correctly. An MCP tool is what gets called to execute a step of that plan against a real external system. A "cut a release" Skill might walk the agent through version bumping, changelog conventions, and a pre-flight checklist — and one step of that checklist might call an MCP tool to actually open the pull request against your git host. The Skill is the playbook; the MCP tool is the hand reaching out to touch the world. Neither replaces the other, and I'd be skeptical of a framework that tried to force one to do the other's job — an MCP server that tries to embed a full procedural playbook in a tool description will bloat every turn's context with instructions most turns don't need, exactly the problem progressive disclosure exists to solve.
This is also, worth saying plainly, the Skills counterpoint to the tool-schema-design discussion in my agent harness piece — I wrote there that a tool's description is a prompt whether you think of it that way or not, and that's still true for MCP tools sitting in context on every turn. Skills sidestep that specific cost for anything that isn't a live external action, at the price of a less mature ecosystem and no independent sandboxing story.
Where is the Skills ecosystem still immature, honestly?
MCP has a formal specification, a broad ecosystem of servers across categories most teams need, and enough production mileage by mid-2026 that the rough edges are mostly known and documented. Agent Skills are younger — the open format only shipped in December 2025 — and while adoption spread quickly across several major coding-agent CLIs, the conventions around versioning, discovery, testing, and sharing Skills across an organization are still settling. A team standardizing on Skills today for anything beyond an individual's or small team's personal workflow library is making a bet on a pattern that's real and useful right now but less battle-tested than MCP's more established spec. That's not a reason to avoid it — the progressive-disclosure win is genuine — but it's a different risk profile than adopting MCP, and worth stating rather than assuming away.
Don't reach for a Skill to paper over a capability gap. If the agent genuinely cannot reach a system — no filesystem access to it, no API path, no credentials — no amount of well-written procedural instruction fixes that. A Skill can tell the agent exactly how you want a database migration reviewed; it cannot give the agent a database connection it doesn't have. That's what MCP is for. Teams that try to solve a missing-connection problem by writing a very detailed Skill end up with an agent that confidently describes the right steps and then fails, or worse, fabricates a plausible-sounding result, at the one step that needed real external access.
So which one do you actually reach for?
Use MCP when the agent needs to touch a live external system it doesn't otherwise have a path to — a production database, a SaaS API, an internal service with its own auth. That's a capability the agent structurally lacks without a connection, and MCP is the standard way to grant exactly that connection with credentials scoped to what's actually needed.
Use Skills when the agent already has the raw capability — it can read files, run commands, call the tools it has — but does the task inconsistently or incorrectly without a documented procedure, especially when you have many such tasks and context budget is a real constraint. Code review conventions, release procedures, a specific team's testing checklist, how to write a commit message that passes your org's linter — these are knowledge problems, not connectivity problems, and Skills are built for exactly that shape of problem at a cost that scales with how much of your library actually gets used, not how much of it exists.
Most agent deployments I've seen do best with both: a modest, well-scoped set of MCP connections for the systems the agent genuinely needs to reach, and a growing library of Skills for the procedures that make it competent and consistent once it's there. Neither one is the "advanced" or "future" choice over the other — they're just solving different halves of the same problem, and a mature agent setup by late 2026 usually has both stacked, not one instead of the other.
What to carry away
MCP is the agent's interface to the outside world: a live, sandboxable, credential-scoped connection whose tool schemas sit in context continuously once established. Agent Skills are the agent's internal procedural knowledge: a static bundle of instructions and optional scripts, loaded lazily via progressive disclosure, with no independent security boundary of its own — it runs inside whatever permissions the harness already grants. Reach for MCP when the limitation is reach; reach for Skills when the limitation is consistency. And if you're evaluating a Skill's bundled script the way you'd evaluate an MCP server's credential scope, stop — they're not the same kind of boundary, and treating them as equivalent is the mistake that bites teams six months in.