Open a fresh Claude Code session in one of my client repos and run /context. Before I type a single word, tens of thousands of tokens are already spent. Most of that is MCP tool definitions: a GitHub server, a Playwright server, a docs server, a memory server. Each one ships dozens of tool schemas, and every schema gets loaded whether the session needs it or not.
Now look at the same repo's .claude/skills/ directory. Twenty-plus skills, each a markdown file with a one-line description. Cost at session start: one line each. The full skill only loads when the agent actually invokes it.
That asymmetry is the entire MCP-vs-Skills debate, and right now it is the loudest argument in the AI tooling world. Red Hat wrote a decision guide. Martin Fowler's site published a context engineering taxonomy that puts both on the same map. Half of Hacker News declared MCP dead in January; by June, Firecrawl reported MCP usage growing roughly 35% in a single month.
Both camps are arguing past each other. MCP and Skills are not competitors. They answer different questions.
The one-sentence version
- MCP gives an agent the ability to do something. Live connections: query your Kubernetes cluster, open a GitHub PR, read a Postgres schema. Capability.
- Skills give an agent the knowledge of how to do something. Procedures: your incident runbook, your Terraform module conventions, your PR review checklist. Knowledge.
The Agentic AI Foundation calls the space between these two the "context gap": an agent with a steering wheel but no driving lessons. Give an agent full kubectl access via MCP and no procedural knowledge, and it will happily "fix" your cluster in ways your on-call rotation will remember for years. I wrote about the guardrail side of this in the $47K AWS bill post. Capability without knowledge is how those incidents happen.
What changed in the last six months
Two things turned this from a niche Claude Code question into an industry-wide one.
1. Skills became an open standard. Anthropic published the Agent Skills spec at agentskills.io in December 2025. As of mid-2026, roughly 40 products support it, including OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, and VS Code. A skill you write for Claude Code runs unmodified in a competitor's agent. That portability is what pushed skills from "Claude feature" to "infrastructure."
2. Agents got better at deferred loading. The original MCP complaint was real: every server you added dumped its full tool catalog into your context window at session start. Modern harnesses now defer tool schemas and load them on demand. That fixed the worst of the token bleed, but it didn't change the underlying design question: should this thing be a live integration or a document?
The decision framework I actually use
Four questions, in order:
1. Does it need live data or credentials?
If the agent needs real-time state (cluster health, open issues, current cloud spend), that's MCP. A skill can't query anything; it's markdown. If your answer involves an API token, it's MCP by definition, because MCP is also your permission boundary. You scope what the server can touch; the agent never holds raw credentials.
2. Is it knowledge the agent already almost has?
Claude already knows what a Kubernetes deployment is. It does not know that your team requires PodDisruptionBudgets on everything in the payments namespace, or that your Terraform modules pin provider versions in a shared file. Team-specific procedure → skill. General capability → you probably need neither; the base model has it.
3. How often is it needed?
A skill costs you one description line until invoked. An MCP server costs you a running process, an auth setup, and (depending on your harness) schema overhead. For something you use in 1 out of 20 sessions, a skill or even a plain script the agent can run beats a standing server.
4. Could a CLI do it?
This is the filter most people skip. If a well-documented CLI already exists (gh, aws, kubectl, psql), a skill that teaches the agent your way of using that CLI is often better than an MCP server that wraps it. The agent gets the capability from Bash and the knowledge from the skill, and you maintain zero server processes. I covered the config mechanics in the MCP server config guide; the guide still stands, but rule zero is now "check if you need a server at all."
The pattern that wins: MCP for hands, skills for brains
Here's a concrete DevOps example, because every abstract explanation of this makes it sound harder than it is.
Incident response setup:
.claude/skills/incident-response/SKILL.md ← the runbook (skill)
.mcp.json ← grafana + pagerduty servers (MCP)
The skill says: check dashboards in this order, never restart the payment service without draining first, page the DBA if replication lag exceeds 30 seconds, write the timeline to the incident doc as you go.
The MCP servers let the agent actually pull the Grafana dashboards and acknowledge the PagerDuty alert.
Remove the MCP servers and the agent knows the procedure but can't see anything. Remove the skill and the agent sees everything but improvises the procedure. Improvised incident response at 2 AM by an autonomous agent is how you become a cautionary tale in someone else's blog post.
When each one is the wrong tool
Skills are wrong when: you need real-time data, enforced permissions, or guarantees. A skill is advice; the model can ignore it. If a rule must never be broken, like "never run mutations against prod", that's not a skill, that's a hook. Hooks are deterministic; skills are probabilistic.
MCP is wrong when: you're wrapping static knowledge in a server because servers feel more "real." I've reviewed setups where an MCP server existed solely to return the contents of a style guide. That's a markdown file with an operations team. Delete the server, commit the skill.
Takeaways
- MCP = capability + permission boundary. Skills = procedure + convention. Different questions, different tools.
- Audit your MCP servers with the CLI test. If a CLI covers it, replace the server with a skill that teaches your usage of that CLI.
- Never encode hard rules as skills. Skills are suggestions. Hooks are enforcement. Know which one your rule needs.
- Write skills for the boring stuff first. Deploy procedures, PR conventions, incident runbooks. That's where agents fail today: not for lack of capability, but for lack of your context.
- The standard is portable now. Skills you write today work across Claude Code, Codex, Copilot, and Cursor. That's the best effort-to-payoff ratio in AI tooling right now.
If you're setting this up from scratch: start with the CLAUDE.md guide, add skills for your top three repeated procedures, and only then add MCP servers for the live systems the agent genuinely needs to touch. Most teams do it in the opposite order, and their context windows show it.