Can a Claude Code Skill call an MCP tool? 432 runs

Can a Claude Code Skill call an MCP tool? Yes, and it works better than I expected. I wrote a Skill whose body says “search with mcp__notes__search_notes” and has no code of its own, and Claude Code searched with that MCP tool in 133 of 144 runs across Haiku 5.5, Sonnet 5.5 and Opus 5.5. The same pattern rescued a server with vague names: used in 25 of 48 runs on its own, 44 of 48 with the Skill pointing at it, and every answer right. The surprise was the control: when the Skill wraps its own script instead, Opus used the script in 46 of 48 runs and never touched the MCP tool.

This is round two of Claude Code Skill vs MCP server, the fifth post on agent memory and MCP (the first measured recall from an MCP memory server). Round one ended with three things I had not tested: a Skill that tells Claude to call the MCP tool, a Skill packaged in a plugin, and models other than Sonnet. This post tests all three, with the same search and the same 12 questions.

Why point a Skill at an MCP tool?

Because of how Claude Code shows the two before either is used. With tool search on (the default), a deferred MCP server appears as tool names only; Claude has to call ToolSearch to see descriptions. A Skill appears with its one-sentence description. In round one that asymmetry decided a lot: a vaguely named server lost every run to a Skill, and plain questions went to the Skill 18 to 4. Issue anthropics/claude-code#101704 reports the same thing with the Playwright server.

So if the Skill listing is what Claude reads, a Skill can be the description for your MCP server. That is the “bridge” Skill: same name and description as the round-one Skill, but the body is instructions only:

---
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, served by the `notes` MCP server. Search them with its tools and
answer from what they return.

1. Search with the `mcp__notes__search_notes` tool (arguments: `query`, the words to look for, and `limit`, default 3).
   It returns the best matching files with a title, a relevance score and a snippet.

2. If a snippet does not hold the answer, read the whole file with `mcp__notes__read_note`, passing the `path` that
   the search returned.

Answer from the notes. If nothing matches, say so.

How I set it up

The pieces are the ones from round one: a BM25 search over seven posts of this blog, exposed as a stdio MCP server (search_notes, read_note) and as a Skill whose script Claude runs through Bash. Both import the same module, so results are identical. New this round: the bridge Skill above, a copy of it that names the vague server’s tools (mcp__s1__query, mcp__s1__get), and a plugin called notes that ships the script Skill, loaded with --plugin-dir and listed to Claude as notes:search-notes.

Each of the 12 questions went to claude -p (Claude Code 2.1.310) twice, hinted (“Check my notes. …”) and bare, under 9 conditions, 2 repetitions: 432 runs in about 70 minutes. For each run I recorded which side ran the first search: an mcp__ tool call or the Skill’s script. Invoking the Skill tool only loads text, so it does not count as a search. Personal CLAUDE.md files, memory and user-level Skills were off. An answer counts as right when it contains the expected numbers.

One change from round one. In the smoke test, a run with only the vague server answered a question by running grep -r over my entire home folder. So this round denies Read, Grep, Glob and read-only shell commands (grep, find, ls, cat and others) in every condition. Only the two search paths were open. That matters for one row below, and I come back to it under what broke.

Does Claude follow a Skill into an MCP tool?

MCP server + bridge Skill	Searched with MCP	Skill invoked first	No search	Right answer
Haiku 5.5	43 / 48	15	5	41 / 48
Sonnet 5.5	44 / 48	27	4	47 / 48
Opus 5.5	46 / 48	46	2	48 / 48

Yes, on all three models. Most runs that did not search answered from the model’s own knowledge (for example, Ollama’s default context size), the same few questions that skipped search in round one; a few Haiku runs said they could not find the data instead. Haiku also lost 5 answers that did search: two stopped at a snippet that did not hold the number instead of reading the note, and three said the recall test had 12 questions (it had 24).

How Claude got there differed by model. Opus invoked the Skill every time it searched, read the instructions, loaded the MCP schema with ToolSearch and called the tool. Sonnet did that for most bare questions (18 of 24) but went straight to the MCP tool for 15 of the 24 “Check my notes.” prompts, where the word notes already matches the server name. Haiku skipped the Skill most of the time and went straight to the tool. Either way, every one of the 133 MCP calls came after ToolSearch had loaded the schema, and none failed. Naming the tool in the Skill is enough; nothing else is needed for the deferred loading.

The cost is one turn, the Skill call itself. On Sonnet the median run had 5 turns instead of 4 and took the same 9.1 seconds as the plain MCP-plus-Skill setup.

Can a Skill rescue a badly named MCP server?

This was the case where round one’s server lost every run. Same server code, renamed s1 with tools query (“Runs a query.”) and get:

Sonnet 5.5	Searched with MCP	No search	Right answer
Vague server only	25 / 48	23	31 / 48
Vague server + bridge Skill naming mcp__s1__query	44 / 48	4	48 / 48

On its own, the vague server was mostly ignored on plain questions: 5 of 24 bare runs used it. In 23 runs Claude did not search at all, and 17 answers were wrong. None were invented numbers; all 17 said Claude could not find the data, such as “my attempt to look through the working directory was denied, so I haven’t seen any data”. In 44 of the 48 runs Claude tried the shell before anything else, and in the 23 runs without a search it never tried the tool called query.

