Skill Management MCP Server

by fkesheh

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: execute_python_code runs Python code directly, run_skill_script executes scripts within skills, skill_crud manages skill metadata, skill_env_crud handles environment variables, and skill_files_crud manages files. The descriptions explicitly differentiate them, preventing misselection.
Naming Consistency4/5
The naming follows a consistent snake_case pattern (e.g., execute_python_code, run_skill_script), but there is a minor deviation: skill_crud, skill_env_crud, and skill_files_crud use a 'skill_*_crud' format, which is slightly different from the verb_noun style of the first two tools. However, the pattern is still readable and mostly predictable.
Tool Count5/5
With 5 tools, the count is well-scoped for a skill management server. Each tool covers a distinct aspect of the domain (execution, script running, CRUD operations for skills, env vars, and files), and none feel redundant or missing, making the set appropriately sized for the purpose.
Completeness5/5
The tool set provides complete coverage for skill management: execute_python_code and run_skill_script handle code execution, while skill_crud, skill_env_crud, and skill_files_crud offer full CRUD operations for skills, environment variables, and files. There are no obvious gaps, and agents can perform all expected lifecycle operations without dead ends.
Average 4.4/5 across 5 of 5 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 MIT License.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. It successfully describes key behaviors: skills are stored in a specific directory (~/.skill-mcp/skills), file paths in responses are relative, delete requires confirmation, and it distinguishes between operations like list vs search. However, it doesn't mention rate limits, error handling, or authentication requirements.
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 well-structured with clear sections (unified purpose, important notes, operations list, examples). While comprehensive, it's appropriately sized for a multi-operation tool. The examples section is extensive but necessary to demonstrate the various operation patterns. Some redundancy exists between the operations list and examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 7-parameter tool with no annotations and no output schema, the description does a good job covering operations, usage guidelines, and examples. It explains the tool's scope and relationship to siblings. However, without output schema, it doesn't describe return values or error formats, leaving some uncertainty about what to expect from operations.
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 baseline is 3. The description adds some value by grouping parameters under operations in the examples section, showing which parameters are used together. However, it doesn't provide additional semantic context beyond what's already documented in the schema descriptions for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a 'Unified CRUD tool for skill management' and enumerates seven specific operations (create, list, search, get, validate, delete, list_templates). It distinguishes itself from sibling tools by explicitly mentioning 'run_skill_script' as the alternative for execution and not using external bash/shell tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives ('To execute scripts, use the 'run_skill_script' tool, NOT external bash/shell tools'). It also includes important notes about file path conventions and storage location, and the examples section demonstrates proper usage patterns for each operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: automatic dependency installation, environment variable loading, temporary file cleanup, timeout defaults, and dependency aggregation. However, it doesn't explicitly mention security implications or resource constraints like memory/CPU limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While well-structured with clear sections, the description is quite lengthy with extensive examples and marketing-style content ('WHY PYTHON OVER BASH/JS'). Some sections like the cross-skill imports promotion and multiple detailed examples could be condensed while maintaining clarity. The core information is front-loaded but followed by substantial elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (code execution with dependencies and skill integration) and no output schema, the description provides comprehensive context. It explains the return format (exit code, STDOUT, STDERR), covers all parameters with examples, and addresses integration with sibling tools. However, without annotations, it could benefit from more explicit safety/security warnings for arbitrary code execution.
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?
With 100% schema description coverage, the baseline is 3. The description adds significant value by explaining parameter semantics beyond the schema: it provides concrete examples of skill_references format, explains how dependencies are aggregated from referenced skills, and shows how environment variables are loaded from skill .env files. The multiple code examples demonstrate practical parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 as executing Python code directly without requiring script files, using specific verbs like 'execute' and 'run'. It explicitly distinguishes itself from creating temporary script files and mentions sibling tool 'run_skill_script' for comparison, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives, stating 'Use this tool instead of creating temporary script files when you need to run quick Python code' and recommending 'Prefer Python over bash/shell scripts for better portability, error handling, and maintainability'. It also mentions the sibling tool 'run_skill_script' for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: 'read' hides values for security, 'set' merges with existing variables, and 'clear' removes all. It also explains the relationship between operations (use 'clear' then 'set' to replace everything). It doesn't mention authentication needs, rate limits, or error handling, keeping it from a perfect score.
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 well-structured with clear sections (operations, examples, note), front-loaded with the purpose and operations. Every sentence earns its place by providing essential information or examples. The examples are concise and illustrative without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does a good job covering operations, parameters, and behaviors. It includes examples that clarify usage. However, it lacks information on return values (since no output schema) and doesn't mention potential errors or side effects, which would be helpful for a mutation tool with multiple operations.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds significant value by explaining parameter usage through examples and clarifying that 'variables' is for 'set' and 'keys' is for 'delete'. It also notes that 'set' merges and 'clear' requires only 'skill_name'. However, it doesn't fully explain all parameter interactions (e.g., when 'variables' or 'keys' can be null), preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs CRUD operations on skill environment variables, specifying the four operations (read, set, delete, clear). It distinguishes from siblings by focusing on environment variables rather than skills themselves (skill_crud) or skill files (skill_files_crud). The description goes beyond the name/title by detailing the specific operations supported.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use each operation (e.g., 'set' merges, 'clear' removes all) and includes a note about replacing all variables by combining 'clear' and 'set'. However, it doesn't explicitly contrast when to use this tool versus sibling tools like skill_crud or skill_files_crud, which would be needed for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It details automatic dependency management, environment variable injection, secure execution boundaries, error handling, output capture, timeout defaults, and supported languages. The only minor gap is that it doesn't explicitly mention authentication requirements or rate limits, though these might not apply to this type of tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive but overly long with redundant sections. While well-structured with clear headings, it repeats information about PEP 723 and includes excessive implementation details that could be condensed. The core information could be presented more efficiently without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (script execution with dependency management, multiple languages, security boundaries) and the absence of both annotations and output schema, the description provides complete context. It thoroughly explains what the tool does, how to use it, behavioral characteristics, parameter semantics, and even documents the return structure despite no output schema being provided.
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?
With 100% schema description coverage, the baseline is 3. The description adds significant value by providing concrete examples of parameter usage (e.g., skill_name: 'weather-skill', script_path: 'main.py'), explaining path relativity rules in detail, and clarifying the timeout default. It also provides context about what each parameter enables (working_dir for subdirectory execution, args for command-line arguments).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Execute a script within a skill directory') and distinguishes it from sibling tools by emphasizing that this is the ONLY tool to use for script execution, not external bash/shell tools or other siblings like execute_python_code. It provides concrete examples of what skills are and how they differ from general code execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('ALWAYS use this tool to execute scripts') and when not to ('DO NOT use external bash/shell tools to execute scripts directly'). It distinguishes this from sibling tools by positioning it as the dedicated script execution mechanism within the skill system, unlike execute_python_code which appears to be for general Python code execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits. It explains atomic mode behavior ('all-or-nothing'), file path constraints (relative only), protection rules ('SKILL.md is protected'), and operational scope (single vs bulk). The only minor gap is lack of explicit mention about permissions or error handling specifics.
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 well-structured with clear sections (important notes, operations, examples) and every sentence adds value. While somewhat lengthy due to comprehensive examples, the information is front-loaded with critical constraints first, and the examples are necessary for understanding this multi-operation tool's usage patterns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 7-parameter CRUD tool with no annotations and no output schema, the description provides excellent coverage of operations, constraints, and usage patterns. It explains what the tool does, how to use it, and important behavioral aspects. The only gap is lack of information about return values or error formats, but given the comprehensive operational guidance, this is a minor omission.
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?
Schema description coverage is 100%, so baseline is 3. The description adds significant value by clarifying parameter usage patterns through detailed examples showing how parameters combine for different operations (single vs bulk, atomic mode). It explains the relationship between operation type and which parameters to use, which goes beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a 'Unified CRUD tool for skill file operations' with specific verbs (read, create, update, delete) and resource (skill files). It distinguishes itself from sibling tools by explicitly mentioning 'run_skill_script' as the alternative for execution and not using external bash/shell tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs alternatives: 'To execute scripts, use the 'run_skill_script' tool, NOT external bash/shell tools.' It also specifies path requirements (relative vs absolute) and includes important operational constraints like SKILL.md protection and atomic mode for bulk operations.
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:

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

Score Badge

Copy to your README.md:

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

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/fkesheh/skill-mcp'

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