The Skill Ninja MCP Server enables you to search, install, and manage AI Agent Skills for MCP-compatible clients like Claude Desktop, Cursor, and VS Code. It provides access to 140+ pre-indexed skills through these capabilities:
Search Skills - Search by keyword, name, description, or category using skillNinja_search
Install/Uninstall Skills - Install skills to your workspace (.github/skills/) or remove them using skillNinja_install and skillNinja_uninstall, automatically updating AGENTS.md
List Installed Skills - View all skills in your workspace with skillNinja_list
Get Recommendations - Receive personalized skill recommendations based on popularity using skillNinja_recommend
Update Index - Refresh the skill index from registered GitHub sources with skillNinja_updateIndex
GitHub Search - Find new skills by searching for SKILL.md files across GitHub using skillNinja_webSearch
Add Sources - Register new GitHub repositories as skill sources with skillNinja_addSource
Localize Descriptions - Translate skill descriptions (English/Japanese) using skillNinja_localize
This allows you to quickly discover relevant skills for your project, install pre-built capabilities, and maintain a curated collection of AI agent skills in your workspace.
Enables searching GitHub for AI Agent Skills and MCP servers, and supports adding new skill sources from GitHub repositories.
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., "@skill-ninja-mcp-server search for skills related to database management"
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 MCP (Model Context Protocol) server for searching, installing, and managing AI Agent Skills.
Works with MCP-compatible clients like Claude Desktop, Cursor, and VS Code.
npm install -g skill-ninja-mcp-serverOr run it directly with npx:
npx skill-ninja-mcp-serverRelated MCP server: Agent Skills MCP
~/.claude/claude_desktop_config.json:
{
"mcpServers": {
"skill-ninja": {
"command": "npx",
"args": ["skill-ninja-mcp-server"]
}
}
}%APPDATA%\Code\User\mcp.json:
{
"servers": {
"skill-ninja": {
"command": "npx",
"args": ["skill-ninja-mcp-server"]
}
}
}Variable | Description | Default |
| GitHub API token for higher rate limits | none |
| Skill index storage directory |
|
| Trusted workspace roots allowed for read/write operations | auto-detect current project root only |
| Output language, for example | system default |
Workspace-mutating tools only operate inside trusted workspace roots.
By default, the server trusts the current working directory only when it looks like a project root.
To allow other locations, set the SKILL_NINJA_TRUSTED_WORKSPACES environment variable to one or more trusted roots separated by your OS path delimiter.
Requests outside trusted roots are rejected before any read, write, or delete occurs.
GitHub API and raw content fetches use a bounded timeout so network failures return control instead of hanging the MCP server indefinitely.
Search and recommendation results include the source name for each skill.
If multiple sources publish the same skill name, pass the optional source field to skillNinja_install or skillNinja_localize.
Installed skill listings include the recorded source, and the server refuses to overwrite an installed skill with the same name from a different source.
If a partial skill name matches multiple different skills, the install, localize, and uninstall flows now stop and ask for the exact skill name instead of picking the first match.
Tool | Description |
| Search the local skill index by keyword |
| Install a skill into a trusted workspace |
| Remove an installed skill from a trusted workspace |
| List installed skills in a trusted workspace |
| Recommend skills based on workspace contents |
| Refresh the local skill index from registered sources |
| Search GitHub for repositories containing |
| Add a GitHub repository as a skill source |
| Update localized skill descriptions in the index |
skillNinja_install tries to fetch the original SKILL.md from the source repository. If the source file cannot be resolved or downloaded, it installs a minimal file generated from the local index and reports that fallback in the result.
"Find skills for Azure work"
-> skillNinja_search
"Install the webapp-testing skill from GitHub Awesome Copilot"
-> skillNinja_install with skillName="webapp-testing" and source="github-awesome-copilot"
"Install test"
-> refine to the exact skill name first, for example "test-driven-development"
"Search GitHub for MCP skills"
-> skillNinja_webSearchgit clone https://github.com/aktsmm/skill-ninja-mcp-server
cd skill-ninja-mcp-server
npm install
npm test
npm run release:verifyCC BY-NC-SA 4.0 — see LICENSE.
Add a new GitHub repository as a skill source. Repository should contain SKILL.md files. / 新しいリポジトリをスキルソースとして追加
| Name | Required | Description | Default |
|---|---|---|---|
| repoUrl | Yes | GitHub repository URL (e.g., 'https://github.com/owner/repo' or 'owner/repo') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states action and requirement. Does not disclose side effects, authentication needs, rate limits, or error handling. For a tool with no annotations, this is insufficient.
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, front-loaded with action. Bilingual inclusion adds slight redundancy but does not hinder 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?
Simple one-param tool, but description lacks context on what 'add' entails (e.g., persistence, indexing). No output schema or annotations to compensate. Leaves operational gaps.
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 provides 100% coverage with description of repoUrl. Description adds no extra semantic meaning beyond schema, so baseline 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?
Clearly states verb 'Add', resource 'GitHub repository as a skill source', and condition 'Repository should contain SKILL.md files'. Distinguishes from sibling tools like install and 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?
Implies usage for adding a source but lacks explicit guidance on when to use vs alternatives like install. No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install an Agent Skill to the workspace. Downloads SKILL.md when source content is resolvable, otherwise generates a minimal stub and updates AGENTS.md. / スキルをワークスペースにインストールし、取得できる場合は SKILL.md を保存、できない場合は最小内容を生成
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Optional source key for disambiguation when multiple skills share the same name | |
| skillName | Yes | Name of the skill to install | |
| workspacePath | Yes | Absolute path to a trusted workspace directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the conditional behavior (resolvable source vs stub) and that AGENTS.md is updated, but does not mention potential overwrites, authorization requirements, or error handling.
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 two English sentences and a Japanese translation. It is front-loaded with the core purpose, though the Japanese section could be considered redundant for an English-language system.
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 and moderate complexity, the description covers the main action and conditional behavior adequately. It is mostly complete, though missing details on failure modes or workspace path validation.
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 baseline is 3. The description adds limited value beyond schema, only implicitly linking 'source' to content resolvability without clarifying disambiguation logic.
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 installs an Agent Skill to the workspace, with specific actions (downloading SKILL.md or generating a stub and updating AGENTS.md). It distinguishes from sibling tools like uninstall and list.
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 context on behavior (conditional download vs stub generation) but does not explicitly state when to use this tool versus alternatives like skillNinja_addSource or skillNinja_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all installed Agent Skills in the workspace. / インストール済みスキル一覧を表示
| Name | Required | Description | Default |
|---|---|---|---|
| workspacePath | Yes | Absolute path to a trusted workspace directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states that the tool lists skills, without disclosing behavioral traits like permissions, read-only nature, or what happens with invalid inputs. This is a minimal disclosure.
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 extremely concise with two sentences (English and Japanese), no fluff, and gets straight to the point.
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 that there are no annotations, no output schema, and only one parameter, the description is minimal. It covers the basic purpose but lacks details on return format or edge cases, which is acceptable for a simple listing 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% for the single parameter workspacePath, and its description already defines it as an absolute path. The tool description does not add further meaning beyond the schema, fitting the baseline.
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 'List' and the resource 'all installed Agent Skills in the workspace,' making the purpose specific and distinct from sibling tools like skillNinja_install or skillNinja_uninstall.
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 (list skills) but does not provide explicit guidance on when to use vs. alternatives, nor any when-not or exclusions. It is adequate but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate/localize skill descriptions in the index. Provide skillName and description_en and/or description_ja. / スキル説明を翻訳・ローカライズ
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Optional source key for disambiguation when multiple skills share the same name | |
| skillName | Yes | Name of the skill to localize | |
| description_en | No | English description for the skill | |
| description_ja | No | Japanese description for the skill (日本語の説明) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description should disclose behavioral traits. It only states that it translates/localizes, but does not specify if it overwrites existing descriptions, requires special permissions, or has side effects on other languages.
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 short and front-loaded with the action. Including both English and Japanese is useful for bilingual context, but could be slightly tighter by omitting the Japanese repetition.
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 tool with 4 parameters and no output schema, the description lacks details on edge cases, overwrite behavior, and expected return value. It does not fully compensate for the absence of annotations.
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 baseline is 3. The description reiterates the parameter names ('Provide skillName and description_en and/or description_ja') but adds no additional meaning about constraints, format, or behavior when both are provided.
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 (translate/localize) and resource (skill descriptions in the index), and it is distinct from sibling tools like search, install, or webSearch.
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. The description does not mention conditions, prerequisites, or when to prefer this over other tools like skillNinja_updateIndex.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get skill recommendations based on popularity. / 人気スキルのおすすめを取得
| Name | Required | Description | Default |
|---|---|---|---|
| workspacePath | Yes | Absolute path to a trusted workspace directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only mentions 'based on popularity' but does not disclose side effects, read-only nature, authentication requirements, or other behavioral traits. The tool likely reads data, but this is not explicitly stated.
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 very short and front-loaded with the core action. It is concise, though could benefit from a bit more detail without being verbose. Score 4 for being efficient.
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 low complexity (1 parameter, no nested objects, no output schema), the description is adequate but lacks details on return format or recommendation criteria beyond 'popularity'. No output schema means agent gets no hints about the response structure.
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 parameter. The description does not add extra meaning beyond the schema. 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 'Get skill recommendations based on popularity', with a specific verb and resource. It is distinct from sibling tools like skillNinja_search or skillNinja_list which have different purposes.
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 like skillNinja_search or skillNinja_list. No context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Agent Skills by keyword. Returns matching skills with trust badges and recommendations. / キーワードでエージェントスキルを検索
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (skill name, description, or category) |
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 returning trust badges and recommendations, but does not disclose permissions, side effects, or limitations. The search is likely read-only, 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 sentence in English followed by a Japanese translation. It is concise and front-loaded, with no extraneous 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?
The input schema is simple and complete. However, the description does not explain return structure (e.g., pagination, ordering) or limitations. For a search tool, more detail could be helpful, but the low complexity mitigates the gap.
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% for the single parameter 'query'. The description adds no new information beyond the schema, as both state the query matches name, description, or category. Baseline is 3.
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 (Search), resource (Agent Skills), and includes what is returned (matching skills with trust badges and recommendations). It distinguishes from siblings like skillNinja_list and skillNinja_webSearch.
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 siblings like skillNinja_list, skillNinja_recommend, or skillNinja_webSearch. The description only implies keyword search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Uninstall an Agent Skill from the workspace. Removes skill folder and updates AGENTS.md. / スキルをアンインストール
| Name | Required | Description | Default |
|---|---|---|---|
| skillName | Yes | Name of the skill to uninstall | |
| workspacePath | Yes | Absolute path to a trusted workspace directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool removes the skill folder and updates AGENTS.md, indicating side effects. However, without annotations, it lacks details on permissions, reversibility, or potential impacts on other skills.
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 extremely concise with two short sentences covering the essential action and effect. It is front-loaded and contains no fluff.
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 and the complexity of a destructive operation, the description lacks important context such as expected return value, error handling, and dependencies on other skills. It also does not help the agent decide when to use this tool among 8 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% for both parameters, so the description does not need to add much. The tool description does not elaborate beyond the schema, meeting the baseline. No new semantic information is provided.
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 'Uninstall' and the resource 'Agent Skill', with additional detail about removing the skill folder and updating AGENTS.md. This distinguishes it from sibling tools like skillNinja_install and skillNinja_list.
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. There is no mention of prerequisites, when not to uninstall, or comparisons to sibling tools like skillNinja_updateIndex.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the skill index from all registered sources. Fetches latest skills from GitHub repositories. / スキルインデックスを更新
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context by mentioning GitHub fetching, but with no annotations, it fails to disclose potential side effects, failure modes, or idempotency. It does not describe what happens to the index or any destructive outcomes.
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 two short sentences (one in English, one in Japanese). It front-loads the action and provides no superfluous 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?
Given no output schema, the description should hint at results or side effects. It omits prerequisites (e.g., registered sources) and return value. The tool is simple, so a 3 reflects adequate but incomplete coverage.
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 has no parameters (100% coverage). The description does not need to add parameter meaning, but the absence of any parameter documentation is acceptable. Baseline 4 for zero parameters 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 action ('Update the skill index') and the scope ('from all registered sources, fetches latest skills from GitHub'). It effectively distinguishes from siblings like skillNinja_search or skillNinja_list, which serve different purposes.
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 (e.g., skillNinja_addSource, skillNinja_install). There is no mention of prerequisites or appropriate contexts, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Agent Skills on GitHub. Finds SKILL.md files across GitHub repositories. / GitHub でスキルを検索
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for GitHub |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose important behavioral traits like rate limits, authentication needs, or what happens if no results are found. It only mentions the action without side effects or constraints.
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 short and to the point, but it includes redundant phrasing ('Search for Agent Skills on GitHub' and 'Finds SKILL.md files across GitHub repositories' are similar). Could be more 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 output schema and only one parameter, the description is incomplete. It does not explain the return format (e.g., list of repositories, contents of SKILL.md) or any result handling, leaving the agent uncertain about the tool's full 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% and the parameter 'query' already has a clear description. The tool description does not add extra meaning beyond the schema, so baseline 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 it searches for Agent Skills on GitHub and specifically finds SKILL.md files, distinguishing it from sibling tools like skillNinja_search which likely searches locally or differently.
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 such as skillNinja_search or skillNinja_recommend. The description only states what it does, not when to use it.
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. Dates show when Glama detected each change.
v0.1.4skillNinja_install2 fields changedInput schema / properties / sourceAdded value: +{
+ "description": "Optional source key for disambiguation when multiple skills share the same name",
+ "type": "string"
+}Input schema / properties / workspacePath / descriptionPrevious value: -"Absolute path to the workspace directory"New value: +"Absolute path to a trusted workspace directory"skillNinja_list1 field changedInput schema / properties / workspacePath / descriptionPrevious value: -"Absolute path to the workspace directory"New value: +"Absolute path to a trusted workspace directory"skillNinja_localize1 field changedInput schema / properties / sourceAdded value: +{
+ "description": "Optional source key for disambiguation when multiple skills share the same name",
+ "type": "string"
+}skillNinja_recommend1 field changedInput schema / properties / workspacePath / descriptionPrevious value: -"Absolute path to the workspace directory"New value: +"Absolute path to a trusted workspace directory"skillNinja_uninstall1 field changedInput schema / properties / workspacePath / descriptionPrevious value: -"Absolute path to the workspace directory"New value: +"Absolute path to a trusted workspace directory"v1.0.0skillNinja_addSourceskillNinja_installskillNinja_listskillNinja_localizeskillNinja_recommendskillNinja_searchskillNinja_uninstallskillNinja_updateIndexskillNinja_webSearchEach tool has a distinct purpose: adding sources, installing/uninstalling, listing, searching, recommending, localizing, updating index, and searching GitHub. No observable overlap.
All tools share the consistent 'skillNinja_' prefix followed by an action verb. Most are single-word verbs, but a few use camelCase compounds (addSource, updateIndex, webSearch), introducing minor inconsistency.
9 tools is well within the ideal 3-15 range, covering the core functionality of a skill management system without being overwhelming.
The set covers CRUD-like operations (add source, install, uninstall, list, update index) plus search and recommendations. A minor gap is lack of a dedicated tool to view detailed info about a single installed skill, but search and list partially fill this.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search your team's shared AI-skill library, get install commands, and save skills from your agent.
Find, inspect and install reviewed reusable AI-agent capabilities from superskill.sh.
Search, install and submit Markdown skills for AI agents; private Brain files when signed in.
Search & install 6,500+ AI agent skills from skills-hub.ai inside any MCP tool.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aktsmm/skill-ninja-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
