mcp-skills

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.9
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 2.9/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-skills MCP server](https://glama.ai/mcp/servers/FranciscoYuster/mcp-skills/badges/card.svg)](https://glama.ai/mcp/servers/FranciscoYuster/mcp-skills)

Score Badge

Copy to your README.md:

[![mcp-skills MCP server](https://glama.ai/mcp/servers/FranciscoYuster/mcp-skills/badges/score.svg)](https://glama.ai/mcp/servers/FranciscoYuster/mcp-skills)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/FranciscoYuster/mcp-skills'

If you have feedback or need assistance with the MCP directory API, please join our Discord server