With the bridge Skill, it invoked the Skill in 44 runs and searched with mcp__s1__query in all 44, and every answer was right. If you ship or use an MCP server whose names you cannot change, a 20-line SKILL.md that says what it is for and names its tools does the job that the server’s own metadata does not. In round one, two sentences of server instructions did the same for 45 of 48 runs, so that is the fix if you own the server.

Do Haiku and Opus pick a Skill or an MCP server like Sonnet does?

Not Opus. This is the round-one setup (the MCP server plus the Skill that runs its own script) on each model:

MCP server + script Skill	Searched with MCP	Searched with the script	No search	Right answer
Haiku 5.5	23	22	3	45 / 48
Sonnet 5.5	20	24	4	48 / 48
Opus 5.5	0	46	2	48 / 48

Sonnet reproduced round one almost exactly (21 MCP to 25 Skill then, 20 to 24 now, two Claude Code versions later), with the same phrasing effect: “Check my notes.” went 17 to 7 for MCP, plain questions 17 to 3 for the script. Haiku split the same way.

Opus did not split. It invoked the Skill in 46 of 48 runs, including all 24 “Check my notes.” prompts that pulled Sonnet toward the MCP tool, and never once called ToolSearch to look at the server. Both repetitions were identical (0 / 23 / 1). The answers were all right, so for this task it did not matter. If your Skill and your MCP server do different things, for example the server has auth, state or logging and the Skill shells out, the model choice alone decides which code runs.

Cost per answer at API prices, as Claude Code reported it (the runs used a subscription): Haiku USD 0.002, Sonnet USD 0.033, Opus USD 0.073. Median wall time: 10.2 s, 9.1 s and 15.7 s.

Does a plugin Skill get picked as often as a project Skill?

No. Same Skill, same files, shipped in a plugin instead of .claude/skills/:

Sonnet 5.5, MCP server + script Skill	Searched with MCP	Searched with the script	Skill invoked	No search
Skill in the project	20	24	28	4
Skill in a plugin (notes:search-notes)	34	10	10	4

The plugin copy was invoked 10 times against 28 for the project copy, and lost the plain questions it used to win (8 of 24 against 17). Both repetitions agreed (4 and 6 script searches). The idle context cost was the same within 4 tokens: a one-turn prompt with no tools used took 16,367 input tokens with nothing installed, +43 with the project Skill, +45 with the bridge Skill and +47 with the plugin Skill. So the plugin Skill was listed; Claude just chose it less.

I can’t say why from these runs. The visible difference is the namespaced name, notes:search-notes. My plugin was also called notes, the same as the MCP server, which may have made the server look like the plugin’s main tool. I did not test a plugin with a different name, so treat this row as “plugin Skills can lose ground to an MCP server”, not as a rate.

Should you wrap your MCP server in a Skill?

From these runs:

• If the server’s names don’t say what it does, yes. A Skill that names the tools took a vague server from 25 to 44 of 48 searches. It costs 45 tokens idle and one turn per use.
• Don’t install a Skill with its own implementation next to an MCP server for the same job. Sonnet and Haiku split by phrasing, and Opus ignored the server completely. If the Skill must exist, make it point at the MCP tool: then all three models use the server.
• Test on the model your users run. A routing result on Sonnet did not hold on Opus.
• If you own the server, server instructions are the simpler fix. Round one got 45 of 48 MCP searches with two sentences and no Skill.

What broke and what I’d do differently

• The smoke test grepped my home folder. With only the vague server installed, Sonnet ran grep -rIil "hermes" ~ to find “my notes”, and Haiku did the same in another run. Claude Code allows read-only commands like that without asking. I added deny rules for file browsing before the real runs, and all such attempts in the 432 runs were refused (Haiku tried in 30 of its 96 runs, Sonnet with the vague server in 44 of 48). If you benchmark Claude Code, check what a curious model can read from the working folder’s parents.
• Those deny rules make the vague-server-only row harder than round one’s setup: Claude tried the shell first in every run, and when it was refused it gave up in about half the runs instead of trying the unfamiliar tool. With the shell open, some of those 23 runs would have grepped instead. The bridge rows had the same rules and searched in 44 of 48.
• Answers were graded by regular expression. Five Haiku answers said the recall test had 12 questions (it had 24, 12 in each language), which the grader rightly failed. Partial answers like that would need a hand grade to count more finely.
• The plugin and the MCP server shared the name notes. Issue #85827 once claimed a name clash between a Skill and a server drops the server; that did not happen here (the server connected in all 432 runs), but the shared name is a confound for the plugin row.
• The sample is small: one corpus of seven files, 12 questions, 2 repetitions per condition. Every row agreed within 2 runs between repetitions, so the directions look solid; read the counts as directions, not rates.
• Claude Code reported USD 14.88 at API prices for the 432 runs, about half of it Opus, plus 12 short context-cost runs.

Everything is in the project folder: the three Skills, the plugin, the conditions, the script that drives claude -p, and every run with its tool calls and answers. For the server itself, start with the 97-line MCP server; for loading one tool upfront instead, see alwaysLoad vs tool search off.