Skill Management MCP Server
The Skill Management MCP Server enables programmatic management, execution, and composition of reusable skills stored locally, with automatic dependency management and environment variable handling.
Core Capabilities:
Skill Discovery & Management: List all available skills, retrieve comprehensive details (files, scripts, environment variables, documentation), and validate skill structure with SKILL.md metadata
File Operations (CRUD): Read, create, update, and delete files within skill directories with automatic parent directory creation
Script Execution: Run Python, Bash, and other executable scripts with automatic PEP 723 dependency installation via
uv, environment variable injection, custom arguments, and captured stdout/stderrDirect Python Execution: Execute raw Python code without files, supporting cross-skill imports with automatic dependency and environment variable aggregation from all referenced skills
Environment Variable Management: Securely list variable keys (values hidden), create or replace
.envfiles for per-skill credential storageMulti-Skill Composition: Unify utilities from multiple skills in single executions with automatic dependency merging and environment loading, achieving 98.7% token efficiency following Anthropic's MCP pattern
Security Features: Path validation, script timeouts, secure credential handling, and directory traversal protection
Cross-Platform Compatibility: Works with any MCP-compatible client including Claude Desktop, Cursor, and claude.ai
Use Cases: LLM-managed skill development, reusable utility libraries, API integrations with credential management, data processing pipelines, and composable multi-tool workflows.
Provides tools for managing per-skill environment variables stored in .env files, including setting and reading configuration values for skill execution
Enables programmatic management of skill files and directories, including creating, reading, updating, and deleting files within the skills directory structure
Supports version control integration for skills management, allowing skills to be tracked and versioned using git repositories
Supports GitHub integration through environment variable management for GitHub API tokens and related GitHub workflow automation
Provides tools for managing SKILL.md files and other Markdown documentation within the skills directory structure
Integrates with PyPI for automatic package distribution and installation via uvx, allowing the MCP server to be run directly from PyPI packages
Allows execution of Python scripts with automatic dependency management using PEP 723 inline metadata, enabling scripts to declare and automatically install their own dependencies
Enables execution of shell/bash scripts and other executable scripts with environment variable injection and output capture
Enables parsing and management of YAML frontmatter in skill files for metadata extraction and skill descriptions
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 Management MCP Servercreate a new skill called 'data-processor' with a script to clean CSV files"
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.
Skill Management MCP Server
A Model Context Protocol (MCP) server that enables Claude to manage skills stored in ~/.skill-mcp/skills. This system allows Claude to create, edit, run, and manage skills programmatically, including execution of skill scripts with environment variables.
Quick Status
Status: โ Production Ready Test Coverage: 86% (145/145 tests passing) Deployed: October 18, 2025 Architecture: 22-module modular Python package with unified CRUD architecture
Related MCP server: Claude Desktop Commander MCP
Overview
TL;DR: Write Python code that unifies multiple skills in one execution - follows Anthropic's MCP pattern for 98.7% more efficient agents.
This project consists of two main components:
MCP Server (
src/skill_mcp/server.py) - A Python package providing 5 unified CRUD tools for skill managementSkills Directory (
~/.skill-mcp/skills/) - Where you store and manage your skills
Key Advantages
๐ Unified Multi-Skill Execution (Code Execution with MCP)
Build once, compose everywhere - Execute Python code that seamlessly combines multiple skills in a single run:
# One execution, multiple skills unified!
# Imports from calculator, data-processor, and weather skills
from math_utils import calculate_average # calculator skill
from json_fetcher import fetch_json # data-processor skill
from weather_api import get_forecast # weather skill
# Fetch weather data
weather = fetch_json('https://api.weather.com/cities')
# Calculate averages using calculator utilities
temps = [city['temp'] for city in weather['cities']]
avg_temp = calculate_average(temps)
# Get detailed forecast
forecast = get_forecast('London')
print(f"Average temperature: {avg_temp}ยฐF")
print(f"London forecast: {forecast}")What makes this powerful:
โ Context-efficient - Dependencies and env vars auto-aggregated from all referenced skills
โ Composable - Mix and match utilities from any skill like building blocks
โ No redundancy - Declare PEP 723 dependencies once in library skills, reuse everywhere
โ Progressive disclosure - Load only the skills you need, when you need them
โ Follows Anthropic's MCP pattern - Code execution with MCP for efficient agents
Efficiency gains:
๐ 98.7% fewer tokens when discovering tools progressively vs loading all upfront
๐ Intermediate results stay in code - Process large datasets without bloating context
โก Single execution - Complex multi-step workflows in one code block instead of chained tool calls
This aligns with Anthropic's research showing agents scale better by writing code to call tools rather than making direct tool calls for each operation.
๐ Not Locked to Claude UI
Unlike the Claude interface, this system uses the Model Context Protocol (MCP), which is:
โ Universal - Works with Claude Desktop, claude.ai, Cursor, and any MCP-compatible client
โ Not tied to Claude - Same skills work everywhere MCP is supported
โ Future-proof - Not dependent on Claude's ecosystem or policy changes
โ Local-first - Full control over your skills and data
๐ฏ Use Skills Everywhere
Your skills can run in:
Cursor - IDE integration with MCP support
Claude Desktop - Native app with MCP access
claude.ai - Web interface with MCP support
Any MCP client - Growing ecosystem of compatible applications
๐ฆ Independent & Modular
โ Each skill is self-contained with its own files, scripts, and environment
โ No dependency on proprietary Claude features
โ Can be versioned, shared, and reused across projects
โ Standard MCP protocol ensures compatibility
๐ Share Skills Across All MCP Clients
โ One skill directory, multiple clients - Create once, use everywhere
โ Same skills in Cursor and Claude - No duplication needed
โ Seamless switching - Move between tools without reconfiguring
โ Consistent experience - Skills work identically across all MCP clients
โ Centralized management - Update skills in one place, available everywhere
๐ค LLM-Managed Skills (No Manual Copy-Paste)
Instead of manually copying, zipping, and uploading files:
โ OLD WAY: Manual process
1. Create skill files locally
2. Zip the skill folder
3. Upload to Claude interface
4. Wait for processing
5. Can't easily modify or version
โ
NEW WAY: LLM-managed programmatically
1. Tell Claude: "Create a new skill called 'data-processor'"
2. Claude creates the skill directory and SKILL.md
3. Tell Claude: "Add a Python script to process CSVs"
4. Claude creates and tests the script
5. Tell Claude: "Set the API key for this skill"
6. Claude updates the .env file
7. Tell Claude: "Run the script with this data"
8. Claude executes it and shows results - all instantly!Key Benefits:
โ No manual file operations - LLM handles creation, editing, deletion
โ Instant changes - No upload/download/reload cycles
โ Full version control - Skills are regular files, can use git
โ Easy modification - LLM can edit scripts on the fly
โ Testable - LLM can create and run scripts immediately
โ Collaborative - Teams can develop skills together via MCP
Features
Skill Management
โ List all available skills
โ Browse skill files and directory structure
โ Read skill files (SKILL.md, scripts, references, assets)
โ Create new skill files and directories
โ Update existing skill files
โ Delete skill files
Script Execution
โ Run Python, Bash, and other executable scripts
โ Automatic dependency management for Python scripts using uv inline metadata (PEP 723)
โ Automatic environment variable injection from secrets
โ Command-line argument support
โ Custom working directory support
โ Capture stdout and stderr
โ 30-second timeout for safety
Direct Python Execution - Multi-Skill Unification ๐
โ UNIFY MULTIPLE SKILLS in one execution - Combine utilities from different skills seamlessly
โ Execute Python code directly without creating script files
โ Cross-skill imports - Import modules from ANY skill as reusable libraries
โ Automatic dependency aggregation - Dependencies from ALL imported skills auto-merged
โ Environment variable loading - .env files from ALL referenced skills auto-loaded
โ PEP 723 support - Inline dependency declarations in code
โ 98.7% more efficient - Follows Anthropic's recommended MCP pattern for scalable agents
โ Perfect for multi-skill workflows, quick experiments, data analysis, and complex pipelines
Environment Variables
โ List environment variable keys (secure - no values shown)
โ Set or update environment variables per skill
โ Persistent storage in per-skill
.envfilesโ Automatic injection into script execution
Directory Structure
~/.skill-mcp/
โโโ skills/ # Your skills directory
โโโ example-skill/
โ โโโ SKILL.md # Required: skill definition
โ โโโ .env # Optional: skill-specific environment variables
โ โโโ scripts/ # Optional: executable scripts
โ โโโ references/ # Optional: documentation
โ โโโ assets/ # Optional: templates, files
โโโ another-skill/
โโโ SKILL.md
โโโ .envNote: The MCP server is installed via uvx from PyPI and runs automatically. No local server file needed!
Quick Start
1. Install uv
This project uses uv for fast, reliable Python package management.
# Install uv (includes uvx)
curl -LsSf https://astral.sh/uv/install.sh | sh2. Configure Your MCP Client
Add the MCP server to your configuration. The server will be automatically downloaded and run via uvx from PyPI.
Claude Desktop - Edit the config file:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.jsonLinux:
~/.config/Claude/claude_desktop_config.json
Cursor - Edit the config file:
macOS:
~/.cursor/mcp.jsonWindows:
%USERPROFILE%\.cursor\mcp.jsonLinux:
~/.cursor/mcp.json
{
"mcpServers": {
"skill-mcp": {
"command": "uvx",
"args": [
"--from",
"skill-mcp",
"skill-mcp-server"
]
}
}
}That's it! No installation needed - uvx will automatically download and run the latest version from PyPI.
3. Restart Your MCP Client
Restart Claude Desktop or Cursor to load the MCP server.
4. Test It
In a new conversation:
List all available skillsClaude should use the skill-mcp tools to show skills in ~/.skill-mcp/skills/.
Common uv Commands
For development in this repository:
uv sync # Install/update dependencies
uv run python script.py # Run Python with project environment
uv add package-name # Add a new dependency
uv pip list # Show installed packages
uv run pytest tests/ -v # Run testsNote: uv automatically creates and manages .venv/ - no need to manually create virtual environments!
Script Dependencies (PEP 723)
โ
BOTH run_skill_script AND execute_python_code support PEP 723!
Python scripts and code can declare their own dependencies using uv's inline metadata. The server automatically detects this and uses uv run to handle dependencies:
#!/usr/bin/env python3
# /// script
# dependencies = [
# "requests>=2.31.0",
# "pandas>=2.0.0",
# ]
# ///
import requests
import pandas as pd
# Your script code here - dependencies are automatically installed!
response = requests.get("https://api.example.com/data")
df = pd.DataFrame(response.json())
print(df.head())Benefits:
โ No manual dependency installation needed
โ Each script/code execution has isolated dependencies
โ Works automatically with both
run_skill_scriptandexecute_python_codeโ Version pinning ensures reproducibility
โ
execute_python_codeALSO aggregates dependencies from skill imports!
How it works with run_skill_script:
You add inline metadata to your Python script file
When the script runs via
run_skill_script, the server detects the metadatauv automatically creates an isolated environment and installs dependencies
The script runs with access to those dependencies
No manual
pip installor virtual environment management needed!
How it works with execute_python_code:
Include PEP 723 metadata directly in your code string
The server automatically detects the metadata
uv creates an isolated environment and installs dependencies
Your code runs with access to those dependencies
BONUS: If you import from skill files, their PEP 723 dependencies are automatically aggregated too!
Example: See example-skill/scripts/fetch_data.py for a working example.
Testing locally:
# Scripts with dependencies just work!
uv run example-skill/scripts/fetch_data.pyDirect Python Code Execution - Unify Multiple Skills in One Run
The execute_python_code tool allows you to run Python code that combines multiple skills in a single execution. This is perfect for:
๐ Multi-skill workflows - Import and compose utilities from different skills
๐งช Quick experiments - Test code without creating files
๐ Data analysis - Process data using libraries from multiple skills
๐๏ธ Building on reusable skill libraries - Create specialized utilities once, use everywhere
Key insight from Anthropic's research: Agents scale better by writing code to call tools instead of making direct tool calls. This approach reduces context usage by up to 98.7% and enables more efficient workflows.
Basic Usage
# Simple inline execution with dependencies
# /// script
# dependencies = [
# "requests>=2.31.0",
# ]
# ///
import requests
response = requests.get("https://api.example.com/data")
print(response.json())Cross-Skill Imports - Unifying Multiple Skills
The power of composition - Create utility skills once and combine them in endless ways:
Real-world example: Process sales data by unifying calculator, data-processor, and CRM skills:
Step 1: Create a calculator skill with reusable modules
# calculator:math_utils.py
def add(a, b):
return a + b
def multiply(a, b):
return a * bStep 2: Create data-processor skill utilities
# data-processor:csv_parser.py
# /// script
# dependencies = ["pandas>=2.0.0"]
# ///
import pandas as pd
def parse_csv_url(url):
return pd.read_csv(url)
def filter_by_status(df, status):
return df[df['status'] == status]Step 3: Unify both skills in one execution!
# Execute with skill_references: ["calculator:math_utils.py", "data-processor:csv_parser.py"]
from math_utils import calculate_average
from csv_parser import parse_csv_url, filter_by_status
# Get sales data
sales_df = parse_csv_url('https://example.com/sales.csv')
# Filter active deals
active_deals = filter_by_status(sales_df, 'active')
# Calculate average deal size using calculator skill
deal_values = active_deals['amount'].tolist()
avg_deal = calculate_average(deal_values)
print(f"Active deals: {len(active_deals)}")
print(f"Average deal size: ${avg_deal:,.2f}")What just happened:
โ Two skills unified - calculator + data-processor in one execution
โ Zero redundancy - pandas dependency declared once in csv_parser.py, auto-included
โ Composable - Mix and match any skills like LEGO blocks
โ Context-efficient - Only loaded the specific modules needed
Automatic Dependency Aggregation
When you import from skill modules that have PEP 723 dependencies, they're automatically included:
Library skill with dependencies:
# data-processor:json_fetcher.py
# /// script
# dependencies = ["requests>=2.31.0"]
# ///
import requests
def fetch_json(url):
return requests.get(url).json()Your code - NO need to redeclare requests!
# Execute with skill_references: ["data-processor:json_fetcher.py"]
from json_fetcher import fetch_json
data = fetch_json('https://api.example.com')
print(data)
# Dependencies from json_fetcher.py are automatically aggregated!Environment Variables from Referenced Skills
When you import from a skill, its environment variables are automatically loaded:
Skill with API credentials:
# weather-skill/.env
API_KEY=your-secret-api-key
API_URL=https://api.weatherapi.comYour code - env vars automatically available:
# Execute with skill_references: ["weather-skill:api_client.py"]
from api_client import fetch_weather
# api_client.py can access API_KEY and API_URL from its .env file
data = fetch_weather('London')
print(data)Benefits:
โ No need to manually load .env files
โ Each skill's secrets stay isolated
โ Multiple skills' env vars are merged automatically
โ Later skills override earlier ones if there are conflicts
Use Cases
๐ Multi-skill workflows - THE KILLER FEATURE - Unify utilities from multiple skills in one execution
Example: Combine API client + data parser + analytics calculator in single run
Example: Chain together scraper + NLP processor + notification sender
Example: Merge CRM data + payment processor + reporting tools
โ Quick data analysis - Run pandas/numpy code without creating files
โ API testing - Test HTTP requests with inline dependencies
โ Reusable libraries - Build once, import everywhere
โ Rapid prototyping - Experiment with code before committing to files
โ Complex pipelines - Build multi-stage data processing in one code block
Comparison: run_skill_script vs execute_python_code
Both tools support PEP 723, but have different use cases:
Feature |
|
|
PEP 723 Support | โ YES | โ YES |
Requires file | โ Yes - executes existing script files | โ No - runs code directly |
Languages supported | Python, JavaScript, Bash, any executable | Python only |
Cross-skill imports | โ No - single skill only | โ YES - UNIFY MULTIPLE SKILLS |
Dependency aggregation | โ No | โ YES - auto-merges deps from all imported skills |
Environment loading | Loads skill's .env only | Loads .env from ALL referenced skills |
Context efficiency | Standard | 98.7% token reduction (Anthropic research) |
Best for | Running complete scripts, batch jobs | Multi-skill workflows, quick experiments |
Example use case |
|
|
Key Insight:
Use
run_skill_scriptwhen you have a script file ready to executeUse
execute_python_codewhen you want to UNIFY MULTIPLE SKILLS in one execution - This is the recommended approach per Anthropic's MCP research for building efficient, scalable agents
Usage Examples
Creating a New Skill
User: "Create a new skill called 'pdf-processor' that can rotate and merge PDFs"
Claude will:
1. Create the skill directory and SKILL.md
2. Add any necessary scripts
3. Test the scripts
4. Guide you through setting up any needed dependenciesManaging Environment Variables
User: "I need to set up a GitHub API token for my GitHub skills"
Claude will:
1. Guide you to add it to the skill's .env file
2. Use `read_skill_env` to list available keys
3. Confirm it's available for scripts to use via `os.environ`Running Skill Scripts
User: "Run the data processing script from my analytics skill"
Claude will:
1. List available skills and scripts
2. Execute the script with environment variables
3. Show you the output and any errorsModifying Existing Skills
User: "Add a new reference document about our API schema to the company-knowledge skill"
Claude will:
1. Read the existing skill structure
2. Create the new reference file
3. Update SKILL.md if needed to reference itAvailable MCP Tools
The server provides these unified CRUD tools to Claude:
Tool | Purpose | PEP 723 Support |
| Unified skill operations: list, get, create, delete, validate, list_templates | N/A |
| Unified file operations: read, create, update, delete (supports bulk operations) | N/A |
| Unified environment variable operations: read, set, delete, clear | N/A |
| Execute scripts (.py, .js, .sh) with automatic dependency detection | โ YES - Auto-detects PEP 723 in Python scripts |
| Execute Python code directly without files (cross-skill imports) | โ YES - PEP 723 PLUS dependency aggregation |
Key Benefits of CRUD Architecture:
โ Reduced context window usage - 5 tools instead of 9+
โ Consistent operation patterns - All tools follow the same CRUD model
โ Bulk operations - Create/update/delete multiple files atomically
โ Better error handling - Unified error responses across all operations
Security Features
Path Validation
All file paths are validated to prevent directory traversal attacks
Paths with ".." or starting with "/" are rejected
All operations are confined to the skill directory
Environment Variables
Variable values are never exposed when listing
Stored in per-skill
.envfilesFile permissions should be restricted (chmod 600 on each .env)
Script Execution
30-second timeout prevents infinite loops
Scripts run with user's permissions (not elevated)
Output size limits prevent memory issues
Capture both stdout and stderr for debugging
Troubleshooting
"MCP server not found"
Check that
uvis in your PATH:which uv(orwhere uvon Windows)Verify the path to
.skill-mcpdirectory is correct and absoluteTest dependencies:
cd ~/.skill-mcp && uv run python -c "import mcp; print('OK')"Ensure
pyproject.tomlexists in~/.skill-mcp/
"Permission denied" errors
chmod +x ~/.skill-mcp/skill_mcp_server.py
chmod 755 ~/.skill-mcp
chmod 755 ~/.skill-mcp/skills
find ~/.skill-mcp/skills -name ".env" -exec chmod 600 {} \;Scripts failing to execute
Check script has execute permissions
Verify interpreter (python3, bash) is in PATH
Use
list_env_keysto check required variables are setCheck stderr output from
run_skill_script
Environment variables not working
Verify they're set: use
read_skill_envfor the skillCheck the .env file exists:
cat ~/.skill-mcp/skills/<skill-name>/.envEnsure your script is reading from
os.environ
Advanced: CRUD Tool Operations
All MCP tools follow a unified CRUD architecture with detailed descriptions:
skill_crud Operations
list - List all skills with descriptions, paths, and validation status (supports text/regex search)
get - Get comprehensive skill information: SKILL.md content, all files, scripts, environment variables
create - Create new skill from template (basic, python, bash, nodejs)
delete - Delete a skill directory (requires confirmation)
validate - Validate skill structure and get diagnostics
list_templates - List all available skill templates with descriptions
skill_files_crud Operations
read - Read one or multiple files in a skill directory (supports bulk reads)
create - Create one or more files (auto-creates parent directories, supports atomic bulk creation)
update - Update one or more existing files (supports bulk updates)
delete - Delete a file permanently (path-traversal protected, SKILL.md cannot be deleted)
skill_env_crud Operations
read - List environment variable keys for a skill (values hidden for security)
set - Set one or more environment variables (merges with existing)
delete - Delete one or more environment variables
clear - Clear all environment variables for a skill
Script Execution
run_skill_script - Execute scripts with automatic PEP 723 dependency detection and environment variable injection
execute_python_code - Execute Python code directly without files (supports PEP 723 dependencies and cross-skill imports)
Advanced Configuration
Custom Skills Directory
The skills directory can be customized using the SKILL_MCP_DIR environment variable. If not set, it defaults to ~/.skill-mcp/skills.
Setting via environment variable (recommended):
# Temporarily for current session
export SKILL_MCP_DIR="/custom/path/to/skills"
# Permanently in your shell config (~/.bashrc, ~/.zshrc, etc.)
echo 'export SKILL_MCP_DIR="/custom/path/to/skills"' >> ~/.zshrcIn MCP client configuration:
For Claude Desktop or Cursor, add the environment variable to your MCP config:
{
"mcpServers": {
"skill-mcp": {
"command": "uvx",
"args": [
"--from",
"skill-mcp",
"skill-mcp-server"
],
"env": {
"SKILL_MCP_DIR": "/custom/path/to/skills"
}
}
}
}Notes:
The directory will be created automatically if it doesn't exist
Use absolute paths for the custom directory
All skills will be stored in the configured directory
No global secrets file; env vars are per-skill .env files
Resource Limits
Resource limits are defined in src/skill_mcp/core/config.py:
MAX_FILE_SIZE = 1_000_000 # File read limit (1MB)
MAX_OUTPUT_SIZE = 100_000 # Script output limit (100KB)
SCRIPT_TIMEOUT_SECONDS = 30 # Script execution timeoutTo modify these limits, you'll need to fork the repository and adjust the constants in the config file.
Architecture & Implementation
Package Structure
src/skill_mcp/
โโโ server.py # MCP server entry point
โโโ models.py # Pydantic input/output models (backward compat)
โโโ models_crud.py # Unified CRUD input models
โโโ core/
โ โโโ config.py # Configuration constants
โ โโโ exceptions.py # Custom exception types
โโโ services/
โ โโโ env_service.py # Environment variable CRUD
โ โโโ file_service.py # File CRUD operations
โ โโโ skill_service.py # Skill discovery & metadata
โ โโโ script_service.py # Script execution & PEP 723
โ โโโ template_service.py # Template management
โโโ utils/
โ โโโ path_utils.py # Secure path validation
โ โโโ yaml_parser.py # YAML frontmatter parsing
โ โโโ script_detector.py # Script capability detection
โโโ tools/
โโโ skill_crud.py # Unified skill CRUD tool
โโโ skill_files_crud.py # Unified file CRUD tool
โโโ skill_env_crud.py # Unified env CRUD tool
โโโ script_tools.py # Script execution tools
tests/
โโโ conftest.py # Pytest fixtures
โโโ 20+ test modules # 145 tests (86% coverage passing)What's New
Unified CRUD Architecture:
โ 3 unified CRUD tools instead of 9+ individual tools (skill_crud, skill_files_crud, skill_env_crud)
โ Bulk operations - Create/update/delete multiple files atomically
โ Consistent patterns - All tools follow the same operation-based model
โ Better error handling - Unified error responses across all operations
Direct Python Execution (Multi-Skill Unification):
๐ execute_python_code - UNIFY MULTIPLE SKILLS in one execution (Anthropic's recommended MCP pattern)
โ Cross-skill imports - Import modules from ANY skill as reusable libraries
โ Automatic dependency aggregation - Dependencies from ALL imported skills auto-merged
โ Automatic environment loading - .env files from ALL referenced skills auto-loaded
โ PEP 723 support - Inline dependency declarations
๐ 98.7% token reduction - Load skills progressively instead of all upfront
Enhanced Features:
โ Skill templates - Create skills from templates (basic, python, bash, nodejs)
โ Template discovery - List all available templates with descriptions
โ Skill validation - Validate skill structure and get diagnostics
โ Search capabilities - Search skills by name/description with text or regex
โ Namespaced paths - File paths shown as "skill_name:file.py" for clarity
โ Configurable skills directory - Use SKILL_MCP_DIR environment variable
Test Results
Unit Tests: 145/145 Passing โ
Coverage: 86% (959/1120 statements covered)
Comprehensive test coverage across all modules:
Module | Coverage | Key Areas |
Core Config | 100% | All configuration constants |
Models & CRUD Models | 100% | Input/Output validation |
Exception Handling | 100% | All exception types |
YAML Parser | 90% | Frontmatter parsing |
Skill Service | 90% | Skill discovery & metadata |
Template Service | 96% | Template management |
File Service | 83% | File CRUD operations |
Environment Service | 85% | Environment variable CRUD |
Skill CRUD Tool | 91% | Unified skill operations |
Skill Files CRUD Tool | 88% | Unified file operations |
Skill Env CRUD Tool | 96% | Unified env operations |
Script Detector | 85% | Script capability detection |
Path Utils | 86% | Path validation & security |
Server | 76% | MCP tool registration |
Script Service | 78% | Script execution & PEP 723 |
Script Tools | 29% | Script execution tools |
Test Organization:
โ CRUD operations: Comprehensive tests for all operations (create, read, update, delete)
โ Bulk operations: Atomic transaction tests for file operations
โ Template system: Template discovery, validation, and creation
โ Path security: Directory traversal prevention and validation
โ PEP 723 support: Dependency detection and aggregation
โ Integration tests: Full MCP server workflow testing
Manual Tests: All Passed โ
โ List skills with YAML descriptions and search functionality
โ Get comprehensive skill details with SKILL.md content
โ Create skills from templates (basic, python, bash, nodejs)
โ Read/create/update/delete files (single and bulk)
โ Read/set/delete/clear environment variables
โ Execute scripts with auto-dependencies (PEP 723)
โ Execute Python code directly with cross-skill imports
โ Dependency aggregation from imported skill modules
โ Environment variable loading from referenced skills
Verification Checklist
โ Server imports successfully
โ All 5 unified CRUD tools registered and callable
โ 145/145 unit tests passing (86% coverage)
โ All manual tests passing
โ MCP client configuration working (Claude Desktop, Cursor)
โ Package deployed to PyPI and active
โ Scripts execute successfully with PEP 723 dependencies
โ File operations working (including bulk operations)
โ Environment variables working (CRUD operations)
โ Template system working (create, list, validate)
โ Direct Python execution working with cross-skill imports
โ Backward compatible with existing skills
Best Practices
Skill Development
Follow the standard skill structure (SKILL.md, scripts/, references/, assets/)
Keep SKILL.md concise and focused
Use progressive disclosure (split large docs into references)
Test scripts immediately after creation
Environment Variables
Use descriptive names (API_KEY, DATABASE_URL)
Never log or print sensitive values
Set permissions on .env files:
chmod 600 ~/.skill-mcp/skills/<skill-name>/.env
Script Development
Use meaningful exit codes (0 = success)
Print helpful messages to stdout
Print errors to stderr
Include error handling
For Python scripts with dependencies: Use inline metadata (PEP 723)
# /// script # dependencies = [ # "package-name>=version", # ] # ///Scripts without metadata use the system Python interpreter
Scripts with metadata automatically get isolated environments via uv
๐ Managing Sensitive Secrets Safely
To prevent LLMs from accessing your sensitive credentials:
โ RECOMMENDED: Update .env files directly on the file system
# Edit the skill's .env file directly (LLM cannot access your local files)
nano ~/.skill-mcp/skills/my-skill/.env
# Add your secrets manually
API_KEY=your-actual-api-key-here
DATABASE_PASSWORD=your-password-here
OAUTH_TOKEN=your-token-here
# Secure the file
chmod 600 ~/.skill-mcp/skills/my-skill/.envWhy this is important:
โ LLMs never see your sensitive values
โ Secrets stay on your system only
โ No risk of credentials appearing in logs or outputs
โ Full control over sensitive data
โ Can be used with
git-secretor similar tools for versioning
Workflow:
Claude creates the skill structure and scripts
You manually add sensitive values to
.envfilesClaude can read the
.envkeys (without seeing values) and use themScripts access secrets via environment variables at runtime
Example:
# Step 1: Claude creates skill "api-client" via MCP
# You say: "Create a new skill called 'api-client'"
# Step 2: You manually secure the secrets
$ nano ~/.skill-mcp/skills/api-client/.env
API_KEY=sk-abc123def456xyz789
ENDPOINT=https://api.example.com
$ chmod 600 ~/.skill-mcp/skills/api-client/.env
# Step 3: Claude can now use the skill securely
# You say: "Run the API client script"
# Claude reads env var names only, uses them in scripts
# Your actual API key is never exposed to Claudeโ NEVER DO:
โ Tell Claude your actual API keys or passwords
โ Ask Claude to set environment variables with sensitive values
โ Store secrets in SKILL.md or other tracked files
โ Use
update_skill_envtool with real secrets (only for non-sensitive config)
โ DO:
โ Update
.envfiles manually on your systemโ Keep
.envfiles in.gitignoreโ Use
chmod 600to restrict file accessโ Tell Claude only the variable names (e.g., "the API key is in API_KEY")
โ Keep secrets completely separate from LLM interactions
โ ๏ธ Important: Verify LLM-Generated Code
When Claude or other LLMs create or modify skills and scripts using this MCP system, always verify the generated code before running it in production:
Security Considerations
โ ๏ธ Always review generated code - LLMs can make mistakes or generate suboptimal code
โ ๏ธ Check for security issues - Look for hardcoded credentials, unsafe operations, or vulnerabilities
โ ๏ธ Test thoroughly - Run scripts in isolated environments first
โ ๏ธ Validate permissions - Ensure scripts have appropriate file and system permissions
โ ๏ธ Monitor dependencies - Review any external packages installed via PEP 723
Best Practices for LLM-Generated Skills
Review before execution - Always read through generated scripts
Test in isolation - Run in a safe environment before production use
Use version control - Track all changes with git for audit trails
Implement error handling - Add robust error handling and logging
Set resource limits - Use timeouts and resource constraints
Run with minimal permissions - Don't run skills as root or with elevated privileges
Validate inputs - Sanitize any user-provided data
Audit logs - Review what scripts actually do and track their execution
Common Things to Check
โ Hardcoded API keys, passwords, or tokens
โ Unsafe file operations or path traversal risks
โ Unvalidated external commands or shell injection risks
โ Missing error handling or edge cases
โ Resource-intensive operations without limits
โ Unsafe deserialization (eval, pickle, etc.)
โ Excessive permissions requested
โ Untrustworthy external dependencies
When in Doubt
Ask Claude/LLM to explain the code
Have another person review critical code
Use linters and security scanning tools
Run in containers or VMs for isolation
Start with read-only operations before destructive ones
Remember: LLM-generated code is a starting point. Your verification and review are essential for security and reliability.
Installation from PyPI
To install the package globally (optional):
pip install skill-mcpOr use uvx to run without installation (recommended):
uvx --from skill-mcp skill-mcp-serverDevelopment Setup
If you want to contribute or run from source:
# Clone the repository
git clone https://github.com/fkesheh/skill-mcp.git
cd skill-mcp
# Install dependencies
uv sync
# Run tests
uv run pytest
# Run the server locally
uv run -m skill_mcp.serverTo use your local development version in your MCP client config:
{
"mcpServers": {
"skill-mcp": {
"command": "uv",
"args": [
"run",
"--directory",
"/path/to/your/skill-mcp",
"-m",
"skill_mcp.server"
]
}
}
}License
MIT License
Copyright (c) 2025
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Contributing
This is a custom tool for personal use. Feel free to fork and adapt for your needs.
Support
For setup issues or questions, refer to:
Claude's MCP documentation at https://modelcontextprotocol.io
The MCP Python SDK docs at https://github.com/modelcontextprotocol/python-sdk
Available Tools
5 toolsexecute_python_codeA
Execute Python code directly without requiring a script file.
RECOMMENDATION: Prefer Python over bash/shell scripts for better portability, error handling, and maintainability.
IMPORTANT: Use this tool instead of creating temporary script files when you need to run quick Python code.
โ SUPPORTS PEP 723 INLINE DEPENDENCIES - just like run_skill_script!
FEATURES:
PEP 723 inline dependencies: Include dependencies directly in code using /// script comments (auto-detected and installed)
Dependency aggregation: When importing from skills, their PEP 723 dependencies are automatically merged into your code
Skill file imports: Reference files from skills using namespace format (skill_name:path/to/file.py)
Automatic dependency installation: Code with PEP 723 metadata is run with 'uv run'
Environment variable loading: Automatically loads .env files from all referenced skills
Clean execution: Temporary file is automatically cleaned up after execution
PARAMETERS:
code: Python code to execute (can include PEP 723 dependencies)
skill_references: Optional list of skill files to make available for import Format: ["calculator:utils.py", "weather:api/client.py"] The skill directories will be added to PYTHONPATH Environment variables from each skill's .env file will be loaded
timeout: Optional timeout in seconds (defaults to 30 seconds if not specified)
CROSS-SKILL IMPORTS - BUILD REUSABLE LIBRARIES: Create utility skills once, import them anywhere! Perfect for:
Math/statistics libraries (calculator:stats.py)
API clients (weather:api_client.py)
Data processors (etl:transformers.py)
Common utilities (helpers:string_utils.py)
AUTOMATIC DEPENDENCY AGGREGATION: When you reference skill files, their PEP 723 dependencies are automatically collected and merged into your code! You don't need to redeclare dependencies - just reference the modules and their deps are included automatically.
Example - library module with deps:
# data-processor:json_fetcher.py
# /// script
# dependencies = ["requests>=2.31.0"]
# ///
import requests
def fetch_json(url): return requests.get(url).json()Your code - NO need to declare requests!
{
"code": "from json_fetcher import fetch_json\ndata = fetch_json('https://api.example.com')\nprint(data)",
"skill_references": ["data-processor:json_fetcher.py"]
}Dependencies from json_fetcher.py are automatically aggregated!
Import from single skill:
{
"code": "from math_utils import add, multiply\nprint(add(10, 20))",
"skill_references": ["calculator:math_utils.py"]
}Import from multiple skills:
{
"code": "from math_utils import add\nfrom stats_utils import mean\nfrom converters import celsius_to_fahrenheit\n\nresult = add(10, 20)\navg = mean([10, 20, 30])\ntemp = celsius_to_fahrenheit(25)\nprint(f'Sum: {result}, Avg: {avg}, Temp: {temp}F')",
"skill_references": ["calculator:math_utils.py", "calculator:stats_utils.py", "calculator:converters.py"]
}Import from subdirectories:
{
"code": "from advanced.calculus import derivative_at_point\ndef f(x): return x**2\nprint(derivative_at_point(f, 5))",
"skill_references": ["calculator:advanced/calculus.py"]
}ENVIRONMENT VARIABLES FROM REFERENCED SKILLS: When you import from a skill, its environment variables are automatically loaded:
{
"code": "from api_client import fetch_weather\ndata = fetch_weather('London')\nprint(data)",
"skill_references": ["weather:api_client.py"]
}If weather:api_client.py uses API_KEY from its .env file, it will be available automatically!
EXAMPLE WITH PEP 723 DEPENDENCIES:
{
"code": "# /// script\n# dependencies = [\n# \"requests>=2.31.0\",\n# \"pandas\",\n# ]\n# ///\n\nimport requests\nimport pandas as pd\n\nresponse = requests.get('https://api.example.com/data')\ndf = pd.DataFrame(response.json())\nprint(df.head())"
}WHY PYTHON OVER BASH/JS:
Better error handling and debugging
Rich standard library
Cross-platform compatibility
Easier to read and maintain
Strong typing support
Better dependency management
RETURNS: Execution result with:
Exit code (0 = success, non-zero = failure)
STDOUT (standard output)
STDERR (error output)
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Python code to execute (can include PEP 723 dependencies) | |
| skill_references | No | Optional list of skill files to import using namespace format (e.g., 'calculator:utils.py') | |
| timeout | No | Optional timeout in seconds (defaults to 30 seconds if not specified) |
TDQS
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.
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.
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.
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.
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.
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.
run_skill_scriptA
Execute a script within a skill directory. Skills are modular libraries with reusable code - scripts can import from their own modules or use external dependencies.
IMPORTANT: ALWAYS use this tool to execute scripts. DO NOT use external bash/shell tools to execute scripts directly. This tool provides:
Automatic dependency management (Python PEP 723, npm packages)
Proper environment variable injection from .env files
Secure execution within skill directory boundaries
Proper error handling and output capture
SKILLS AS LIBRARIES: Scripts within a skill can import from local modules naturally:
weather-skill/
โโโ main.py # Script that imports from modules below
โโโ api_client.py # Reusable API client module
โโโ parsers.py # Data parsing utilities
โโโ formatters.py # Output formattingIn main.py:
from api_client import WeatherAPI
from formatters import format_temperature
api = WeatherAPI()
data = api.get_weather("London")
print(format_temperature(data))Execute with:
{
"skill_name": "weather-skill",
"script_path": "main.py",
"args": ["--city", "London"]
}SUPPORTED LANGUAGES:
Python: Automatically detects and installs PEP 723 inline dependencies via 'uv run'
JavaScript/Node.js: Automatically runs 'npm install' if package.json exists
Bash: Executes shell scripts (.sh files)
Other: Any executable file with proper shebang line
FEATURES:
Module imports: Scripts can import from other files within the skill directory
Automatic PEP 723 dependency detection: Python scripts with inline metadata are automatically run with 'uv run'
Automatic npm dependency installation: Node.js scripts install dependencies from package.json
Environment variables: Loads skill-specific .env file and injects variables into script environment
Working directory: Can specify a subdirectory to run the script from
Arguments: Pass command-line arguments to the script
Output capture: Returns stdout, stderr, and exit code
PEP 723 AUTOMATIC DEPENDENCY DETECTION: Python scripts with inline dependencies are automatically detected and executed with 'uv run':
Example Python script with PEP 723 (e.g., weather-skill/fetch_weather.py):
#!/usr/bin/env python3
# /// script
# dependencies = [
# "requests>=2.31.0",
# "beautifulsoup4>=4.12.0",
# ]
# ///
import requests
from bs4 import BeautifulSoup
response = requests.get("https://api.weather.com/data")
print(response.json())Execute with automatic dependency handling:
{
"skill_name": "weather-skill",
"script_path": "fetch_weather.py",
"args": ["--city", "London"]
}No manual dependency installation needed - the server automatically:
Detects the PEP 723 metadata in your script
Uses 'uv run' to create an isolated environment
Installs the declared dependencies
Executes your script with access to those dependencies
PARAMETERS:
skill_name: The name of the skill directory (e.g., 'weather-skill')
script_path: Relative path to the script within skill directory (e.g., 'main.py', 'scripts/fetch_weather.py', 'bin/process.sh')
args: Optional list of command-line arguments (e.g., ['--verbose', 'input.txt'])
working_dir: Optional working directory relative to skill root (e.g., 'scripts')
timeout: Optional timeout in seconds (defaults to 30 seconds if not specified)
IMPORTANT PATH NOTES:
All paths are RELATIVE to the skill directory, never absolute paths
Script path example: 'main.py' NOT '/Users/username/.skill-mcp/skills/my-skill/main.py'
Working dir example: 'scripts' NOT '/full/path/to/scripts'
RETURNS: Script execution result with:
Exit code (0 = success, non-zero = failure)
STDOUT (standard output)
STDERR (error output)
| Name | Required | Description | Default |
|---|---|---|---|
| skill_name | Yes | Name of the skill | |
| script_path | Yes | Relative path to the script within the skill directory | |
| args | No | Optional command-line arguments to pass to the script | |
| working_dir | No | Optional working directory for script execution | |
| timeout | No | Optional timeout in seconds (defaults to 30 seconds if not specified) |
TDQS
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.
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.
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.
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.
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.
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.
skill_crudA
Unified CRUD tool for skill management.
IMPORTANT NOTES:
Skills are stored in ~/.skill-mcp/skills directory
All file paths in responses are relative to the skill directory (e.g., 'main.py', not full paths)
To execute scripts, use the 'run_skill_script' tool, NOT external bash/shell tools
Operations:
create: Create a new skill with templates (basic, python, bash, nodejs)
list: List all skills with optional search (supports text and regex)
search: Search for skills by pattern (text or regex)
get: Get detailed information about a specific skill
validate: Validate skill structure and get diagnostics
delete: Delete a skill directory (requires confirm=true)
list_templates: List all available skill templates with descriptions
Examples:
// List available templates
{"operation": "list_templates"}
// Create a Python skill
{"operation": "create", "skill_name": "my-skill", "description": "My skill", "template": "python"}
// List all skills
{"operation": "list"}
// Search skills by text
{"operation": "search", "search": "weather"}
// Search skills by regex pattern
{"operation": "search", "search": "^api-"}
// Get skill details
{"operation": "get", "skill_name": "my-skill", "include_content": true}
// Validate skill
{"operation": "validate", "skill_name": "my-skill"}
// Delete skill
{"operation": "delete", "skill_name": "my-skill", "confirm": true}| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Operation to perform: 'create', 'list', 'get', 'validate', 'delete' | |
| skill_name | No | Name of the skill (required for get, validate, delete, create) | |
| description | No | Skill description (optional for create) | |
| template | No | Template to use for create: 'basic', 'python', 'bash', 'nodejs' | basic |
| search | No | Search pattern for list (text or regex) | |
| include_content | No | Include SKILL.md content in get operation | |
| confirm | No | Confirm delete operation (required for delete) |
TDQS
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.
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.
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.
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.
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.
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.
skill_env_crudA
Unified CRUD tool for skill environment variable operations. Supports single and bulk operations.
Operations:
read: Read all environment variable keys (values are hidden for security)
set: Set one or more environment variables (merges with existing)
delete: Delete one or more environment variables
clear: Clear all environment variables
Examples:
// Read all env var keys
{
"operation": "read",
"skill_name": "my-skill"
}
// Set single variable (merges with existing)
{
"operation": "set",
"skill_name": "my-skill",
"variables": {"API_KEY": "sk-123"}
}
// Set multiple variables (bulk merge)
{
"operation": "set",
"skill_name": "my-skill",
"variables": {
"API_KEY": "sk-123",
"DEBUG": "true",
"TIMEOUT": "30"
}
}
// Delete single variable
{
"operation": "delete",
"skill_name": "my-skill",
"keys": ["API_KEY"]
}
// Delete multiple variables
{
"operation": "delete",
"skill_name": "my-skill",
"keys": ["API_KEY", "DEBUG", "TIMEOUT"]
}
// Clear all environment variables
{
"operation": "clear",
"skill_name": "my-skill"
}Note: The 'set' operation always merges with existing variables. To replace everything, use 'clear' first, then 'set'.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Operation to perform: 'read', 'set', 'delete', 'clear' | |
| skill_name | Yes | Name of the skill | |
| variables | No | Variables to set (key-value pairs for 'set' operation) | |
| keys | No | Variable keys to delete (for 'delete' operation) |
TDQS
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.
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.
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.
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.
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.
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.
skill_files_crudA
Unified CRUD tool for skill file operations. Supports both single and bulk operations.
IMPORTANT PATH NOTES:
All file paths are RELATIVE to the skill directory (e.g., 'main.py', 'scripts/utils.py')
NEVER use absolute paths (e.g., NOT '/Users/username/.skill-mcp/skills/my-skill/main.py')
To execute scripts, use the 'run_skill_script' tool, NOT external bash/shell tools
Operations:
read: Read a file's content
create: Create one or more files (supports atomic mode for bulk)
update: Update one or more files
delete: Delete a file (SKILL.md is protected and cannot be deleted)
Single File Examples:
// Read a file
{"operation": "read", "skill_name": "my-skill", "file_path": "script.py"}
// Create a single file
{"operation": "create", "skill_name": "my-skill", "file_path": "new.py", "content": "print('hello')"}
// Update a single file
{"operation": "update", "skill_name": "my-skill", "file_path": "script.py", "content": "print('updated')"}
// Delete a file
{"operation": "delete", "skill_name": "my-skill", "file_path": "old.py"}Bulk File Examples:
// Read multiple files
{
"operation": "read",
"skill_name": "my-skill",
"file_paths": ["file1.py", "file2.py", "file3.py"]
}
// Create multiple files atomically (all-or-nothing)
{
"operation": "create",
"skill_name": "my-skill",
"files": [
{"path": "src/main.py", "content": "# Main"},
{"path": "src/utils.py", "content": "# Utils"},
{"path": "README.md", "content": "# Docs"}
],
"atomic": true
}
// Update multiple files
{
"operation": "update",
"skill_name": "my-skill",
"files": [
{"path": "file1.py", "content": "new content 1"},
{"path": "file2.py", "content": "new content 2"}
]
}| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Operation to perform: 'read', 'create', 'update', 'delete' | |
| skill_name | Yes | Name of the skill | |
| file_path | No | Relative path to file (for single file operations) | |
| content | No | File content (for single create/update) | |
| files | No | List of files for bulk create/update operations | |
| file_paths | No | List of file paths for bulk read operations | |
| atomic | No | Atomic mode: rollback all on error (for bulk create) |
TDQS
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.
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.
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.
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.
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.
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
13 tool updates
v1.0.0- Removed
create_skill_file - Removed
delete_skill_file - Added
execute_python_code - Removed
get_skill_details - Removed
list_skills - Removed
read_skill_env - Removed
read_skill_file - Changed
run_skill_script3 fields changed- added
Input schema / descriptionAdded value: +"Input for running a skill script." - added
Input schema / properties / timeoutAdded value: +{ + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional timeout in seconds (defaults to 30 seconds if not specified)", + "title": "Timeout" +} - added
Input schema / titleAdded value: +"RunSkillScriptInput"
- Added
skill_crud - Added
skill_env_crud - Added
skill_files_crud - Removed
update_skill_env - Removed
update_skill_file
9 tool updates
- First observed
create_skill_file - First observed
delete_skill_file - First observed
get_skill_details - First observed
list_skills - First observed
read_skill_env - First observed
read_skill_file - First observed
run_skill_script - First observed
update_skill_env - First observed
update_skill_file
TDQS
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.
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.
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.
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.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Path-scoped team memories, rules and skills for Claude Code, Cursor, Codex and other MCP clients.
Agent-first skill marketplace with USK open standard for Claude, Cursor, Gemini, Codex CLI.
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
1Manage portable AI agent playbooks, Agent Skills, MCP configurations, personas, and memory.
Related MCP Servers
- AlicenseAqualityBmaintenanceAllows Claude desktop app to execute terminal commands and edit files on your computer through MCP, with features including command execution, process management, and diff-based file editing.2638,9239,486MIT
- AlicenseAqualityDmaintenanceAllows Claude to execute terminal commands on your computer and perform file system operations including surgical code editing with diff-based replacements.1938,9237MIT
- AlicenseNot gradedqualityDmaintenanceTurns Claude-style skills (SKILL.md files with resources) into callable MCP tools for any agent. Discovers skills from a directory, exposes their instructions and resources, and can execute bundled helper scripts.399MIT
- FlicenseNot gradedqualityDmaintenanceExposes 1,334 skills as global MCP tools across Claude Desktop, VSCode, and Cursor, automatically discovering and categorizing skills from a local directory into 18 categories with semantic search capabilities.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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