Claude Code Skill vs MCP server: which one does Claude use?

If you give Claude Code a Skill and an MCP server that do the same job, which one does it use? I installed the same notes search both ways and asked 12 questions 288 times. With both installed, Claude searched with the Skill in 25 of 48 runs and with the MCP tool in 21 (2 runs did not search). It was not a coin flip, though. The wording of the prompt moved it, and one thing on the MCP side decided it outright: what the server shows before its tools are loaded. With vague names the MCP server lost every run to the Skill. With two sentences of server instructions it won every run in which Claude searched.

This is the third post on agent memory and MCP. The first measured whether an MCP memory server returns the right note, the second whether Claude calls a small MCP server at all. This one adds a competitor.

Why test a Skill against an MCP server?

Because people now install both, and they overlap. A GitHub issue, anthropics/claude-code#101704, reports that with the Playwright MCP server and a browser Skill installed, Claude Code “always chooses the Skill and ignores the MCP server”. Their explanation: a deferred MCP server shows up as a bare name, while a Skill shows up with its description. The Skills docs confirm the Skill half: “skill descriptions are loaded into context so Claude knows what’s available, but full skill content only loads when invoked.” My last post confirmed the MCP half: until Claude loads a tool, it sees tool names and server instructions, not descriptions.

So I built the cleanest comparison I could: one search, two wrappers.

How I set it up

The search is the BM25 index from the last post, moved into a shared module, notes-index.mjs, so both sides return byte-identical results. The MCP side is the same 97-line server with two tools, search_notes and read_note. The Skill side is a folder with a SKILL.md and a small CLI that Claude runs through Bash:

---
name: search-notes
description: Full-text search over the user's local Markdown notes and blog posts. Use it before answering questions about what these notes say.
---

# Search notes

The user's notes are a folder of Markdown files. Search them with the bundled script and answer from what it returns.

1. Search (returns the best matching files with a title, a relevance score and a snippet):

   node "${CLAUDE_SKILL_DIR}/search.mjs" search "words to look for" 3

2. If a snippet does not hold the answer, read the whole file by the path the search returned:

   node "${CLAUDE_SKILL_DIR}/search.mjs" read "path/from/search.md"

The Skill’s description is the MCP tool’s description, reworded. Neither side got an advantage in wording that I could see.

The questions are the 12 from the last post, about seven posts of this blog, such as “How much RAM did the Hermes Agent gateway use while idle?” Each went to claude -p (Claude Code 2.1.302, Claude Sonnet 5.5) twice: hinted, starting with “Check my notes.”, and bare. The working folder held nothing but the Skill, web search was off, and every condition had the same permissions: the MCP server, the Skill tool and node in Bash. Personal CLAUDE.md files, memory and my user-level Skills were switched off (last time they skewed a whole run).

Six conditions, 2 repetitions, 288 runs. For each run I recorded which side ran the first search: an mcp__ tool call, or the Skill’s script in Bash.

Which one does Claude Code pick when both are installed?

Installed	Searched with MCP	Searched with the Skill	No search	Right answer
MCP server only	44	0	4	48 / 48
Skill only	0	46	2	48 / 48
Both	21	25	2	48 / 48
Both, server instructions added	45	0	3	48 / 48
Both, tool search off	48	0	0	48 / 48
Both, vague MCP names (s1, query)	0	46	2	47 / 48

Alone, each side worked: 44 and 46 of 48 runs searched, and the few that did not were questions Claude knows from training (Ollama’s default context without a GPU, Hermes Agent’s 64K minimum), answered from memory and right.

Together, with a well-named MCP server (notes, search_notes), it split 21 to 25. Claude never searched with both in the same run. In 11 of those 48 runs it loaded both, invoking the Skill and fetching the MCP tool’s schema, and then used one. Three times it read the Skill’s instructions and then searched with the MCP tool anyway.

Every answer was right whichever side Claude picked, except one: with the vague server, a Skill run answered “up to 60 seconds late” from a snippet instead of reading the note (the post says 49). So for this task the choice did not change the answers. It changes which code runs, which matters as soon as the two sides are not identical.

Why did the wording change the winner?

Both installed, by phrasing	Searched with MCP	Searched with the Skill	No search
“Check my notes. …”	17 / 24	7 / 24	0 / 24
Plain question	4 / 24	18 / 24	2 / 24

My reading: with “Check my notes.”, the word notes matches the deferred tool name mcp__notes__search_notes, which is all Claude sees of the server. A plain question such as “What context size does Ollama pick by default when there is no GPU?” matches nothing in a tool name, and the Skill is the only entry with a sentence explaining what it holds. The data fit that: the Skill wins exactly where the name gives Claude nothing to go on.

Does a vague MCP server lose to a Skill every time?

