Independent directory of the Claude Code skills, MCP servers & marketplaces worth installing. 86,000+ tools indexed daily, ranked by real installs. Not affiliated with Anthropic.
The tools are cheap because they are loaded on demand, and they get ignored because they are loaded on demand.
The MCP docs back that reading: with tool search on (the default), only tool names and server instructions load at session start. The same page names the server-side fix for the two sessions that never searched. Server instructions "help Claude understand when to search for your tools." Your ten tools ride on the IDE's server, so that field belongs to JetBrains, and your CLAUDE.md line ends up doing its job.
Two other levers, each with a cost. "alwaysLoad": true on the server entry in your --mcp-config loads its tools upfront whatever ENABLE_TOOL_SEARCH says, but it works per server, so all 119 definitions come in. Per tool, a server can set "anthropic/alwaysLoad": true in that tool's _meta. Does the JetBrains plugin API let you set _meta on your ten? That would load only yours and skip the search step.
Problem solver here to meet your business demands with effective and flexible IT solutions. With a strong interest in both cybersecurity and operational development, I also specialize in turning
Thanks, that's the most precise explanation so far, and it matches what I saw: the two sessions that skipped the tools never ran a tool search, so they only had names to go on. I haven't tried alwaysLoad yet. Loading all 119 definitions would cost a lot more than the ~2,300 tokens I measured, so the per-tool _meta option is the interesting one. I don't know yet whether the plugin API lets me set _meta on the tools I register. I'll check, and if it does, I'll run the same 9 sessions with only my ten tools always loaded and no CLAUDE.md line, then post the numbers here.
Problem solver here to meet your business demands with effective and flexible IT solutions. With a strong interest in both cybersecurity and operational development, I also specialize in turning
Does the JetBrains plugin API let me set _meta on my ten tools? No. The IDE's MCP server builds every tools/list entry with _meta left empty (checked in 2025.3 and 2026.1), and a plugin's tool descriptor has no field for it. So the per-tool "anthropic/alwaysLoad" is out of my hands; it would need JetBrains to expose it.
So I ran the 9 sessions with your other lever: "alwaysLoad": true on the server entry, no CLAUDE.md line, same prompt and project, Sonnet.
without alwaysLoad: 0/6 sessions used the tools
with alwaysLoad, ten i18n tools: 6/6, 21-28 s, $0.12-0.29
with alwaysLoad, only the two translation tools: 3/3, 20-23 s, $0.11-0.27
all 9 wrote the 92 values, none touched an existing one
The cost is the one you predicted: every tool of the IDE's server loads upfront (73 in this WebStorm build), so the first turn goes from ~16k to ~48k tokens of context, in every session of the project, translation or not.
The CLAUDE.md line gets the same 3/3 at $0.12-0.13 with no extra cost, so it stays my recommendation, and alwaysLoad is now documented as the fallback when you can't touch the project file: github.com/IBRAHIMDANS/i18nSupport...
Really useful measurement — the 2-in-6 miss rate is the interesting number here, more than the speed win.
One thing your results point to: the CLAUDE.md line worked because it is in context from turn zero, while the tool definitions are only loaded on demand. So at the moment the model decides how to do the job, it is choosing mostly from tool names, not from what the tools actually do. That makes the name and the first sentence of the description do most of the work — "use this instead of editing the locale JSON files" belongs in the description itself, not just in CLAUDE.md.
The other lever is count. Ten tools for one job means ten chances for the model to decide none of them is the obvious entry point. A single entry-point tool that lists the missing keys and writes them in one call would probably get picked more reliably than ten granular ones, at the cost of some flexibility — worth an A/B run if you repeat the experiment.
Problem solver here to meet your business demands with effective and flexible IT solutions. With a strong interest in both cybersecurity and operational development, I also specialize in turning
Thanks, that matches what I saw. You are right about the descriptions: none of them says "use this instead of editing the locale files". They describe what each tool does, not when to prefer it over a plain edit. I will move that sentence from CLAUDE.md into the descriptions of i18n_missing_translations and i18n_write_translations, then rerun without the CLAUDE.md line to see whether it is enough on its own.
On a single entry point: the plugin has no model, so the agent does the translating. That means two calls at least, one to list what is missing and one to write it. But the A/B is cheap to run: same prompt, only those two tools allowed, against the full ten. I will post the numbers here.
Problem solver here to meet your business demands with effective and flexible IT solutions. With a strong interest in both cybersecurity and operational development, I also specialize in turning
@agentwareshq
I ran it. Same prompt, same setup, and the new descriptions now open with "Use this instead of editing the translation files...".
10 tools, no CLAUDE.md line: 0 of 6 sessions wrote through the tools. Two called i18n_missing_translations after writing the files themselves, to check their work.
Only the 2 translation tools exposed: 0 of 3.
Control, same IDE, with the CLAUDE.md line: 3 of 3, 22 to 24 s, $0.12 to $0.13.
So in this setup the description did nothing, and fewer tools did nothing either. That fits your first point better than your fix. With deferred tools, the model decides from the names, and it reads a description only once it has already chosen. The project-level line is what it sees at turn zero, and that is still the only thing that worked.
Small sample, one model, and a different IDE build from the first run, so I would not compare these numbers to the 4 of 6 from the article. But the control makes the point. Thanks for pushing me to measure it.
The tool only shows the agent the English text, so it never sees that the French file keeps "trustee" in English. What if the list of missing keys also came with a few existing translations from that file?
Problem solver here to meet your business demands with effective and flexible IT solutions. With a strong interest in both cybersecurity and operational development, I also specialize in turning
Good catch, and it explains part of the terminology drift I mentioned: the tool gives the agent the source text but not the decisions already made in the target file. Returning a few existing translations from that file next to the missing keys would be cheap to add, and it's a better fix than asking the agent to go read the JSON on its own. I've noted it for the plugin. Do you think a short sample would be enough, or would you rather see a glossary of terms that stay untranslated?
GMT strategy and custom B2B outreach lists on request: people and companies by ICP, domain, profile URL, email or name. 1B+ profiles. Claude Code plugins, API, MCP. kevin@outricher.com
the two runs that skipped the tools are the number I would chase. a tool description is only read when the tool is listed, so a one line pointer in the project file saying to use them first gets read on every run. did you try that, and did the miss rate move
Problem solver here to meet your business demands with effective and flexible IT solutions. With a strong interest in both cybersecurity and operational development, I also specialize in turning
Yes, that's the fix that worked. With one line in CLAUDE.md pointing at the i18n_* tools, 3 of 3 runs used them, and the control in my rerun gave 3 of 3 again. Moving the same sentence into the tool descriptions did nothing (0 of 6), and so did exposing only the two translation tools (0 of 3). Details are in my reply to the first comment. Small samples, but for now the project file is the only lever that moved the miss rate.
Tool names that match the task wording (say translate_missing_strings) might help too, since the model picks tools partly by how closely the name fits the request.
Problem solver here to meet your business demands with effective and flexible IT solutions. With a strong interest in both cybersecurity and operational development, I also specialize in turning
Good point, though in this case the name was already close: the prompt said "translate the keys missing" and the tool is i18n_missing_translations. The two sessions that skipped the tools never ran a tool search at all, so they never got to the name. My guess is that the decision to edit the files by hand happens before name matching. A description that says "instead of editing the files" might reach it earlier. That is the next run.
We're a place where coders share, stay up-to-date and grow their careers.
The MCP docs back that reading: with tool search on (the default), only tool names and server instructions load at session start. The same page names the server-side fix for the two sessions that never searched. Server instructions "help Claude understand when to search for your tools." Your ten tools ride on the IDE's server, so that field belongs to JetBrains, and your CLAUDE.md line ends up doing its job.
Two other levers, each with a cost.
"alwaysLoad": trueon the server entry in your--mcp-configloads its tools upfront whateverENABLE_TOOL_SEARCHsays, but it works per server, so all 119 definitions come in. Per tool, a server can set"anthropic/alwaysLoad": truein that tool's_meta. Does the JetBrains plugin API let you set_metaon your ten? That would load only yours and skip the search step.Thanks, that's the most precise explanation so far, and it matches what I saw: the two sessions that skipped the tools never ran a tool search, so they only had names to go on. I haven't tried alwaysLoad yet. Loading all 119 definitions would cost a lot more than the ~2,300 tokens I measured, so the per-tool _meta option is the interesting one. I don't know yet whether the plugin API lets me set _meta on the tools I register. I'll check, and if it does, I'll run the same 9 sessions with only my ten tools always loaded and no CLAUDE.md line, then post the numbers here.
Follow-up, as promised.
Does the JetBrains plugin API let me set _meta on my ten tools? No. The IDE's MCP server builds every tools/list entry with _meta left empty (checked in 2025.3 and 2026.1), and a plugin's tool descriptor has no field for it. So the per-tool "anthropic/alwaysLoad" is out of my hands; it would need JetBrains to expose it.
So I ran the 9 sessions with your other lever: "alwaysLoad": true on the server entry, no CLAUDE.md line, same prompt and project, Sonnet.
The cost is the one you predicted: every tool of the IDE's server loads upfront (73 in this WebStorm build), so the first turn goes from ~16k to ~48k tokens of context, in every session of the project, translation or not.
The CLAUDE.md line gets the same 3/3 at $0.12-0.13 with no extra cost, so it stays my recommendation, and alwaysLoad is now documented as the fallback when you can't touch the project file: github.com/IBRAHIMDANS/i18nSupport...
Really useful measurement — the 2-in-6 miss rate is the interesting number here, more than the speed win.
One thing your results point to: the CLAUDE.md line worked because it is in context from turn zero, while the tool definitions are only loaded on demand. So at the moment the model decides how to do the job, it is choosing mostly from tool names, not from what the tools actually do. That makes the name and the first sentence of the description do most of the work — "use this instead of editing the locale JSON files" belongs in the description itself, not just in CLAUDE.md.
The other lever is count. Ten tools for one job means ten chances for the model to decide none of them is the obvious entry point. A single entry-point tool that lists the missing keys and writes them in one call would probably get picked more reliably than ten granular ones, at the cost of some flexibility — worth an A/B run if you repeat the experiment.
Thanks, that matches what I saw. You are right about the descriptions: none of them says "use this instead of editing the locale files". They describe what each tool does, not when to prefer it over a plain edit. I will move that sentence from CLAUDE.md into the descriptions of i18n_missing_translations and i18n_write_translations, then rerun without the CLAUDE.md line to see whether it is enough on its own.
On a single entry point: the plugin has no model, so the agent does the translating. That means two calls at least, one to list what is missing and one to write it. But the A/B is cheap to run: same prompt, only those two tools allowed, against the full ten. I will post the numbers here.
@agentwareshq
I ran it. Same prompt, same setup, and the new descriptions now open with "Use this instead of editing the translation files...".
So in this setup the description did nothing, and fewer tools did nothing either. That fits your first point better than your fix. With deferred tools, the model decides from the names, and it reads a description only once it has already chosen. The project-level line is what it sees at turn zero, and that is still the only thing that worked.
Small sample, one model, and a different IDE build from the first run, so I would not compare these numbers to the 4 of 6 from the article. But the control makes the point. Thanks for pushing me to measure it.
PR #870
The tool only shows the agent the English text, so it never sees that the French file keeps "trustee" in English. What if the list of missing keys also came with a few existing translations from that file?
Good catch, and it explains part of the terminology drift I mentioned: the tool gives the agent the source text but not the decisions already made in the target file. Returning a few existing translations from that file next to the missing keys would be cheap to add, and it's a better fix than asking the agent to go read the JSON on its own. I've noted it for the plugin. Do you think a short sample would be enough, or would you rather see a glossary of terms that stay untranslated?
the two runs that skipped the tools are the number I would chase. a tool description is only read when the tool is listed, so a one line pointer in the project file saying to use them first gets read on every run. did you try that, and did the miss rate move
Yes, that's the fix that worked. With one line in CLAUDE.md pointing at the i18n_* tools, 3 of 3 runs used them, and the control in my rerun gave 3 of 3 again. Moving the same sentence into the tool descriptions did nothing (0 of 6), and so did exposing only the two translation tools (0 of 3). Details are in my reply to the first comment. Small samples, but for now the project file is the only lever that moved the miss rate.
Tool names that match the task wording (say translate_missing_strings) might help too, since the model picks tools partly by how closely the name fits the request.
Good point, though in this case the name was already close: the prompt said "translate the keys missing" and the tool is i18n_missing_translations. The two sessions that skipped the tools never ran a tool search at all, so they never got to the name. My guess is that the decision to edit the files by hand happens before name matching. A description that says "instead of editing the files" might reach it earlier. That is the next run.