Claude Skills are folders of instructions that teach Claude how to do a task. MCP servers are connectors that give Claude access to external data. Skills shape behaviour. MCP unlocks reach. The right answer for almost every real workflow is both, with Skills handling the procedure and MCP feeding it the data.
In late 2025 Anthropic shipped Agent Skills. By April 2026 the AI Twitter timeline had decided this was either the most important thing since MCP or the death of MCP, with no middle ground. Both takes are wrong.
I have been building on top of Claude for the last six months, including an MCP server for ContextBolt and a stack of Skills that runs my own workflows. The two features are not in competition. They sit at different layers of how Claude actually does work.
This post breaks down where each one fits, when to reach for one over the other, and why the wrong choice burns context for no upside.
What Claude Skills actually are
A Claude Skill is a folder containing a SKILL.md file with YAML frontmatter and Markdown instructions. Optional files can sit alongside it: example outputs, scripts, templates. Claude reads the Skill on demand and follows the instructions inside.
The mechanism is what Anthropic calls progressive disclosure. Only the YAML frontmatter (name, description, when to use) is loaded into the system prompt at startup. That costs roughly 30 to 50 tokens per Skill. The body of the Skill, plus any linked files, are pulled in only when Claude decides the Skill is relevant.
This matters because it is what lets you keep dozens of Skills installed without bloating context. According to Anthropic’s docs, teams routinely run 20 to 50 Skills in a single Claude environment with no measurable performance hit.
A Skill cannot call an API. It cannot read your files unless Claude already has filesystem access through another mechanism. It cannot fetch a webpage. It is text that Claude reads and follows. Powerful text, but text.
The clearest way to think about it: a Skill is what you would write in a Notion page if you were onboarding a contractor to do a recurring task. The same instructions, just structured so Claude can find and apply them automatically.
What MCP actually is
The Model Context Protocol is a standard for connecting Claude to data sources and tools (official spec). An MCP server runs as a separate process, exposes a list of tools, and Claude calls those tools mid-conversation when it needs them.
The reach is the point. With MCP, Claude can read files on your machine, query a Postgres database, fetch a tweet you bookmarked, post a Slack message, or hit any API the server exposes. None of that is possible inside the conversation otherwise.
By early 2026 MCP had become genuine infrastructure. SDK downloads passed 97 million per month. Microsoft, Google, OpenAI, AWS, Cloudflare, Block, and Bloomberg all ship MCP support. It is no longer an Anthropic side project.
The cost: setup is real. Most MCP servers need either an OAuth flow through Claude Desktop’s Connectors menu or a JSON config edit with credentials. You also have to think about authentication, rate limits, and what happens when the underlying service changes its API.
Skills are instructions. MCP is connectivity. Once you internalise that distinction the rest of the comparison falls into place.
The side-by-side that actually matters
| Dimension | Claude Skills | MCP |
|---|---|---|
| What it provides | Procedural knowledge (how) | External access (what) |
| Format | Markdown file with YAML frontmatter | Server process exposing tools |
| Data access | None on its own | Files, APIs, databases, web |
| Setup | Drop a folder in .claude/skills/ | Install server, configure auth, edit JSON |
| Token cost at idle | 30 to 50 tokens per Skill | Tool descriptions in system prompt |
| Sharing | Drop a Markdown file in a repo | Publish a server, document the install |
| Best at | Style, judgement, workflows, formatting | Live data, integrations, system access |
| Worst at | Anything requiring fresh data | Encoding subjective taste or process |
The mistake people make is treating these as alternatives. They are not alternatives. They are layers.
When Skills are the right tool
Reach for a Skill when the task is procedural and self-contained. Some patterns where Skills clearly win.
Style and brand consistency. You want every email reply, document, or commit message to follow the same conventions. A Skill captures the rules, examples, and edge cases in one file. Claude applies them automatically whenever the task matches the description in the frontmatter.
Workflow templates. Code review checklists, weekly report formats, customer response templates. The procedure rarely changes and lives independently of any external data. A Skill encodes the procedure once and Claude executes it on demand.
Specialised formatting tasks. Anthropic’s own examples include Skills that produce Excel spreadsheets, PowerPoint decks, and PDFs with consistent layout. One reported finance workflow ran roughly 87% faster after the team encoded their formatting rules as a Skill instead of explaining them in every prompt.
Domain shortcuts. A “git commit message” Skill that knows your team’s conventions. A “customer escalation reply” Skill that knows your tone of voice. These are the tasks people currently solve by pasting the same prompt into Claude over and over. A Skill is the version that does not need pasting.
Anything you would otherwise turn into a prompt template. If you keep a prompt around in a notes file and copy it into Claude every few days, that is a Skill waiting to be created.
The unifying theme: a Skill is right when Claude already has everything it needs and you just want it to behave a specific way.
When MCP is the right tool
Reach for MCP whenever the task needs data Claude does not already have in the conversation. Some patterns where MCP clearly wins.
Querying your own knowledge base. Files on your machine, notes in Notion, a Postgres database, your bookmarks across X and Reddit and LinkedIn. Each of these needs an MCP server. There is no way for a Skill to reach into them.
Live external data. Stock prices, recent news, weather, anything where Claude’s training cutoff is the wrong source. An MCP server like Exa or Firecrawl gives Claude access to current information mid-conversation, with citations attached.
Automating actions. Posting to Slack, opening a GitHub PR, updating a calendar event. The action lives in another system. Only an MCP server can reach over and trigger it.
Cross-conversation memory. Tools like Mem0’s OpenMemory MCP let Claude write to and read from a persistent store. A Skill cannot store anything between sessions. Memory needs MCP.
Anything where the answer changes hour by hour. A Skill is static instructions. If the data behind the answer is moving, MCP is the only way Claude sees the current version.
The unifying theme: MCP is right when Claude needs to see something it cannot see today.
Where the real win is: both at once
The most useful pattern in real work combines them. The Skill encodes the procedure. The MCP server provides the data. Claude orchestrates.
A concrete example from how I use ContextBolt’s MCP. The MCP server exposes four tools: search_bookmarks, list_clusters, get_cluster_bookmarks, and get_recent_bookmarks. Each tool returns saved posts from X, Reddit, and LinkedIn.
That is the data layer. On top of it, a Skill called research-from-bookmarks tells Claude how to use those tools when I am writing about a topic. The Skill says: first list clusters relevant to the topic, then pull the top 20 bookmarks from those clusters, summarise the strongest takes, cite the original authors, and flag anything that contradicts itself. None of that procedural logic lives in the MCP server. None of the actual saved content lives in the Skill.
Run them together and a single sentence (“draft a piece on agent memory using my saves”) triggers the full chain: MCP fetches the relevant bookmarks, the Skill imposes the analytical structure, Claude writes the draft.
This is the architecture Anthropic’s own engineering team recommends for serious agent work. Skills are the playbook. MCP is the access layer the playbook uses.
The contrarian take that gets misread
Simon Willison wrote in October 2025 that Skills might be a bigger deal than MCP. The take got picked up and turned into “Skills replace MCP” headlines, which is not what he said and not what is happening.
Here is the argument that holds up. For solo users and small teams, the bottleneck is rarely access. Most people already have files Claude can read, notes Claude can search, and accounts Claude can already see. The bottleneck is procedure. They want Claude to do specific things consistently. Skills solve that.
For agents running unsupervised, or for any workflow that touches external systems, MCP is non-negotiable. You cannot replace a database connector with a Markdown file.
Skills feel transformative because the surface area people most often want to control is behaviour, not access. MCP is the bigger long-term story because every system Claude wants to touch eventually needs a connector. Both are right. They describe different parts of the elephant.
How to decide for any specific task
A simple decision framework that holds up in practice.
If the task is “do this consistently every time,” build a Skill. Style guides, formatting rules, response templates, code review checklists. The procedure lives in your head or in a doc. Codify it.
If the task is “look at this and tell me about it,” build or install an MCP server. Whatever “this” is, Claude needs access to it first. Filesystem MCP for files. Notion MCP for docs. ContextBolt MCP for social bookmarks. Without the connector there is nothing for any Skill to operate on.
If the task is “use this data to do this consistently,” build both. This is the real shape of most knowledge work. The MCP server is the data layer. The Skill is how you want Claude to handle the data once it has it.
If you are not sure, start with a Skill. Skills are cheaper to build, easier to share, and reversible. You can always wire in an MCP server later if the Skill keeps asking the user for data it could otherwise fetch automatically.
What this means for personal context
The reason Skills matter for ContextBolt users specifically: they make MCP data more useful without expanding the MCP surface.
A bookmark-research Skill, a weekly-saved-content-digest Skill, a find-the-thread-I-half-remember Skill. Each one points Claude at the existing four MCP tools and tells it how to use them for a specific outcome. The MCP layer never grows. The procedural layer does all the work.
This is the inverse of where most people are looking. The conversation is “which MCP servers should I install?” The more useful question for actual day-to-day Claude use is “which Skills should I write for the MCP servers I already have?”
If you have already built out a personal context stack, your next round of upside is on the Skill side, not the MCP side. The data is there. Teach Claude what to do with it.
The thing nobody is saying out loud
A Skill is just a Markdown file. That is so unremarkable as a technical fact that it is easy to miss what it actually unlocks.
Sharing AI workflows used to mean writing a guide, hoping people would copy your prompts, and watching most of them fail because the prompts were context-dependent. With Skills, you put the file in a public repo. Anyone with Claude Code clones it, and the next time they run a relevant task, the Skill kicks in. No translation, no setup, no support thread.
That is going to compound. The first wave of useful Skills came from Anthropic. The second wave is already happening on GitHub. The third wave is going to be domain experts publishing Skills the same way they currently publish Notion templates or Obsidian plugins.
MCP made integrations portable. Skills make procedures portable. The combination is what turns Claude from a smart chatbot into a workflow engine.
You do not need to pick a side. You need both.