In my runs, yes. I renamed the server s1 and its tools query (“Runs a query.”) and get, the same code, and Claude used the Skill in 46 of 48 runs and the MCP server in 0. It never even loaded the server’s schema. That is the situation in issue #101704: a server whose deferred name does not say what it is for, next to a Skill that does. In the last post, with no Skill installed, the same vague server still got used in 20 of 48 runs. A Skill with a description takes those runs.

How do you make Claude Code prefer your MCP server?

Two things worked, and either one flipped the result completely.

Server instructions. These two sentences, passed as the server’s instructions, took the MCP side from 21 to 45 of 48 and the Skill from 25 to 0:

Searches the user's local Markdown notes and blog posts. Use search_notes when the user asks about
their notes or about results from their experiments.

Server instructions are loaded with the deferred tool names, so they give the server what the Skill already had: a sentence saying what it is for. Claude invoked the Skill once in those 48 runs and then searched with the MCP tool.

Turning tool search off (ENABLE_TOOL_SEARCH=false) loads every MCP tool definition upfront. The MCP tool won all 48 runs. That costs context, though, as the next section shows.

If you maintain a Skill and want the opposite, the levers are the same in reverse: the Skill’s description is what Claude reads. The docs cap the description and when_to_use text at 1,536 characters in the listing.

Is the Skill or the MCP path slower or more expensive?

About the same. Medians for runs that searched with one side only:

Path	Runs	Turns	Wall time	Cost per answer (API prices)
MCP, alone	44	4	7.8 s	USD 0.038
MCP, with the Skill installed	21	4	7.6 s	USD 0.035
MCP, tool search off	48	3	6.5 s	USD 0.034
Skill, alone	46	5	7.8 s	USD 0.029
Skill, with the MCP server installed	25	5	7.7 s	USD 0.028

The Skill path takes one more turn, because invoking the Skill is a tool call of its own before the Bash call, but wall time was within half a second. The Skill runs came out cheaper at API prices; I did not dig into why, and the differences are small next to the run-to-run spread. The slowdown in issue #101704 (2m36s against 8m19s) came from what their Skill did once loaded, long shell workflows with retries, not from the routing itself. With two wrappers around the same search, I saw no such gap.

How much context does each one cost?

Input tokens for a one-turn “Reply with the single word OK.” prompt, three runs each (identical every time):

Setup	Input tokens
Nothing installed	13,631
MCP server, tool search on	13,653 (+22)
Skill	13,675 (+44)
Both	13,697 (+66)
Nothing installed, tool search off	28,210
MCP server, tool search off	28,558 (+348)

Idle, both are cheap. The Skill’s listing (name plus one sentence) costs twice the deferred MCP names, and it buys the description that wins the bare questions. Tool search off costs 348 tokens for this server plus about 14,600 tokens of Claude Code’s own tools on every request, which is why I would reach for server instructions first. A follow-up measured a middle ground: marking one tool with anthropic/alwaysLoad got it called in 96 of 96 runs for 238 tokens of context.

Should you ship a Skill or an MCP server?

From these runs, for a capability both could provide:

• If both are installed, expect a split, not a winner. Which one runs depends on the user’s words and on the one sentence each side shows Claude before loading.
• An MCP server without instructions is at a disadvantage next to a Skill. Its tools are only names until loaded. Name the server and tools after what they hold, and write instructions.
• Don’t install both for the same job unless you mean it. If they differ (a Skill that wraps a CLI, an MCP server with auth or state), Claude will use either, and you will debug two code paths. Pick one, or make the Skill tell Claude to call the MCP tool.
• A Skill is the cheaper thing to write. Mine is 22 lines of Markdown and a 20-line CLI around the shared search code; it worked in 46 of 48 runs alone with no server process.

What broke and what I’d do differently

• The vague-name condition was not in the plan. I added it while the first repetition was running, to test the issue’s case directly, so its first 24 runs ran after the others instead of interleaved with them. The second repetition interleaved all six conditions, and both repetitions agree (0 MCP searches each time).
• My first summary counted “the Skill was invoked first” as a Skill win. Three runs invoked the Skill and then searched with the MCP tool, so I switched to counting which side ran the search.
• With only the MCP server installed, bare questions led Claude to run ls and grep in 15 of 24 runs before or instead of the tool, some outside the working folder. Claude Code allows read-only commands like these without asking. None of them reached the notes.
• The sample is small: one model, one corpus of seven files, 12 questions, 2 repetitions. Each split was the same direction in both repetitions, but read the counts as directions, not rates. I did not test Opus or Haiku, a plugin-packaged Skill, or a Skill that tells Claude to prefer the MCP tool.
• Claude Code reported USD 9.17 at API prices for the 288 runs (it ran on a subscription), plus 21 short context-cost runs.

Everything is in the project folder: the shared search, both wrappers, the six conditions, the script that drives claude -p, and every run with its tool calls and answers. To build the MCP side from scratch, start with the 97-line server post.