Click on "Deploy 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., "@skills.sh MCP Server search for a markdown editor skill"
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.
An unofficial Model Context Protocol (MCP) server for the skills.sh ecosystem. This server empowers your AI agents (like Claude Code, Antigravity-cli, or Cursor) to autonomously search, evaluate, and install the most relevant skills directly from the skills.sh catalog.
📦 NPM Package: skills-mcp-server
Zero-Config & No Auth: Uses public endpoints—no Vercel tokens or API keys required.
AI-Native & Self-Documenting: Natively embeds detailed workflow instructions via MCP Prompts and Resources so your LLM always knows exactly how to search effectively.
4 Powerful Tools:
search_skills: Semantic search through the catalog.
get_skill_details: Deep-dive analytics (installs, platforms, history).
get_popular_skills: Discover trending and hot skills.
get_install_command: Instantly generate npx installation commands.
Related MCP server: skills-master-mcp
You can install this directly into Claude Code with a single command:
claude mcp add skills-sh -- npx -y skills-mcp-serverAdd the following to your MCP client configuration (e.g., claude_desktop_config.json):
{
"mcpServers": {
"skills-sh": {
"command": "npx",
"args": [
"-y",
"skills-mcp-server"
]
}
}
}If you prefer not to use npx every time, you can install it globally:
npm install -g skills-mcp-serverThen use skills-mcp-server as your command instead of npx.
If you prefer to run the server locally:
Clone this repository.
Install dependencies: npm install
Build the project: npm run build
Add the absolute path to your MCP client config:
{
"mcpServers": {
"skills-sh": {
"command": "node",
"args": [
"/absolute/path/to/your/skills-mcp-server/build/index.js"
]
}
}
}This server is designed to be fully self-documenting for LLMs.
When your agent connects, it automatically gains access to:
Rich Tool Descriptions: Tools contain explicit instructions telling the LLM to generate diverse keywords, loop searches, and thoroughly vet results before recommending them.
MCP Resources: Exposes a skills-sh://agent-instructions resource. Advanced clients can automatically read this to understand the full step-by-step searching workflow.
MCP Prompts: Exposes a skills-search-workflow prompt. Users can invoke this manually in supported clients to force the LLM into a highly optimized "Skill Search Mode".
Core API discovery and initial implementation credit goes to brandonqr/skillsh-mcp.
Get the npx install command for a skill
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repository name | |
| owner | Yes | GitHub owner/username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It does not mention whether the operation is read-only, requires authentication, what the return format is, or any side effects. The word 'get' implies a read, but this is not explicit.
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 a single, front-loaded sentence that is concise and to the point. It contains no filler or redundant information, achieving maximum clarity with minimal 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?
The tool is simple with only two required parameters and no output schema. However, the description does not specify the exact return format or any error conditions. It is minimally adequate but leaves room for additional clarity.
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 description coverage is 100%, with both 'repo' and 'owner' clearly described. The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
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's specific function: retrieve the npx install command for a skill. This is a distinct action from sibling tools like search_skills, get_skill_details, and get_popular_skills, making it easily distinguishable.
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?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does without mentioning when it should be chosen over get_skill_details or other siblings, nor does it offer any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get popular skills from the leaderboard
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results (default: 20) | |
| timeframe | No | Timeframe: "all", "trending", or "hot" | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure, but it only states the action and source. It does not disclose whether this is a read-only operation, how results are ordered, pagination behavior, or any side effects. Minimal behavioral context 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 a single sentence with no filler, making it highly concise. However, it is under-specified in content, leaving out relevant context that could be added without adding wordiness.
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?
This simple tool with two optional parameters and no output schema still lacks important context in the description. It does not explain return format, how 'popular' is defined, the impact of timeframe, or the overall purpose relative to other skills tools. The description is barely above a stub.
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 input schema already has 100% coverage for both parameters (limit and timeframe) with descriptions and defaults. The description adds no parameter-specific detail, so the baseline of 3 applies.
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 states a clear action and resource: 'Get popular skills from the leaderboard.' This distinguishes it from siblings like search_skills and get_skill_details by implying a ranked leaderboard source, but it doesn't explicitly differentiate or mention what makes skills 'popular.'
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 no guidance on when to use this tool versus alternatives. It does not mention sibling tools, scenarios where this is appropriate, or exclusions. The usage context is only implied by the phrase 'from the leaderboard.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific skill. Use this tool ALWAYS after 'search_skills' to vet a skill before recommending it. It provides critical data like total installs, weekly installs, and supported platforms. Extract 'owner', 'repo', and 'skillId' from the search results table.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repository name | |
| owner | Yes | GitHub owner/username | |
| skillId | Yes | Skill ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool provides 'critical data like total installs, weekly installs, and supported platforms,' but does not explicitly state it is read-only or disclose other behavioral traits like rate limits. Adequate but not exhaustive.
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?
Three sentences, front-loaded with purpose. Concise with no wasted words, though it could be slightly more compressed without losing clarity.
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 output schema, the description sufficiently explains the kind of data returned (installs, platforms). Combined with high schema coverage, it provides a complete picture for a simple retrieval tool.
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%, so parameters are already described. The description adds value by instructing to 'Extract owner, repo, and skillId from the search results table,' which clarifies source and usage beyond schema definitions.
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 'Get detailed information about a specific skill,' which is a specific verb+resource. It distinguishes from siblings by instructing to use after 'search_skills' and naming sibling tools.
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 'Use this tool ALWAYS after search_skills to vet a skill before recommending it,' providing clear context of when to use and a prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for skills on skills.sh by query term.
CRITICAL WORKFLOW FOR AI AGENTS:
Parse user intent and generate 3-5 diverse keywords (e.g., for "scrape websites", use "web scraping", "puppeteer", "crawler").
Call this tool multiple times with different keywords if the first results are poor.
DO NOT recommend a skill immediately. You MUST use 'get_skill_details' on top candidates to check their install counts and platforms first.
Recommend the top 1-3 skills and provide the npx install command.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (default: 50) | |
| query | Yes | Search query term |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read operation ('search') but does not detail behavior such as pagination, result structure, or any limitations. The workflow guidance adds some context, but core behavioral traits are missing.
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 concise, with a clear lead sentence followed by bullet points. Every sentence serves a purpose, though the 'CRITICAL WORKFLOW' section makes it slightly longer than minimal but well-structured.
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 two parameters and no output schema, the description covers purpose and usage well but lacks details about the return format or what to expect from results. It is adequate for basic usage but not fully complete.
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 description coverage is 100%, so both parameters (query, limit) are documented in the schema. The description does not add extra meaning beyond the schema's descriptions, meeting the baseline for high coverage.
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 it 'search[es] for skills on skills.sh by query term', providing a specific verb and resource. It distinguishes itself from sibling tools like get_skill_details and get_popular_skills by focusing on query-based 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 provides explicit workflow steps, including generating multiple keywords, calling the tool multiple times, and using get_skill_details before recommending skills. It clearly contrasts with sibling tools by guiding when to use each.
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.
v1.0.4get_install_commandget_popular_skillsget_skill_detailssearch_skillsScored across 4 tools
Each tool has a clearly distinct purpose: searching, getting details, retrieving install commands, and viewing popular skills. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_install_command, search_skills), making them predictable and easy to understand.
With 4 tools covering search, details, install commands, and popular skills, the set is well-scoped for a skill discovery and installation server—neither too sparse nor excessive.
The tools provide a complete workflow: search for skills, examine details, retrieve install commands, and browse popular skills. No obvious gaps for the stated purpose.
Find, inspect and install reviewed reusable AI-agent capabilities from superskill.sh.
Search & install 6,500+ AI agent skills from skills-hub.ai inside any MCP tool.
Search your team's shared AI-skill library, get install commands, and save skills from your agent.
Search, fetch, lint, and install Agent Skills (SKILL.md) from the SkillMD registry.
