This server routes and manages agent skills (SKILL.md files) over the Model Context Protocol (MCP), enabling discovery, intelligent matching, and secure retrieval of skill instructions.
list_skills() — Get a lightweight overview of all available skills (name + one-line description), useful as a cheap first step.
match_skill(query, top_k?) — Rank skills by relevance to a task, returning 0–1 confidence scores and a requires field listing needed tools. Uses semantic (Ollama embedding) matching with automatic keyword fallback; engine is reported in results.
get_skill(name) — Load full SKILL.md instructions for a skill, capped at 8,000 tokens. Returns a truncated flag and sections list if content was cut off.
get_skill_section(name, section) — Fetch a single H2 section of a large skill by heading name, enabling incremental loading when get_skill returns truncated: true.
rescan_skills() — Force an immediate re-index of the skills directory after adding or modifying skill files (a file watcher also handles this automatically).
MCP resources — Skills are also exposed as MCP resources (skill://index.json, skill://<name>/SKILL.md) for spec-aware hosts.
Security — Path allowlist, skill-name sanitization, and index-time content linting for prompt injection, credential exfiltration, and similar suspicious patterns.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@skill-router-mcp match skill for compressing images"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Skill routing for SKILL.md libraries, served over MCP to any agent.
Point it at a directory of Agent Skills
(SKILL.md files with YAML frontmatter) and any MCP client — Claude Code,
Cursor, Windsurf, Codex, or your own agent — can discover skills, match a task
to the best one, and load instructions on demand without blowing its context
window.
match_skill("create a word document")
→ [{ name: "docx", score: 0.85, requires: ["filesystem", "python"] }, ...]
get_skill("docx")
→ full SKILL.md instructions (token-capped, section-aware)Claude Code and Codex now load Agent Skills natively, and several MCP skill
servers already exist (skillz,
mcp-skill-hub,
skillserver,
Skills Over MCP). What none of them do is
rank skills against a task query — they rely on the host LLM picking from
descriptions, which degrades as skill libraries grow. This project's focus is
the routing layer: a scored match_skill backed by local embeddings (Ollama +
nomic-embed-text, with automatic keyword fallback), plus strict path
security and context-window discipline.
Measured on a 48-query labeled benchmark over 16 skills (queries written before measuring, not tuned):
Engine | Top-1 | Top-3 | MRR | ms/query |
keyword | 77.1% | 85.4% | 0.813 | ~1 |
semantic (nomic-embed-text) | 93.8% | 97.9% | 0.958 | ~69 |
Both engines score 100% on queries that share words with the skill
description — the gap is entirely on paraphrased (62.5% → 93.8%) and
indirect (68.8% → 87.5%) queries like "combine several invoices into a
single file for printing" → pdf. Reproduce with npm run benchmark.
Every match_skill response reports which engine produced the ranking
(semantic or keyword), so fallback is never silent.
Related MCP server: skills-mcp-server
Run it straight from npm — no clone, no build:
SKILLS_ROOT=/path/to/skills npx skill-router-mcpWire it into Claude Code (.mcp.json in your project):
{
"mcpServers": {
"skill-router": {
"command": "npx",
"args": ["skill-router-mcp"],
"env": { "SKILLS_ROOT": "/absolute/path/to/your/skills" }
}
}
}Semantic matching is optional — install Ollama and
ollama pull nomic-embed-text to enable it; otherwise it falls back to
keyword matching automatically.
git clone https://github.com/anujkumar8076/skill-router-mcp
cd skill-router-mcp
npm install && npm run build
SKILLS_ROOT=/path/to/skills node dist/index.jsTool | Purpose |
| All skills — name + description only (cheap, call first) |
| Top-k skills for a task, with 0–1 scores and |
| Full SKILL.md, capped at |
| One H2 section — for skills too big for one fetch |
| Force re-index (a chokidar watcher also auto-reindexes) |
Skills are also served through the MCP Resources primitive per the Skills Over MCP Working Group draft (SEP-2640), so any spec-aware host can consume them without knowing this server's tools:
skill://index.json — enumerable discovery index (Agent Skills discovery
schema 0.2.0)
skill://<name>/SKILL.md — each skill as a text/markdown resource, with
requires/works_in frontmatter exposed under the
io.modelcontextprotocol.skills/ _meta prefix
The io.modelcontextprotocol/skills extension capability is declared at
initialization
Resource reads pass through the same allowlist validation as the tools.
Standard Agent Skills format, with two optional routing fields:
---
name: docx
description: "Use when the user wants to create or edit Word documents."
requires: [filesystem, python] # tools the agent needs to execute this skill
works_in: [claude_code] # environments the skill is known to work in
---
# Instructions...Agents should check requires against their own toolset before loading a
skill — this server delivers instructions; your agent supplies execution.
Env var | Default | Meaning |
|
| Directory scanned (recursively) for |
|
| Token cap on |
|
| Set |
|
|
|
|
| Ollama endpoint for embeddings |
|
| Embedding model ( |
Skill vectors are cached by content hash in
~/.cache/skill-router-mcp/embeddings.json, so restarts and re-indexes only
embed skills whose text changed. If Ollama goes down mid-session, matching
degrades to keyword automatically — routing never hard-fails.
Allowlist, not paths. Skill names are sanitized to [a-z0-9_-], looked
up in an index built at startup, and the resolved file is canonicalized and
verified to live inside SKILLS_ROOT. User input never constructs a path.
Rejected lookups are logged to stderr.
Trust boundary: skill content is injected into your agent's context.
Only point SKILLS_ROOT at skills you trust — a 2026 study of 31k
marketplace skills found ~26% contained prompt-injection or exfiltration
patterns.
Index-time content lint. Every skill is scanned for suspicious
patterns: prompt injection ("ignore previous instructions"), concealment
("don't tell the user"), exfiltration (send-to-URL, known exfil endpoints),
credential access (~/.ssh, .env, API-key harvesting), pipe-to-shell,
decode-and-execute, destructive commands, and opaque base64 blobs.
Findings are logged at index time, shown as lint_warnings in
list_skills, and attached to get_skill responses before the content
so a reviewing agent sees the warning first. The lint flags — it never
blocks — and rules favor precision over recall.
Embedding-based match_skill (local, Ollama nomic-embed-text) behind
the Matcher interface, with content-hash caching + keyword fallback
Routing benchmark: keyword vs. embeddings on a 48-query labeled set — see benchmark/RESULTS.md
Index-time content lint for suspicious skill patterns (10 rules,
surfaced in list_skills and get_skill)
SEP-2640 alignment: skill:// resources, skill://index.json
discovery index, and the skills extension capability
npm test # vitest: security, indexer, matchers, content
npm run build # tsc → dist/
node scripts/smoke.mjs # drive the built server over stdio with real queries
npm run benchmark # keyword vs semantic routing accuracy (needs Ollama)MIT
Load a skill's full SKILL.md instructions (capped at 8000 tokens). If truncated is true, fetch the remaining parts one at a time with get_skill_section using the returned sections list.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Skill name as returned by list_skills or match_skill |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses truncation behavior, token cap, and the returned sections list. It does not mention side effects, but as a read operation, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences with no wasted words. Essential information is front-loaded: what it does, the token cap, and conditional behavior for get_skill_section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description fully explains input (skill name) and output behavior (full instructions or truncated with sections). Completely adequate for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value beyond the schema by explaining token cap and truncation handling. The parameter description in schema is clear, and the tool description enriches context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a skill's SKILL.md instructions with a token cap, and distinguishes it from get_skill_section by specifying when to use the latter for truncated content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells when to use get_skill_section if truncated, providing clear context. However, it does not explicitly say when not to use this tool or mention alternatives like list_skills or match_skill.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single H2 section of a skill by heading name. Use for large skills where get_skill returned truncated: true.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Skill name | |
| section | Yes | H2 heading to fetch (case-insensitive; substring ok) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It implies a read operation but does not disclose idempotency, error handling, or what happens if the section is not found. It lacks depth beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading purpose and usage guidance without any fluff. Every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple parameters and no output schema, the description adequately explains what the tool does and when to use it. However, it does not describe the return format or contents of the section, which would be helpful for an agent to process the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described in the schema (100% coverage), so the description adds minimal extra meaning. The phrase 'by heading name' aligns with the section parameter but does not provide new details beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a single H2 section of a skill by heading name, using specific verbs and resources. It also distinguishes from siblings by mentioning the truncated scenario, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Use for large skills where get_skill returned truncated: true.' This directly guides the agent to choose this over get_skill or other siblings in that context, with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available skills (name + one-line description only). Cheap to call; use before match_skill or get_skill.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses that it is cheap to call and returns only name + one-line description, implying no side effects. Could be more explicit about read-only nature, but sufficient for a simple list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no params and no output schema, description fully covers what the tool does, what it returns, and when to use it. Sibling list aids context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema is empty. Description adds value by specifying what fields are returned (name + one-line description), which is not in the schema. Baseline is 4 for 0 parameters, and description meets it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List all available skills (name + one-line description only)', specifying verb, resource, and scope. Distinguishes from siblings by noting output brevity and referencing match_skill and get_skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Cheap to call; use before match_skill or get_skill', providing clear when-to-use context and suggesting sibling tools for more detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the best skills for a task. Returns top matches with a 0-1 confidence score and the tools each skill requires. Check requires against your own available tools before loading a skill.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The task to find a skill for, e.g. 'create a word document' | |
| top_k | No | How many matches to return (default 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses output format (confidence score, tools) and a behavioral instruction to verify tool availability. This is sufficient for a read-only search tool, though it could mention behavior for no matches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each serving a distinct purpose: first explains what the tool does and returns, second provides actionable guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 simple parameters, no output schema, and no annotations, the description adequately covers purpose, output, and a usage hint. It lacks details on edge cases but is complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (100% coverage). The description adds only an example for query. Baseline 3 is appropriate as schema already explains parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds best skills for a task and returns confidence scores and required tools. This distinguishes it from siblings like get_skill (retrieve specific) and list_skills (list all).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: to find skills for a task. It also gives a post-invocation guideline to check required tools before loading. However, it lacks explicit comparison to siblings or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force an immediate re-index of the skills directory. Use if skills were added or changed and the index looks stale.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral traits. It states 'Force an immediate re-index' implying a potentially resource-intensive operation but does not disclose side effects, such as whether the index becomes temporarily unavailable or if the operation is idempotent. More detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence clearly states the action, and the second provides guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is minimally adequate. However, it lacks information about the return value (e.g., success confirmation) and any potential impacts on other operations. A more complete description would mention whether the call is synchronous or asynchronous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100%. The description adds value beyond the schema by explaining the purpose and use case, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Force an immediate re-index') and clearly identifies the resource ('skills directory'). It distinguishes itself from sibling tools like 'get_skill' and 'list_skills' by focusing on re-indexing rather than retrieval or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use if skills were added or changed and the index looks stale.' This provides clear context, though it does not mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_skillget_skill_sectionlist_skillsmatch_skillrescan_skillsScored across 5 tools
Each tool has a clearly distinct purpose: listing skills, fetching full skill content, fetching sections, matching skills to tasks, and re-indexing. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern with snake_case (get_skill, get_skill_section, list_skills, match_skill, rescan_skills), making them predictable.
5 tools is well-scoped for a skill router: listing, fetching, section retrieval, matching, and re-indexing. Each tool earns its place without redundancy.
Covers all essential operations for skill management: discovery (list_skills), retrieval (get_skill, get_skill_section), intelligent selection (match_skill), and maintenance (rescan_skills). No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Governed AI agent skills — one library, distributed to devs and exposed to remote agents over MCP.
Sharebench — search & pull AI skills, agents, prompts & playbooks (SKILL.md) into any MCP client
Hosted MCP server for live public-data APIs and Skills for AI agents.
Search & install 6,500+ AI agent skills from skills-hub.ai inside any MCP tool.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/anujkumar8076/skill-router-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
