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 MCP search for skills that can help me analyze PDF documents"
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.
The Package Manager for AI Agents.
Skills MCP connects your LLM Agent (like Claude Desktop or Claude Code) to a global registry of capabilities. It allows your Agent to autonomously discover, install, and learn new skills to solve complex tasks.
Thin MCP, Fat Agent Philosophy: This tool handles the delivery of code and instructions, empowering the Agent to execute them using its own environment (e.g.,
uv,bash).
Search: Find skills for specific tasks (e.g., "pdf", "excel", "diagram").
Install: One-click download and installation to your local machine (~/.skills).
Learn: Provides the Agent with the exact file structure and SKILL.md instructions.
Dependency Management: Works seamlessly with uv to let Agents self-manage Python environments without polluting your system.
Related MCP server: aai-gateway
The recommended way to install is via uv (a fast Python package manager). It ensures the tool runs in an isolated environment.
Python 3.10+
uv (Recommended)
# 1. Install uv (if you haven't already)
curl -LsSf https://astral.sh/uv/install.sh | sh
# 2. Install Skills MCP globally
uv tool install skills-mcp(Alternatively, you can use pip, but we strongly recommend uv to avoid dependency conflicts.)
To use Skills MCP with the Claude Desktop app, update your configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the following entry:
{
"mcpServers": {
"skills": {
"command": "uv",
"args": ["tool", "run", "skills-mcp"],
"env": {
"SKILLS_ROOT": "/Users/YOUR_USERNAME/.skills",
"SKILLS_REGISTRY_URL": "https://skills.leezhu.cn/api/v1"
}
}
}
}Tip: Replace /Users/YOUR_USERNAME with your actual home directory path.
If you are using the claude command-line tool, you can install the MCP server directly via the CLI:
# Add the MCP server
claude mcp add skills -- uv tool run skills-mcpNote on Configuration:
Claude Code inherits environment variables from your shell. To set custom configurations (like a private registry URL), export them in your shell profile (~/.zshrc or ~/.bashrc):
export SKILLS_REGISTRY_URL="https://your-private-registry.com/api/v1"Variable | Description | Default |
| Where skills are installed locally. |
|
| The API endpoint of the skills registry. |
|
| (Optional) Token for private registries. |
|
Once installed, you can ask Claude to do things like:
Discovery:
"Search for a skill that can split Excel files." (Claude calls
skills_search)
Acquisition:
"Install the excel-pro skill." (Claude calls
skills_install)
Execution:
"Read the instructions for excel-pro and split this file." (Claude calls
skills_get_details, reads theSKILL.md, installs dependencies viauv, and runs the script)
git clone https://github.com/leezhuuuuu/skills-mcp.git
cd skills-mcp
# Install dependencies
uv sync# Direct run
uv run skills-mcpWe welcome contributions! Please feel free to submit a Pull Request.
Fork the repository.
Create your feature branch.
Commit your changes.
Push to the branch.
Open a Pull Request.
This project is licensed under the MIT License - see the LICENSE file for details.
Read the instruction manual (SKILL.md) and file structure of a locally installed skill. Use this to learn how to use a skill after installing it.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the installed skill |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description implies read-only by stating 'Read the instruction manual'. Lacks details on permissions or limitations, but adequate for a read operation.
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, no redundancy. Action stated first, then usage guidance. Every sentence adds 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?
With output schema present, no need to describe return values. Covers purpose, usage, and parameter sufficiently for a simple read 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 100% with description 'Name of the installed skill'. Description adds value by specifying 'locally installed' and context of use, reinforcing parameter's role.
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?
Clear verb+resource: 'Read the instruction manual (SKILL.md) and file structure of a locally installed skill.' Differentiates from siblings (install, list, search) by focusing on post-installation learning.
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?
Explicit usage context: 'Use this to learn how to use a skill after installing it.' Implies not for installation or listing, though no explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download and install a skill to the local environment.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact name of the skill | |
| force | No | Overwrite if exists |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet the description only says 'download and install' without detailing side effects, default overwrite behavior, network requirements, or error handling. Additional behavioral context is needed.
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?
A single sentence conveying the core action without any superfluous words. Perfectly concise.
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?
Despite having an output schema, the description does not mention what the tool returns or any success/failure indicators. It omits important context about the installation process and outcome.
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 parameter descriptions are adequate. The tool description adds the overall action context but does not enhance parameter meaning beyond what the schema provides.
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 downloads and installs a skill, using specific verb and resource. It distinguishes from siblings which are about viewing and searching skills.
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 on when to use this tool versus alternatives, no mention of prerequisites or when to apply the force parameter. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all external Agent Skills currently installed in the local environment. Call this tool when the user asks 'what skills do I have' or 'show my skills', to complement your knowledge of built-in tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the core behavior (listing installed external skills) but omits details like authentication needs, rate limits, or whether the listing is comprehensive. However, for a 0-parameter read operation, this is minimally 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 succinct sentences, front-loaded with purpose followed by usage context. No redundant or vague language.
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 parameterless tool with a documented output schema, the description fully covers purpose and usage triggers. No missing information for the agent to select or invoke it.
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?
Input schema has zero parameters with 100% schema coverage, so baseline is 4. Description adds no parameter details, but none are needed.
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 the action 'list' and resource 'external Agent Skills currently installed', with additional context that it complements built-in tools, distinguishing it from siblings like skills_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?
Explicitly gives example user queries ('what skills do I have' or 'show my skills') as triggers. While it doesn't enumerate when not to use it, the context strongly implies it's for listing all installed skills, and reliance on output schema and sibling names covers gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the extended Agent Skills Registry. Use this tool WHENEVER the user asks to 'find skills', 'search skills', or needs capabilities that you do not natively possess (e.g. specialized file handling, complex workflows). This registry contains community-contributed skills that extend your native capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search keywords | |
| page | No | Page number | |
| limit | No | Items per page |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It explains that the registry contains community-contributed skills that extend native capabilities, but does not disclose details about sorting, filtering, or result format. The existence of an output schema partially compensates.
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: first states the purpose, second gives usage guidance. No wasted words, and key information is front-loaded.
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 description covers the tool's purpose and usage context adequately for a search tool. With an output schema present, it does not need to detail return values. It could mention that results are paginated, but that is implied by the page and limit parameters.
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?
All three parameters have descriptions in the schema (100% coverage), so the description does not need to add more. The description does not provide additional semantic meaning beyond what the schema already offers.
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 extended Agent Skills Registry. It specifies the verb 'search' and the resource 'Skills Registry', and distinguishes from siblings like skills_get_details by indicating it's for finding skills based on queries.
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 says 'Use this tool WHENEVER the user asks to find skills, search skills, or needs capabilities that you do not natively possess.' This provides clear context for when to use it, though it doesn't explicitly mention when not to use it or alternative tools.
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.
skills_get_detailsskills_installskills_listskills_searchScored across 4 tools
Each tool has a clear, distinct purpose: installing, listing, searching, or getting details of skills. There is no ambiguity between them.
All tools start with 'skills_' and use a verb pattern, but 'skills_get_details' mixes verb_noun while others are single verbs. This is a minor inconsistency.
Four tools is a concise and well-scoped set for managing skills, covering the essential operations without being too few or excessive.
The set covers install, list, search, and details, but lacks an uninstall or remove tool, which is a notable gap for full lifecycle management.
AI agent skills marketplace — token-efficient skill search & execution
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-to-agent marketplace for AI task discovery, matching, delivery, and trust.
Private, portable memory and reusable skills for AI agents.
