skill-search-mcp

# skill-search [](https://github.com/sowhan/skill-search/actions/workflows/test.yml) **Semantic, on-demand skill retrieval for Claude Code.** Claude Code injects a short blurb for every installed skill into context on *every* turn so it can decide which to use. As your skill count grows, that listing becomes a large recurring token tax — and because the match is essentially name/description keyword overlap, a skill whose name doesn't echo the user's words quietly never fires. skill-search replaces that with a vector retriever over the **full** skill descriptions. Skills are set to `name-only` (name stays visible and invocable, the description leaves the budget), and an MCP tool returns just the few skills that semantically match the task at hand. > **Where it shines:** this pays off once you have a lot of skills installed — > roughly hundreds. With only a handful, the native listing is already cheap and > you don't need the extra round-trip. --- ## Proof of value All numbers below are **measured**, not estimated by vibes — on a real setup of **117 active skills**. You can reproduce them (see [Reproduce](#reproduce-the-numbers)). ### 1. It reclaims a measurable chunk of every turn The native skill listing injects name + description for all skills, every turn. At `name-only`, only the names remain and the retriever supplies descriptions on demand. Counted with a real BPE tokenizer (`tiktoken` cl100k_base), modeling each skill as it appears in the listing (`- name: description`): | | Tokens injected per turn | % of a 200K window | |---|---:|---:| | Native full listing (name + description) | 7,267 | 3.63% | | `name-only` + skill-search | 887 | 0.44% | | **Saved, every turn** | **6,380** | **3.19%** | That's ~53 tokens/skill of description you stop paying for on turns that don't need them. The worst offenders are generic-named skills whose value lives entirely in the descript…