MCP vs. Agent Skills: What's the Difference and Which Do You Need?
As AI agents evolve beyond basic chat interfaces into fully autonomous systems, developers keep hitting the same architectural decision: how do we actually extend what an agent can do?
Two concepts dominate that conversation right now — Model Context Protocol (MCP) and AI Agent Skills (SKILL.md) — and they're routinely discussed as if they're competing options. They aren't. They solve two different problems that only look similar from a distance, and picking the wrong one for the job is one of the more common ways teams burn a sprint building an agent that's either disconnected from reality or has no idea what to do once it's connected.
Here's the actual distinction, how each one works under the hood, and a framework for knowing which one — or both — your next agent build actually needs.
The core concept: a badge versus a playbook
Imagine hiring a new developer for your team:
- MCP is the interface that lets them connect to your databases, Slack channels, GitHub repos, and cloud infrastructure. The actual access is whatever credential is behind that connection; MCP just standardizes how the agent calls it.
- AI Agent Skills are their Standard Operating Procedures. It's the playbook that tells them how your team formats code, writes pull requests, or triages production incidents. An interface without a playbook gets you a new hire who can technically reach every system but has no idea how your team actually wants things done — so they improvise, inconsistently, every time. A playbook without any system access gets you someone who knows exactly what to do but can't touch anything. Production-grade agents need both, and knowing which gap you're actually looking at is what keeps you from reaching for the wrong fix.
"How do I extend this agent?"
│
┌──────────────────┴──────────────────┐
│ │
Needs access to a Needs to follow a
live external system repeatable procedure
│ │
▼ ▼
┌───────────────┐ ┌───────────────────┐
│ MCP │ │ Agent Skills │
│ (interface) │ │ (the playbook) │
└───────────────┘ └───────────────────┘
What is MCP (Model Context Protocol)?
MCP is an open standard designed to standardize how LLMs connect to external tools, databases, and APIs.
Before MCP, connecting an agent to a system like Postgres or GitHub meant custom API integrations or a bespoke function-calling schema per provider. Every new tool meant a new adapter; every new model meant rewriting that adapter to match whatever shape that provider's function-calling API expected. MCP replaces that with a universal bridge: build the connection once, as an MCP server, and any MCP-compatible client can use it without provider-specific glue code.
How it works
MCP runs on a client-server architecture over JSON-RPC:
┌────────────┐ MCP (JSON-RPC) ┌──────────────────┐
│ AI Agent │ ◄──────────────────────────► │ MCP Server │
│ (client) │ │ (e.g. GitHub, │
│ │ │ Postgres, Slack)│
└────────────┘ └──────────────────┘
An MCP server exposes three primitives to any connected client:
- Resources — structured, read-only data the model can pull into context (a file, a database row, a ticket)
- Tools — functions the model can actually invoke, with side effects (create a PR, run a query, send a message)
- Prompts — reusable, parameterized prompt templates the server offers to the client A minimal client config for connecting an agent to a GitHub MCP server:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_TOKEN": "your_token_here"
}
}
}
}
Once connected, the agent can list open issues, read a file from a repo, or open a pull request — not because it memorized GitHub's REST API, but because the MCP server translated GitHub's API surface into a standard interface the agent already knows how to speak. Worth noting: the actual permission boundary here is GITHUB_TOKEN, not the MCP layer itself — MCP standardized the calling convention, and whatever that token is scoped to do is what the agent can do.
MCP is the right layer when the problem is access to live, changing state: current inventory counts, today's support tickets, a database that gets written to every minute. That data can't be baked into a prompt or a static file, because it's stale the moment you write it down.
What are AI Agent Skills?
If MCP is about connecting to systems, Skills are about encoding expertise. A Skill is a folder — typically a SKILL.md file plus optional scripts, templates, or reference documents — that teaches an agent how to perform a specific, repeatable task the way your team wants it done.
---
name: pr-review-checklist
description: Use when reviewing a pull request before approval. Covers this team's standards for tests, security, and rollback safety.
---
# PR Review Checklist
Before approving, verify:
1. Tests cover the new/changed logic, not just the happy path
2. No secrets or credentials in the diff
3. Migration steps are documented if the schema changed
4. There's a rollback plan if this touches a production data path
How it works: progressive disclosure
The architectural idea behind Skills is progressive disclosure. An agent doesn't load every Skill's full content into context at all times — that would burn tokens on procedures it isn't currently using.
Always in context: Loaded only on demand:
┌─────────────────────┐ ┌──────────────────────────┐
│ pr-review: description │ ───► │ Full SKILL.md body │
│ triage: description │ │ + bundled scripts/ │
│ formatting: description│ │ templates, only when │
└─────────────────────┘ │ the task actually matches│
└──────────────────────────┘
Only the name and description stay resident by default — a line or two each. When a task matches a Skill's description, the full body loads. If the Skill references bundled scripts, those load only when actually needed. That's what makes Skills cheap to accumulate: dozens of them can sit around — commit conventions, an incident-triage runbook, a data-visualization style guide — without a standing context-window tax for the ones not currently in use.
Skills are the right layer when the problem is repeatable procedure or expertise: a style guide, a checklist, a domain-specific workflow. A Skill that's pure prose is genuinely static — it only changes when someone edits it. A Skill that bundles a script or calls tools on the agent's behalf is executable code riding along with a markdown file, and it's worth reviewing with the same rigor as any other code change: ownership, version, and what permissions it actually exercises.
MCP vs. Skills: the key differences
| MCP | Agent Skills | |
|---|---|---|
| Solves | Access to external systems and live data | Encoding repeatable procedures and expertise |
| What it actually controls | The calling convention — permission comes from the credential behind it | The agent's behavior; bundled scripts mean real code execution |
| Requires infrastructure | Yes — a running server, auth, network calls | No — just files in a repo or agent config |
| Data/artifact freshness | The data fetched through it is live and dynamic | The Skill file itself is static prose, or executable if it bundles scripts |
| Context cost | Tool/resource schemas loaded as needed | Name + description only, until matched |
| Typical use case | Query a database, call an API, send a message | Follow a style guide, run a checklist, format output consistently |
| Portability | Tied to the system it connects to | A folder of files — copy it anywhere (though bundled scripts still carry their own assumptions) |
They aren't competitors — they work together
The most common mistake is treating this as either/or. In production, the strongest agents use both, for different halves of the same job.
Take a support agent handling refund requests:
- MCP servers give it live access to Stripe (the actual charge), Zendesk (the actual ticket), and the order database (actual fulfillment status).
- A Skill gives it your team's actual refund policy: which situations qualify for a full refund vs. store credit, what tone to use, when to escalate to a human instead of resolving automatically. Strip out the Skill and the agent has perfect system access but no policy — it improvises, inconsistently, every time. Strip out MCP and it knows the policy perfectly but can't verify whether the charge even went through. And when both are wired together, it's worth making sure the Skill's conclusion doesn't directly trigger the MCP write with no review step in between — the policy decision and the action it authorizes are worth keeping separately inspectable.
┌───────────────────────────────────────────────────────┐
│ Support Agent │
│ │
│ Skill: "refund-policy" MCP: Stripe, Zendesk, │
│ (how to decide, what to say) order DB (what's true) │
│ │ │ │
│ └──────────────┬───────────────┘ │
│ ▼ │
│ Grounded, policy-correct refund decision │
└───────────────────────────────────────────────────────┘
A decision framework: which do you actually need?
Does this task need information or actions from a live, external system? A database that changes, an API that has to be called, a message that has to be sent — that's MCP territory.
Does this task need to be done the same specific way every time, based on knowledge that doesn't come from an external system? A formatting convention, a checklist, a domain-specific procedure — that's a Skill.
Does it need both? Most real production agents do. Answering system access and procedural knowledge as two separate questions is what keeps the architecture clean instead of cramming everything into one oversized prompt.
Key Takeaways
- MCP standardizes the calling convention, not permissions — the actual access boundary is the credential behind the MCP server, not the protocol itself.
- Agent Skills standardize knowledge — they package repeatable procedures into files an agent loads only when relevant, via progressive disclosure. Pure-prose Skills are static; Skills that bundle scripts are executable code and worth reviewing as such.
- MCP requires running infrastructure (a server, auth, a network connection); Skills are just files — no infrastructure required, and portable, though a bundled script's assumptions travel with it.
- The two solve different halves of the same problem: the strongest production agents combine both, Skills for the "how," MCP for "what's actually true right now."
- The fastest way to pick correctly: ask whether the task needs live external state (MCP), repeatable procedure (Skills), or both — most real agents need both.
Closing CTA
If you're building an agent right now, take an honest inventory of what it's actually missing: is it fumbling because it can't reach a system it needs, or because it can reach everything but has no consistent playbook for what to do once it's there? Those are two different fixes, and reaching for the wrong one is the fastest way to burn a sprint on the wrong problem. What's your agent stack missing — access, procedure, or both?
Top comments (2)
The access/playbook split is useful, with one security nuance: MCP is the connection and capability-description layer, not the access badge by itself. The effective permission is the intersection of the server's exposed tools, the credential/identity presented at runtime, database or API policy, tenant context, and any client approval gate. A beautifully narrow MCP schema backed by an admin token is still an admin boundary.
Skills also aren't necessarily “just static knowledge.” A skill can bundle scripts and instruct the agent to invoke tools, so it belongs in the same supply-chain review as code: owner, version/digest, provenance, declared permissions, test fixtures, and change approval. Copying a skill folder makes it portable; it does not make its assumptions portable.
For the combined refund example, I'd bind policy version + normalized evidence + proposed action into a decision record before the write. Then the approval and idempotency key apply to that exact payload. That keeps the skill's procedural guidance, MCP-fetched facts, authorization decision, and eventual side effect independently reviewable instead of letting “the playbook says yes” become mutation authority.
Thanks Hansen for your input. A miss from my side. Have made appropriate changes.