Skip to main content
Glama
skillselion

Skillselion MCP server

Official
by skillselion
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

🚀 Install

Claude Code - one line:

claude mcp add skillselion --scope user -- npx -y skillselion-mcp

Claude Desktop / Cursor / Codex - add to your MCP config:

{ "mcpServers": { "skillselion": { "command": "npx", "args": ["-y", "skillselion-mcp"] } } }

No build step, no auth, no API key. One ~30 KB file via npx.

Want it fully automatic? npx -y skillselion-mcp setup registers the server and installs a session hook so your agent loads the right skill the moment a task matches - see Skill autopilot.

Related MCP server: SkillHub MCP

🔧 Tools

Tool

What it does

📥 load_skill

The everyday default: finds the best-matching skill for your task and materializes it - real SKILL.md in context + bundled scripts/references on disk - so the agent follows it like an installed skill. Returns ranked runner-ups you can switch to.

🧬 synthesize_skills

The cross-source playbook: merges the key rules of the top ~5 matching skills into one deduped, provenance-tagged digest - the field's consensus, not one author's take.

🔍 search_skillselion

Search the catalog by keyword or task; filter by skill / mcp / marketplace.

🏆 top_skillselion

The leaderboard - the most-installed skills and top-starred MCP servers right now.

🔒 Private by default

Read-only, no auth, no secrets. It never sends your code, files, or the context you pass - only a scrubbed search query + which skill matched, so the catalog learns what to add next. Set DO_NOT_TRACK=1 to disable even that.

🪄 Skill autopilot

npx -y skillselion-mcp setup        # interactive - pick your packs
npx -y skillselion-mcp setup --yes  # non-interactive - agents / CI

Registers the MCP globally and installs a Claude Code SessionStart hook that primes every session with skills relevant to you - so loads happen on their own.

Flag

What it does

--packs <a,b,…>

one or more packs (or all), e.g. --packs frontend,backend; frontend:6 sets a per-pack count

--per-pack N

skills per pack (default 3) · --top N sets the popular count

--auto

adapt each session to the current repo's stack

--history

infer your focus from Claude Code / Codex history (one-time scan)

--yes

