Allows the fetching of skill documentation and repository content directly from GitHub repositories to provide AI agents with immediate access to community-made instructions and code 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., "@skills-master-mcp find and read a skill for converting markdown to PDF"
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.
A Plug & Play MCP server that connects your AI coding agent to the SkillsMP marketplace - 8,000+ community-made skills.
You can search for skills, easily install them (to ~/.claude/skills/) or read them directly into your agent's context (without installing).
No API key needed.
One command to set up.
The key idea is to help lazy people like me to use skills more often, and save time and tokens for our dear agents.
Related MCP server: mcp-skills
Here’s a real use case: converting a Markdown file to PDF.
You can either have the agent learn how to do it via web search, or simply import the skill.
Super efficient and fast.
You: "I need to convert README.md to a PDF"
Agent: searches SkillsMP for "markdown to pdf"
→ finds a skill for it
→ reads the SKILL.md content from GitHub
→ now has the full instructions in context
Agent: "I found a skill for this. It uses Puppeteer to render
the markdown and save it as PDF. Let me do that now."
...converts your file using the skill's instructions.
You: ":))))"The skill was never installed to your ~/.claude/skills
The agent just read it, learned the approach, and executed it.
One-shot use.
If you want a skill permanently, you can install it too:
You: "Install that markdown-to-pdf skill for Claude Code"
Agent: runs install_skill
→ skill is now saved to .claude/skills/
→ available in every future conversationNo API key
No .env
No configuration
Just install and run
claude mcp add skills-master -- npx skills-master-mcpAdd to .cursor/mcp.json:
{
"mcpServers": {
"skills-master": {
"command": "npx",
"args": ["skills-master-mcp"]
}
}
}npx skills-master-mcpTool | Input | Output |
| keywords (e.g., | List of matching skills with name, author, stars, links |
| plain English (e.g., | Semantically relevant skills ranked by relevance |
| GitHub owner + repo + path | The skill's full SKILL.md content, loaded into agent context |
| GitHub source + skill names + target agents | Skill permanently saved to agent's skills directory |
| skill names | Deletes the skill files from agent's skills directory |
searchParameter | Type | Default | Description |
| string | required | Search terms |
| number |
| Page number |
| number |
| Results per page (max: 100) |
| string |
|
|
| string |
|
|
ai_searchParameter | Type | Default | Description |
| string | required | Natural language query |
| string |
|
|
read_skillParameter | Type | Default | Description |
| string | required | GitHub user/org |
| string | required | Repository name |
| string | — | Path to skill folder |
| string |
| Git branch |
install_skillParameter | Type | Default | Description |
| string | required | GitHub |
| string | required | Skill names (comma-separated) |
| string | required | Target agents (comma-separated) |
| boolean |
| Install globally (user-level) |
remove_skillParameter | Type | Default | Description |
| string | required | Skill names to remove (comma-separated) |
| string |
| Target agent |
| boolean |
| Remove from global scope |
Agent | Install | Remove |
Yes | Yes | |
Yes | Yes | |
Yes | — | |
Yes | — | |
Yes | — | |
Yes | — | |
Yes | — |
Your AI Agent
│
▼
skills-master-mcp (local, via npx)
├── search / ai_search ──▶ Proxy Backend ──▶ SkillsMP API
├── read_skill ──────────▶ GitHub (direct)
├── install_skill ───────▶ npx add-skill
└── remove_skill ────────▶ Local file deletionSearch requests go through a proxy backend so you don't need an API key. Everything else is direct.
Nothing to configure. Optional env vars for advanced use:
Variable | Default | Description |
| Production URL | Override backend endpoint |
|
|
|
|
| HTTP port (when |
MIT
Semantic search for skills using natural language queries. Powered by AI to understand intent.
Use this when keywords aren't enough - describe what you want to accomplish.
Parameters:
query: Natural language query (e.g., "How to build REST APIs with authentication")
Examples: "tools for web scraping", "help with React testing", "automate deployments"
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language query for AI semantic search (e.g., 'How to create a web scraper', 'tools for SEO optimization') | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide comprehensive behavioral hints (read-only, non-destructive, idempotent, open-world), so the bar is lower. The description adds valuable context beyond annotations by explaining the AI-powered semantic nature and intent understanding, which helps the agent anticipate how queries are processed. No contradictions with annotations exist.
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 well-structured and front-loaded with the core purpose, followed by usage guidelines, parameters, and examples. Every sentence earns its place without redundancy, making it efficient and easy for an agent to parse quickly.
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 the tool's moderate complexity, rich annotations covering safety and behavior, and 100% schema coverage, the description is mostly complete. It lacks details on output format or result structure, but since there's no output schema, this is a minor gap. The description adequately complements the structured data for agent 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 description coverage is 100%, providing detailed parameter documentation. The description adds minimal value beyond the schema, only mentioning the 'query' parameter with examples but not elaborating on 'response_format'. Since the schema does the heavy lifting, 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 purpose with specific verbs ('semantic search for skills') and resources ('skills'), distinguishing it from sibling tools like 'search' by emphasizing AI-powered natural language understanding. It explicitly mentions the AI component and natural language queries, which differentiates it from keyword-based alternatives.
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 guidance on when to use this tool ('Use this when keywords aren't enough - describe what you want to accomplish'), offering a clear alternative scenario (keyword-based search) and distinguishing it from the sibling 'search' tool. It effectively tells the agent when this tool is preferred over other search methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install skills from GitHub to AI coding agents.
Parameters:
source: GitHub "owner/repo" (e.g., "anthropics/claude-code") [REQUIRED]
skills: Skill names, comma-separated (e.g., "frontend-design,backend-dev") [REQUIRED]
agents: Target agents, comma-separated [REQUIRED] Valid: claude-code, cursor, codex, opencode, antigravity, github-copilot, roo
global: Installation scope [REQUIRED] true = user-level install to ~/.claude/skills (available across all projects) false = project-level install to ./.claude/skills (only this project)
Example: source="anthropics/claude-code", skills="frontend-design", agents="claude-code", global=false
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Full path to skill: 'owner/repo/path/to/skill' (e.g., 'openclaw/skills/skills/araa47/md-2-pdf') or GitHub URL | |
| skills | Yes | Skill names to install (comma-separated: 'skill1,skill2' or array). REQUIRED. | |
| agents | Yes | Target agents (comma-separated: 'claude-code,cursor'). Valid: opencode, claude-code, codex, cursor, antigravity, github-copilot, roo. REQUIRED. | |
| global | Yes | Installation scope - REQUIRED. Set to true for user-level (~/.claude/skills) or false for project-level (./.claude/skills) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds some behavioral context by explaining the installation scope implications (user-level vs project-level) and listing valid agent values. However, it doesn't describe important behavioral aspects like what happens on failure, whether installations are reversible, or how the tool interacts with existing skills. The description doesn't contradict annotations.
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 well-structured with a clear opening statement followed by organized parameter explanations and a complete example. Each sentence serves a purpose, though the parameter explanations could be slightly more concise. The information is front-loaded with the core purpose stated first. Minor verbosity in parameter formatting prevents a perfect score.
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 4-parameter mutation tool with no output schema, the description provides adequate but incomplete context. It covers parameter usage well but lacks information about return values, error conditions, or what constitutes successful installation. The annotations provide safety profile (non-destructive, non-idempotent), but the description doesn't fully compensate for the missing output schema by explaining expected results.
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?
With 100% schema description coverage, the baseline is 3. The description adds meaningful value by providing concrete examples (e.g., 'anthropics/claude-code' for source, 'frontend-design,backend-dev' for skills), clarifying the format of comma-separated values, and explaining the boolean meaning of 'global' parameter with specific path implications. The description enhances understanding beyond the schema's technical specifications.
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 purpose with specific verb ('Install') and resource ('skills from GitHub to AI coding agents'). It distinguishes from sibling tools like 'read_skill' and 'remove_skill' by specifying installation rather than reading or removal. The opening sentence provides immediate clarity about what the tool does.
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 implies usage context through parameter explanations (e.g., 'global' parameter defines installation scope), but doesn't explicitly state when to use this tool versus alternatives like 'remove_skill' or 'read_skill'. No explicit guidance is provided about prerequisites, error conditions, or when not to use this tool. The example shows typical usage but doesn't provide comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read skill file content (SKILL.md) from a GitHub repository. Use to preview a skill before installing.
Parameters:
owner: GitHub username/org (e.g., "anthropics")
repo: Repository name (e.g., "claude-code")
path: Path to skill folder (e.g., "plugins/frontend-design/skills/frontend-design")
branch: Git branch (default: "main")
If path has no skill.md, returns directory listing.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | GitHub repository owner (e.g., 'davila7') | |
| repo | Yes | GitHub repository name (e.g., 'claude-code-templates') | |
| path | No | Path to skill within repo (e.g., 'cli-tool/components/skills/development/senior-prompt-engineer'). If not provided, lists available skills. | |
| branch | No | Git branch (default: 'main') | main |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it specifies what happens when the path has no skill.md ('returns directory listing'), which is not inferable from annotations alone. However, it doesn't mention rate limits or authentication needs.
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 front-loaded with the core purpose in the first sentence, followed by usage guidance and parameter details. Every sentence earns its place: the first states what it does, the second when to use it, and the parameter section clarifies behavior and defaults. 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?
For a read-only tool with comprehensive annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) and full schema coverage, the description is mostly complete. It explains the tool's purpose, usage context, and fallback behavior. However, without an output schema, it could benefit from more detail on return values (e.g., format of directory listing).
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 the schema already fully documents all parameters. The description repeats parameter names and provides examples (e.g., 'anthropics', 'claude-code'), but doesn't add significant semantic meaning beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.
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 verb ('Read') and resource ('skill file content (SKILL.md) from a GitHub repository'), distinguishing it from sibling tools like install_skill and remove_skill. It specifies the exact file being read (SKILL.md) and the source (GitHub repository), making the purpose unambiguous.
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 to preview a skill before installing'), providing clear context for its application. It also distinguishes from alternatives by focusing on previewing rather than installing or removing skills, which are handled by sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove installed skills from an AI coding agent.
Parameters:
skills: Skill names to remove (comma-separated: 'skill1,skill2'). REQUIRED.
agent: Agent to remove from (default: 'claude-code') Valid: claude-code, cursor, codex, opencode, antigravity, github-copilot, roo
global: Removal scope [REQUIRED] true = remove from user-level ~/.agents/skills (global install) false = remove from project-level ./.agents/skills (project install)
Removes the skill directory and associated symlinks from the agent's skills directory.
| Name | Required | Description | Default |
|---|---|---|---|
| skills | Yes | Skill names to remove (comma-separated: 'skill1,skill2' or array). REQUIRED. | |
| agent | No | Agent whose skills to remove (default: 'claude-code') | claude-code |
| global | Yes | Removal scope - REQUIRED. Set to true for user-level (~/.claude/skills) or false for project-level (./.claude/skills) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive (true) and idempotent (true) operations, but the description adds valuable behavioral context: 'Removes the skill directory and associated symlinks from the agent's skills directory' clarifies what gets destroyed and the scope of removal. It doesn't contradict annotations and provides implementation details beyond the structured hints.
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 well-structured with a clear purpose statement followed by parameter explanations and implementation details. While somewhat verbose in repeating schema information, every sentence contributes to understanding. It could be more front-loaded by moving the 'Removes the skill directory...' sentence earlier.
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 destructive tool with good annotations and full schema coverage, the description provides adequate context about what gets removed and scope implications. Without an output schema, it doesn't describe return values, but the operational details are sufficiently covered for the tool's complexity level.
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?
With 100% schema description coverage, the schema already documents all parameters thoroughly. The description repeats parameter information (skills format, agent options, global scope meaning) but doesn't add significant semantic value beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('Remove installed skills') and target resource ('from an AI coding agent'), distinguishing it from siblings like 'install_skill' and 'read_skill'. It provides a complete operational picture beyond just the tool name.
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 implies usage context through parameter explanations (global vs project scope, agent selection) but doesn't explicitly state when to use this tool versus alternatives like 'read_skill' or 'install_skill'. No explicit guidance on prerequisites or when-not-to-use scenarios is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search SkillsMP marketplace for AI coding skills by keywords.
Parameters:
query: Search terms (e.g., "fastapi", "react testing")
page: Page number (default: 1)
limit: Results per page (default: 20, max: 100)
sort_by: "stars" (default) or "recent"
Returns skills with name, description, author, stars, and GitHub URL.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for skills (e.g., 'SEO', 'web scraper', 'data analysis') | |
| page | No | Page number for pagination | |
| limit | No | Items per page (default: 20, max: 100) | |
| sort_by | No | Sort results by: 'stars' (default) or 'recent' | stars |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and behavior. The description adds context about the marketplace scope and return format (skills with name, description, author, stars, GitHub URL), but does not disclose additional traits like rate limits, authentication needs, or pagination details beyond what annotations imply.
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 appropriately sized with two paragraphs: one for purpose and one for parameters/returns. It is front-loaded with the main purpose, but could be more concise by integrating parameter details more seamlessly rather than a separate list.
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 the tool's moderate complexity (5 parameters, 100% schema coverage, annotations covering key behaviors, no output schema), the description is mostly complete. It explains the purpose, parameters, and return values, though it could benefit from more usage guidance relative to siblings.
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 the schema fully documents all 5 parameters. The description lists parameters with examples and defaults, but adds minimal meaning beyond the schema (e.g., 'query' example 'fastapi', 'react testing' is similar to schema's 'SEO', 'web scraper'). Baseline 3 is appropriate as the schema does the heavy lifting.
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 searches the 'SkillsMP marketplace for AI coding skills by keywords', specifying both the action (search) and resource (AI coding skills in SkillsMP marketplace). It distinguishes from sibling tools like 'install_skill', 'read_skill', and 'remove_skill' which perform different operations on skills, and from 'ai_search' which likely has a different scope or method.
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 implies usage for searching skills by keywords, but does not explicitly state when to use this tool versus alternatives like 'ai_search' or other siblings. It provides context for searching the marketplace but lacks explicit guidance on exclusions or comparisons with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes: ai_search and search both handle searching but differ in approach (semantic vs keyword-based), while install_skill, read_skill, and remove_skill clearly manage skill lifecycle. The overlap between ai_search and search creates minor ambiguity, but their descriptions help differentiate them.
Tools follow a consistent verb_noun pattern with snake_case throughout (ai_search, install_skill, read_skill, remove_skill, search). The only deviation is 'ai_search' versus 'search' where the prefix clarifies the semantic approach, maintaining overall readability.
With 5 tools, this server is well-scoped for managing AI coding skills. It covers core operations: discovery (two search tools), installation, inspection, and removal. Each tool earns its place without bloat, fitting typical server scope expectations.
The toolset provides strong coverage for skill management: discover, preview, install, and remove. A minor gap exists in updating or modifying installed skills, but agents can work around this by removing and reinstalling. Core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search & install 6,500+ AI agent skills from skills-hub.ai inside any MCP tool.
AgentPMT is the AI agent marketplace that turns any MCP-compatible AI assistant into an autonomous employee. Connect once and your agents gain access to a growing ecosystem of tools, workflows, and skills spanning communication, data analytics, development, file management, search, and more. AgentPMT dynamically discovers and orchestrates tools from across the MCP ecosystem, so your agents can independently find the right tool for any task without manual configuration.
Agent-first skill marketplace with USK open standard for Claude, Cursor, Gemini, Codex CLI.
One place to build, share, and govern the skills and tools your AI agents use at work.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/adarc8/skills-master-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
