When people compare MCP and Agent Skills, the conversation usually turns into a feature table. Which one supports tools? Prompts? Progressive disclosure? But that framing misses the point. The real story is evolutionary: how our approach to empowering AI agents is shifting — from software engineering to context engineering — and why both MCP and Skills are waypoints on that journey.
The Overlap Is Real
Let's get the obvious out of the way: MCP and Skills overlap. Every MCP tool could be packaged as a skill. An MCP server that exposes a search_code tool is, in effect, giving the agent a new capability — exactly what a skill does. Look closer and MCP's prompts resemble skill instructions, its resources resemble skill-bundled context.
So why do both exist?
Because they come from fundamentally different worldviews.
MCP Belongs to Software Engineering
MCP is the first AI protocol to go truly viral. It has SDKs in TypeScript, Python, Java, Kotlin, C#, and more. Its architecture — client/server, JSON-RPC, capability negotiation — is instantly recognizable to any backend engineer. And that's precisely the point.
MCP didn't invent its underlying transport paradigms. It shipped existing concepts from software engineering into the AI era: service discovery, schema-based tool invocation, resource endpoints, protocol versioning. It's a USB-C port for AI — standardized, universal, familiar.
MCP's power comes from meeting developers where they are. You already know how to build a server. You already know JSON-RPC. MCP makes it trivially easy to expose your existing systems to any AI agent.
Skill Belongs to Context Engineering
Skills operate at a different layer entirely. Yes, a skill can bundle tools (including MCP tools). But a skill's core contribution isn't about enabling new capabilities — it's about encoding domain expertise.
A skill can say: "When reviewing a PR, check security first, then test coverage, then style — and here's how to weigh each." That's not a tool. That's a workflow. That's judgment. That's the kind of thing a senior engineer would explain to a junior on their first week.
Skills bundle:
- Domain expertise: specialized knowledge about how to approach a problem.
- Repeatable workflows: multi-step procedures that should be consistent every time.
- Interoperability: the same skill works across Claude Code, OpenCode, Gemini CLI, and dozens of other agents.
This is context engineering — an AI-native approach to empowering agents. Instead of giving the model more functions to call, you give it more understanding of what to do and why.
"But Progressive Disclosure!"
Many articles highlight progressive disclosure as the killer feature that separates Skills from MCP. And yes, it's valuable — skills can reveal instructions incrementally, keeping the agent's context window lean.
But is progressive disclosure impossible in MCP? I don't think so. Nothing in the MCP spec prevents it — and I believe the spec could be improved to support it natively. Imagine a tool description that exposes a summary by default and a detailed instruction set on demand, or a resource that layers context based on the agent's current task. The mechanism isn't exclusive to the skill format; MCP just hasn't prioritized it yet.
What is exclusive is the design intent. Skills were designed from the ground up to feed context to language models. Every decision — the markdown structure, the load-on-demand pattern, the instruction layering — assumes the consumer is an LLM. Progressive disclosure is just one expression of that intent. MCP was designed for software interoperability; context efficiency is a secondary concern.
And yes, skills are "just" markdown files. That's the point. A skill is dramatically easier to create than an MCP server — no SDK, no deployment pipeline, no running process. You write prose, not code. The format's power comes from standardization and portability, not from runtime magic.
The Evolution Path
Here's the arc that matters:
| Era | Capability | Paradigm |
|---|---|---|
| 2022 | ChatGPT launches — the chat works | Prompt engineering |
| 2023 | Function calling | Software engineering |
| 2024 | MCP goes viral | Software engineering (standardized) |
| 2025 | Agent Skills emerge | Context engineering |
| 2026 | MCP Apps bring UI to agents | Protocol-level UI + context-level intelligence |
The direction is clear: the evolution path is shifting from software engineering to context engineering.
Why? Because the models are getting bigger and better. Less hallucination. Better instruction following. More stable structured output.
This shifts the value equation. When GPT-3.5 could barely parse a JSON schema, function calls were revolutionary. Now that Claude and GPT can absorb pages of nuanced instructions and execute multi-step workflows reliably, giving them richer context becomes more valuable than giving them more tools.
And crucially, the model providers are leading this trend in advance. Anthropic developed the Agent Skills format and trains Claude to follow skill instructions natively — the format and the model co-evolve. You don't ship a context-engineering standard without first ensuring your model can handle it.
MCP Is Not Standing Still
MCP isn't standing still either. MCP Apps is a fascinating development — it extends the protocol to deliver interactive UIs (charts, forms, dashboards) inline in the conversation, with bidirectional communication between the agent and the UI.
The telling detail: MCP Apps ships with four Agent Skills — create-mcp-app, migrate-oai-app, add-app-to-server, and convert-web-app. The recommended way to build an MCP App is to install these skills and let your coding agent do the work. MCP and Skills aren't enemies — they're converging.
MCP has a massive head start in adoption — that's precisely why this embrace of skills matters. MCP Apps is the steamer ticket for adherents of a former dynasty to board the new ship. MCP developers don't have to abandon their paradigm; they can add context-engineering capabilities incrementally, through the protocol they already know. It proves that protocol-level interoperability and context-level intelligence aren't mutually exclusive.
What's Next?
The models are evolving. The paradigm is evolving. The methodology is evolving.
I believe LLMs will become powerful enough to handle complex tasks based purely on context engineering, within a year or two. The trajectory points toward agents that don't need carefully crafted tool schemas to interact with the world; they'll need carefully crafted context to understand what they should do, why they should do it, and how to reason about tradeoffs.
When that day comes:
- MCP's tools won't disappear — they'll become infrastructure, like HTTP endpoints.
- Skills won't disappear either — they'll evolve into richer, more adaptive formats.
- And whatever comes next will combine protocol-level interoperability (MCP's gift) with context-level intelligence (Skills' gift) in ways that will make today's debate look quaint.
The question isn't "MCP or Skills?" — It's "what does the next island look like?" And the ship has already left port.
Top comments (0)