never prompt (default when there's no terminal)

Packs: popular (default) · frontend · ai-agents · media · backend · devops · quality · automation.

Safe by design: ~/.claude/settings.json is merged, never clobbered; re-running de-dupes and upgrades the hook in place.

Var

Default

What it controls

GITHUB_TOKEN

-

optional, read-only; raises GitHub's rate limit for full multi-file skill loads (60 → 5000 req/hr)

SK_INLINE_BUDGET

6000

char cap on the in-context SKILL.md portion (the full skill is always on disk)

SK_SYNTH_N

5

how many top skills synthesize_skills merges (2-8)

SK_SYNTH_PER_SKILL

12

max rules kept per source skill

SK_SYNTH_BUDGET

4000

char cap on the merged digest

DO_NOT_TRACK

-

set 1 to disable the anonymous demand signal

The agent doesn't see the tools. Some clients surface MCP tools lazily - tell the agent to search its tools for "skillselion" first (e.g. ToolSearch), then call it. The setup hook automates this nudge.

load_skill returns only the SKILL.md, no bundled files. You hit GitHub's unauthenticated 60 req/hr limit - set a read-only GITHUB_TOKEN in the server's env.

"No skill on Skillselion clearly matches..." The relevance floor working as intended - nothing topical matched, so it refuses to waste your context. Try a more specific query.

Setup couldn't auto-register. Run the printed claude mcp add ... line yourself.

npm install
npm test           # offline: server boots, tools, synthesis
npm run test:live  # live catalog + GitHub (set GITHUB_TOKEN)

⭐ Like it?

  • Star the repo - it helps other developers find it.

  • Browse the full catalog → skillselion.com - thousands of skills, MCP servers & marketplaces, ranked by real installs.

  • Bug or missing skill? Open an issue - PRs welcome.

📄 License

MIT © Skillselion

Available Tools

4 tools
load_skillA

Load a community-vetted skill into your context on demand - like installing it mid-task. Reach for this when a task is in a domain a skill likely covers (tests, frontend/UI, an API/DB, infra, a named framework) and a proven recipe would beat improvising - most valuable in territory you are less sure of, or fast-moving stacks where your memory may be stale. You MUST pass context (your task + stack + constraints): it ranks candidates, fits them to your current repo, flags dependency mismatches, and keeps the load deliberate. Returns the best match (real SKILL.md + bundled scripts/refs materialized to a temp folder, used like an installed skill) PLUS the next-best candidates so you can switch. Always verify the loaded skill against your project before trusting it. For broad "current best practices across the field" tasks that span several skills, use synthesize_skills instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
idNoAn exact skill id from search_skillselion, e.g. "skill:owner/repo#slug".
queryNoWhat you need - task/skill keywords (e.g. "playwright e2e tests"). Required unless you pass an exact id.
contextYesREQUIRED. What you are actually doing + your stack + constraints/anti-patterns (e.g. "Next.js marketing page, no new deps, role-based locators"). Ranks candidates, fits them to your repo, and flags dependency mismatches. Be specific - this also keeps the load deliberate, not reflexive.

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It describes the return (best match + next-best candidates), materialization to a temp folder, and warns to verify. It also explains the purpose of context. Could mention if any mutations occur, but likely not needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat long but well-structured: first sentence gives purpose, then usage guidelines, then parameter details, then warning. All sentences add value. Could trim slightly but no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, no output schema, and no annotations, the description covers the tool's behavior thoroughly: explains what the tool does, how context is used, what is returned, and a verification warning. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds significant meaning beyond schema: context 'ranks candidates, fits them to your repo, flags dependency mismatches'. Also provides example values for parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the purpose: 'Load a community-vetted skill into your context on demand'. It uses a specific verb ('load') and resource ('skill'), and distinguishes from siblings by mentioning 'synthesize_skills' for broad tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on when to use ('when a task is in a domain a skill likely covers...') and when not ('For broad... tasks that span several skills, use synthesize_skills instead'). Also specifies the context parameter's role.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_skillselionA

Search Skillselion, a curated directory of Claude Code agent skills, MCP servers and plugin marketplaces, ranked by real community signal (installs + GitHub stars). Use to browse trusted skills/MCPs/marketplaces for the task at hand (e.g. "postgres", "code review", "playwright"). To actually USE a skill, call load_skill (with an id from here, or directly with a query - it searches for you).

ParametersJSON Schema
NameRequiredDescriptionDefault
typeNoRestrict to one listing type. Omit to search all.
limitNoMax results (default 8).
queryYesWhat to search for - a tool, framework, task, or keyword.

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden of disclosing behavior. It mentions ranking by community signal but does not explicitly state that the tool is read-only or non-destructive. While search is inherently safe, the description could be more transparent about side effects or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading the purpose and key features. Every sentence adds distinct value: first sentence explains what is searched and ranking, second gives usage examples and links to sibling tool. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, no output schema, and no annotations, the description is sufficiently complete. It covers the tool's purpose, usage context, and integration with a sibling tool. The lack of return value description is acceptable as no output schema exists, but additional behavioral details could improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all three parameters. The description adds value by explaining that 'query' can be a tool, framework, task, or keyword, and that 'type' restricts to one listing. It also provides context on ranking, which enhances understanding of results, though it doesn't directly enrich parameter definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Search' and the resource 'Skillselion directory' of skills, MCPs, and marketplaces. It differentiates from 'load_skill' by specifying that browsing is for searching, not using. However, it does not explicitly distinguish from 'synthesize_skills' or 'top_skillselion'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: 'Use to browse trusted skills/MCPs/marketplaces for the task at hand' and when to call 'load_skill' instead. Example queries are given. It does not mention alternatives for other sibling tools, but the core use case is covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

synthesize_skillsA

Pull the BEST rules across the top matching community skills and merge them into one cross-source playbook - use for broad "how should I approach X / current best practices" tasks that span multiple skills, or when you want the field's combined guidance rather than one skill's. For a single specific skill (and its bundled scripts/files), use load_skill instead. Pass your task as query and your stack + constraints as context (required). Returns a deduped, provenance-tagged rule digest plus each source skill materialized on disk.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe topic/task to synthesize across skills (e.g. "playwright e2e testing best practices").
contextYesREQUIRED. What you are actually doing + your stack + constraints. Ranks candidates and fits them to your repo.

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It discloses that the tool pulls top matching skills, merges them, deduplicates, returns a provenance-tagged digest, and materializes source skills on disk. This is transparent, though it could mention how 'top matching' is determined.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficient and front-loaded, starting with the core action and then providing usage context, alternatives, parameter guidance, and output summary. It is succinct but could be slightly more streamlined.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately explains the return format (deduped, provenance-tagged digest plus materialized files) and input parameters. For a tool with two simple required parameters and no nested objects, this is fairly complete. It does not detail the selection criteria for 'top matching,' but that is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds minor clarification by explaining how to use each parameter (e.g., 'pass your task as query and your stack + constraints as context'), which is helpful but not essential beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: pulling the best rules from top community skills and merging them into a cross-source playbook. It specifies the action (synthesize/merge), resource (skills), and scope (broad tasks), and distinguishes from sibling load_skill.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes when to use (broad 'how should I approach X' tasks spanning multiple skills) and when not to (single skill -> use load_skill). Also clarifies required parameters and their roles.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

top_skillselionA

List the top entries on Skillselion (the leaderboard), optionally by type. Skills rank by installs; MCP servers and marketplaces by GitHub stars.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeNoRestrict to one listing type. Omit for all.
limitNoMax results (default 10).

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description reveals ranking criteria (installs, stars) but omits details like data freshness, pagination, or side effects. Adequate for a read-only list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, followed by ranking specifics. No superfluous words; each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple listing tool with 2 params and no output schema, the description provides key behavior and ranking details. Could hint at default limit or result structure, but sufficient for basic usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds value by explaining how the 'type' parameter affects ranking (installs vs stars), which is beyond the schema's enum listing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool lists top entries on Skillselion leaderboard, with optional type filtering. Distinguishes from siblings like load_skill, search_skillselion, and synthesize_skills by focusing on leaderboard rankings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for fetching top entries but does not explicitly state when to use vs alternatives. No when-not or exclusion guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.9.6
    • First observedload_skill
    • First observedsearch_skillselion
    • First observedsynthesize_skills
    • First observedtop_skillselion
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 4 tools

Disambiguation4/5

Tools are mostly distinct: load_skill installs a skill, search_skillselion browses, synthesize_skills merges multiple, top_skillselion lists. However, load_skill also performs a search via query, which may cause confusion with search_skillselion. Descriptions help differentiate but some overlap remains.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with lowercase and underscores: load_skill, search_skillselion, synthesize_skills, top_skillselion. The naming is predictable and uniform.

Tool Count5/5

Four tools is well-scoped for a skill marketplace consumer: search, load, synthesize, and list top. Each tool serves a distinct purpose without redundancy or unnecessary proliferation.

Completeness4/5

The tool surface covers core consumer workflows: browsing, loading, and aggregating skills. Minor gaps exist (e.g., no direct metadata-only retrieval) but agents can work around via search and load.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • claude-oracle-mcp

    Vvkmnn
    A
    license
    A
    quality
    D
    maintenance
    An MCP server for discovering Claude Code skills, plugins, and MCP servers by searching 15,000+ resources from 17 registries, GitHub, and the web with zero setup.
    3
    46 npm
    3
    MIT

  • SkillHub MCP

    artuntan
    A
    license
    A
    quality
    C
    maintenance
    Enables AI assistants to search, discover, and get recommendations from 20,000+ skills, tools, agents, rules, and MCP servers.
    5
    15 npm
    1
    MIT

  • remoteopenclaw-mcp

    aidevelopers2
    A
    license
    A
    quality
    C
    maintenance
    Enables AI agents to search a directory of 13,870+ MCP servers, 4,384+ agent skills, and plugins from Remote OpenClaw, returning install commands directly.
    3
    31 npm
    4
    MIT