MCP vs. Agent Skills: A Decision Framework for Context Engineering

A developer has clarified the distinction between Model Context Protocol (MCP) and AI Agent Skills (SKILL.md), explaining that MCP connects agents to live external systems while Skills encode repeatable procedures. The framework helps teams choose the right approach for extending agent capabilities.

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. Imagine hiring a new developer for your team: "How do I extend this agent?" │ ┌──────────────────┴──────────────────┐ │ │ Needs access to a Needs to follow a live external system repeatable procedure │ │ ▼ ▼ ┌───────────────┐ ┌───────────────────┐ │ MCP │ │ Agent Skills │ │ access badge │ │ the playbook │ └───────────────┘ └───────────────────┘ 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. 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: { "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. 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. 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 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, static knowledge : a procedure, a style guide, a checklist. None of it changes minute to minute, and none of it needs a live connection — it just needs to be taught once and reliably applied whenever the matching task comes up. MCP | Agent Skills | | |---|---|---| | Solves | Access to external systems and live data | Encoding repeatable procedures and expertise | | Analogy | Access badge / API connection | SOP / playbook | | Requires infrastructure | Yes — a running server, auth, network calls | No — just files in a repo or agent config | | Content type | Dynamic, changes in real time | Static, changes only when someone edits it | | 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 | 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: ┌───────────────────────────────────────────────────────┐ │ Support Agent │ │ │ │ Skill: "refund-policy" MCP: Stripe, Zendesk, │ │ how to decide, what to say order DB what's true │ │ │ │ │ │ └─────────────┬──────────────┘ │ │ ▼ │ │ Grounded, policy-correct │ │ refund decision │ └───────────────────────────────────────────────────────┘ 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. 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?