Integrates with the Vercel-backed skills.sh ecosystem to enable discovery, installation, and lifecycle management of reusable AI agent skills and instruction sets.
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., "@mcp-skills find and install a skill for generating React components"
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.
mcp-skills is an MCP server that integrates with the open skills.sh ecosystem. It enables coding agents and LLMs to discover, recommend, and install reusable skills automatically.
Related MCP server: skills-master-mcp
Modern AI coding agents can write code, but they can’t easily extend themselves.
When an agent lacks a capability (e.g. React testing, refactoring patterns, architectural scaffolding), it usually depends on:
Manual CLI execution
Human intervention
Prompt hacks
mcp-skills bridges that gap.
It gives AI agents structured access to the open skills.sh ecosystem through Model Context Protocol (MCP), enabling:
Skills discovery
Context-aware skill recommendation and installation
Full lifecycle management (install, update, uninstall)
skills.sh is The Open Agent Skills Ecosystem by Vercel. It lets you search, install, and manage skills (reusable instruction sets) for popular coding agents like Copilot, Cursor, Claude Code, Codex, OpenCode, and many more.
Example use cases:
"Find a skill to generate React components" → Agent searches and installs it
"Install the TypeScript refactoring skill" → Agent adds it to your environment
Agent detects missing capability → Autonomously searches and installs the right skill
"Analyze this monorepo and enforce a consistent testing strategy across all packages" → Agent detects Jest/Vitest usage, installs the appropriate testing skill, and refactors configs automatically
"Migrate this legacy Express API to a typed architecture" → Agent selects a TypeScript migration skill, installs it, and applies structured refactors across the codebase
CLI: Token-efficient and fast for direct execution.
MCP: Better for structured reasoning, introspection, and autonomous agent workflows.
Install the MCP server from npm. No need to clone the repository.
Standard config works in most MCP clients:
{
"mcpServers": {
"mcp-skills": {
"command": "npx",
"args": [
"-y",
"@koderspa/mcp-skills@latest"
]
}
}
}Add via the Amp VS Code extension settings screen or by updating your settings.json file:
"amp.mcpServers": {
"mcp-skills": {
"command": "npx",
"args": [
"@koderspa/mcp-skills@latest"
]
}
}Amp CLI Setup:
Add via the amp mcp addcommand below
amp mcp add mcp-skills -- npx @koderspa/mcp-skills@latestUse the Claude Code CLI to add the mcp-skills MCP server:
claude mcp add mcp-skills npx @koderspa/mcp-skills@latestFollow the MCP install guide, use the standard config above.
Follow the instruction in the section Configuring MCP Servers
Example: Local Setup
Add the following to your cline_mcp_settings.json file:
{
"mcpServers": {
"mcp-skills": {
"type": "stdio",
"command": "npx",
"timeout": 30,
"args": [
"@koderspa/mcp-skills@latest"
],
"disabled": false
}
}
}Use the Codex CLI to add the mcp-skills MCP server:
codex mcp add mcp-skills npx "@koderspa/mcp-skills@latest"Alternatively, create or edit the configuration file ~/.codex/config.toml and add:
[mcp_servers.mcp-skills]
command = "npx"
args = ["@koderspa/mcp-skills@latest"]For more information, see the Codex MCP documentation.
Use the Copilot CLI to interactively add the mcp-skills MCP server:
/mcp addAlternatively, create or edit the configuration file ~/.copilot/mcp-config.json and add:
{
"mcpServers": {
"mcp-skills": {
"type": "local",
"command": "npx",
"tools": [
"*"
],
"args": [
"@koderspa/mcp-skills@latest"
]
}
}
}For more information, see the Copilot CLI documentation.
Follow the MCP install guide, use the standard config above. You can also install the mcp-skills MCP server using the VS Code CLI:
# For VS Code
code --add-mcp '{"name":"mcp-skills","command":"npx","args":["@koderspa/mcp-skills@latest"]}'After installation, the mcp-skills MCP server will be available for use with your GitHub Copilot agent in VS Code.
Go to Cursor Settings -> MCP -> Add new MCP Server. Name to your liking, use command type with the command npx @koderspa/mcp-skills@latest. You can also verify config or add command like arguments via clicking Edit.
Use the Factory CLI to add the mcp-skills MCP server:
droid mcp add mcp-skills "npx @koderspa/mcp-skills@latest"Alternatively, type /mcp within Factory droid to open an interactive UI for managing MCP servers.
For more information, see the Factory MCP documentation.
Follow the MCP install guide, use the standard config above.
Go to Advanced settings -> Extensions -> Add custom extension. Name to your liking, use type STDIO, and set the command to npx @koderspa/mcp-skills@latest. Click "Add Extension".
Follow the MCP Servers documentation. For example in .kiro/settings/mcp.json:
{
"mcpServers": {
"mcp-skills": {
"command": "npx",
"args": [
"@koderspa/mcp-skills@latest"
]
}
}
}
Go to Program in the right sidebar -> Install -> Edit mcp.json. Use the standard config above.
Follow the MCP Servers documentation. For example in ~/.config/opencode/opencode.json:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"mcp-skills": {
"type": "local",
"command": [
"npx",
"@koderspa/mcp-skills@latest"
],
"enabled": true
}
}
}
Open Qodo Gen chat panel in VSCode or IntelliJ → Connect more tools → + Add new MCP → Paste the standard config above.
Click Save.
Go to Settings -> AI -> Manage MCP Servers -> + Add to add an MCP Server. Use the standard config above.
Alternatively, use the slash command /add-mcp in the Warp prompt and paste the standard config from above:
{
"mcpServers": {
"mcp-skills": {
"command": "npx",
"args": [
"@koderspa/mcp-skills@latest"
]
}
}
}Follow Windsurf MCP documentation. Use the standard config above.
AI Agent ↓ MCP Client ↓ mcp-skills (this server) ↓ skills.sh CLI ↓ Installed Skills
Read-only: Yes Input: Query string Output: List of matching skills with metadata
Uses the skills.sh CLI to search the open skills ecosystem.
Read-only: No (modifies system)
Input: Skill ID (format: <code>owner/repo@skill</code>)
Output: Installation success/failure message
Auto-detects: Installs missing skills CLI automaticallyInstalls a skill from skills.sh or GitHub by its ID.
Read-only: No (modifies system)
Input: Skill ID (format: <code>owner/repo@skill</code>)
Output: Uninstallation success/failure messageRemoves a previously installed skill by its ID.
Read-only: No (modifies system)
Input: Skill ID (format: <code>owner/repo@skill</code>)
Output: Update success/failure messageUpdates an installed skill to its latest version.
Read-only: Yes
Input: Task description
Output: Best matching skill with detailsRecommends the most relevant skill for a specific task using the skills.sh ecosystem.
Read-only: Yes
Input: None (analyzes <code>package.json</code> in the current directory)
Output: Detected stack and recommended skillsAnalyzes your project's package.json to detect frameworks/libraries and recommends relevant skills.
Contributions are welcome! Please feel free to submit a Pull Request.
Fork the repository
Create your feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add some amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
Issues: GitHub Issues
Email: yusterfrancisco@koderspa.com
Apache-2.0 License - see LICENSE file for details.
Analiza el package.json y recomienda skills según el stack detectado.
| 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 carries the full burden of behavioral disclosure. It mentions analysis and recommendation but doesn't specify whether this is a read-only operation, if it requires authentication, how it handles errors (e.g., missing package.json), or what the output format looks like. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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, efficient sentence in Spanish that directly states what the tool does. It uses clear language ('Analiza el package.json y recomienda skills según el stack detectado') with no wasted words or redundancy, making it highly concise and 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?
Given the complexity (analysis and recommendation based on package.json), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'skills' are, how recommendations are generated, the format of the output, or error handling. For a tool that performs non-trivial operations, more context is needed to guide effective 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?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for any parameter gaps, and it appropriately focuses on the tool's purpose without unnecessary parameter details. A baseline of 4 is applied for zero-parameter tools when the schema is fully covered.
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: analyzing package.json and recommending skills based on the detected stack. It uses specific verbs ('analiza', 'recomienda') and identifies the resource (package.json). However, it doesn't explicitly differentiate from sibling tools like 'findSkills' or 'selectSkill', which may have overlapping functionality.
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 doesn't mention prerequisites (e.g., needing a package.json file), exclusions, or how it differs from siblings like 'findSkills' (which might search for skills) or 'selectSkill' (which might choose from recommendations). Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca skills en el ecosistema skills.sh por palabra clave
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Palabra clave para buscar skills |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches by keyword but doesn't describe what the search returns (e.g., list of skills, metadata, pagination), performance characteristics, error conditions, or authentication needs. For a search tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('Busca skills') and includes essential context ('en el ecosistema skills.sh por palabra clave'). Every part of the sentence contributes meaning, making it appropriately 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?
Given the lack of annotations and output schema, the description is incomplete for effective tool use. It doesn't explain what the search returns (e.g., a list, details, or IDs), how results are structured, or any limitations (e.g., max results, sorting). For a search tool with no structured output information, the description should provide more context about the expected behavior and 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?
The description adds minimal semantic context beyond the input schema. It mentions 'por palabra clave' (by keyword), which aligns with the 'query' parameter's description ('Palabra clave para buscar skills'). However, with 100% schema description coverage, the schema already documents the parameter well. The description doesn't provide additional details like query syntax, examples, or constraints, so it meets the baseline for high schema 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 the tool's purpose: 'Busca skills en el ecosistema skills.sh por palabra clave' (Search for skills in the skills.sh ecosystem by keyword). It specifies the verb ('busca' - search), resource ('skills'), and scope ('ecosistema skills.sh'). However, it doesn't explicitly differentiate from sibling tools like 'selectSkill' or 'analyzeProjectStack', which might also involve skill selection or analysis.
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 doesn't mention prerequisites, when not to use it, or how it differs from sibling tools like 'selectSkill' (which might pick a specific skill) or 'analyzeProjectStack' (which might analyze project dependencies). The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Instala un skill desde skills.sh o GitHub usando su ID (owner/repo@skill)
| Name | Required | Description | Default |
|---|---|---|---|
| skillId | Yes | ID del skill a instalar, ej: owner/repo@skill |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It lacks details on permissions needed, side effects (e.g., if installation affects system state), error handling, or confirmation steps. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence with zero waste. It front-loads the purpose and includes essential details (sources, ID format) without unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after installation, success/failure indicators, or behavioral traits like dependencies or system impacts, leaving significant gaps for an agent to use it correctly.
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 documents the skillId parameter with an example. The description adds minimal value by mentioning the ID format and sources, but doesn't provide additional syntax, validation rules, or context beyond what the schema 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 action ('Instala') and resource ('un skill'), specifying it installs a skill from skills.sh or GitHub using an ID format. It distinguishes from siblings like uninstallSkill and updateSkill by focusing on installation, but doesn't explicitly differentiate from selectSkill which might involve selection rather than installation.
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 like selectSkill or findSkills. The description mentions the source (skills.sh or GitHub) but doesn't specify prerequisites, conditions for use, or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recomienda el skill más relevante para una tarea concreta
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Descripción de la tarea para la que necesitas un skill |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool recommends a skill but doesn't explain how the recommendation is generated (e.g., based on criteria, rankings, or AI models), what the output format is (since no output schema exists), or any limitations like rate limits or authentication needs. This leaves key behavioral traits unspecified.
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, clear sentence in Spanish that directly states the tool's function without unnecessary words. It's front-loaded and efficiently conveys the core purpose, making it easy to parse and understand 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 complexity of a recommendation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like how recommendations are made, what data is returned, or error handling. For a tool that likely involves ranking or selection logic, more context is needed to guide effective 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?
The description implies the 'task' parameter is used to determine relevance, but it doesn't add meaning beyond the schema's description ('Descripción de la tarea para la que necesitas un skill'). With 100% schema description coverage, the baseline is 3, as the schema adequately documents the parameter without extra semantic value from the description.
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 'Recomienda el skill más relevante para una tarea concreta' clearly states the tool's purpose: recommending the most relevant skill for a specific task. It uses a specific verb ('recomienda') and resource ('skill'), making the intent understandable. However, it doesn't explicitly differentiate from sibling tools like 'findSkills' or 'analyzeProjectStack', which might have overlapping or related functions.
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 doesn't mention prerequisites, exclusions, or compare it to siblings such as 'findSkills' (which might list skills) or 'installSkill' (which might apply a skill). Without this context, an AI agent might struggle to choose between these tools appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Desinstala un skill instalado usando su ID (owner/repo@skill)
| Name | Required | Description | Default |
|---|---|---|---|
| skillId | Yes | ID del skill a desinstalar, ej: owner/repo@skill |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool uninstalls a skill but doesn't describe what 'uninstall' entails (e.g., whether it's reversible, if it removes data, permissions required, or potential side effects). For a mutation tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
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, efficient sentence that front-loads the key action ('Desinstala un skill instalado') and includes necessary parameter context. There's no wasted text, though it could be slightly more structured (e.g., by explicitly stating it's a destructive operation).
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 complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It doesn't explain what happens during uninstallation, whether there are confirmation prompts, error conditions, or what the return value might be. For a tool that presumably alters system state, more context is needed to guide safe usage.
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 the parameter 'skillId' documented in the schema as 'ID del skill a desinstalar, ej: owner/repo@skill'. The description repeats this information ('usando su ID (owner/repo@skill)') but adds no additional meaning beyond what the schema provides, such as format details or examples. Baseline 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 action ('Desinstala' - uninstalls) and the resource ('un skill instalado' - an installed skill), specifying it uses the skill ID. It distinguishes from siblings like 'installSkill' and 'updateSkill' by focusing on removal rather than addition or modification. However, it doesn't explicitly differentiate from 'selectSkill' which might involve skill selection without uninstallation.
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 doesn't mention prerequisites (e.g., the skill must be installed first), when not to use it, or how it relates to sibling tools like 'updateSkill' for modifications or 'findSkills' for discovery. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Actualiza un skill instalado usando su ID (owner/repo@skill)
| Name | Required | Description | Default |
|---|---|---|---|
| skillId | Yes | ID del skill a actualizar, ej: owner/repo@skill |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool updates an installed skill but doesn't describe what 'update' entails (e.g., fetching latest version, applying patches, restarting services), potential side effects (e.g., downtime, configuration changes), authentication requirements, or error handling. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence that directly states the tool's purpose and parameter format. It's appropriately sized for a simple tool with one parameter, with no redundant information. However, it could be slightly more front-loaded by explicitly mentioning it's for updating installed skills before detailing the ID format.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens during the update process, what success/failure looks like, or any constraints (e.g., network requirements, version compatibility). For a tool that modifies system state, more behavioral context is needed to be 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%, with the single parameter 'skillId' fully documented in the schema as 'ID del skill a actualizar, ej: owner/repo@skill'. The description adds minimal value beyond this, only restating the parameter format without providing additional context like validation rules or examples of valid IDs. Baseline 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 action ('Actualiza' - updates) and the resource ('un skill instalado' - an installed skill) using a specific identifier format. It distinguishes itself from siblings like 'installSkill' and 'uninstallSkill' by focusing on updating existing skills rather than adding or removing them. However, it doesn't explicitly differentiate from potential 'selectSkill' or other management operations.
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 doesn't mention prerequisites (e.g., the skill must already be installed), when not to use it (e.g., for initial installation), or direct comparisons to sibling tools like 'installSkill' for new installations or 'uninstallSkill' for removal. Usage context is implied but not explicitly stated.
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.9analyzeProjectStackfindSkillsinstallSkillselectSkilluninstallSkillupdateSkillScored across 6 tools
Each tool has a clearly distinct purpose with no overlap: analyzeProjectStack detects stacks, findSkills searches by keyword, selectSkill recommends for tasks, and install/uninstall/update manage skill lifecycle. The descriptions make it easy to differentiate between analysis, search, recommendation, and management functions.
Tools follow a consistent verbNoun pattern (e.g., analyzeProjectStack, findSkills, installSkill) with clear action-object naming. The minor deviation is 'selectSkill' which uses 'select' instead of a more precise verb like 'recommendSkill', but overall the naming is highly predictable and readable.
With 6 tools, the server is well-scoped for managing skills in the skills.sh ecosystem. It covers analysis, discovery, recommendation, and full lifecycle management (install/update/uninstall), with each tool earning its place without being overwhelming or insufficient for the domain.
The toolset provides complete coverage for the skills management domain: analyzeProjectStack for stack detection, findSkills and selectSkill for discovery and recommendation, and installSkill, updateSkill, uninstallSkill for full CRUD-like lifecycle management. No obvious gaps exist for the stated purpose.
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.
Find, inspect and install reviewed reusable AI-agent capabilities from superskill.sh.
Agent-first skill marketplace with USK open standard for Claude, Cursor, Gemini, Codex CLI.
Governed AI agent skills — one library, distributed to devs and exposed to remote agents over MCP.
