local-skills-mcp
Click on "Deploy 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., "@local-skills-mcplist my available skills"
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.
π― Local Skills MCP
Enable any LLM or AI agent to utilize expert skills from your local filesystem via MCP
Quick Start β’ Features β’ Usage β’ FAQ β’ Contributing
π Table of Contents
Related MCP server: superpowers-mcp
What is Local Skills MCP?
A universal Model Context Protocol (MCP) server that enables any LLM or AI agent to access expert skills from your local filesystem. Write skills once, use them across Claude Code, Claude Desktop, Cline, Continue.dev, custom agents, or any MCP-compatible client.
Transform AI capabilities with structured, expert-level instructions for specialized tasks. Context-efficient lazy loadingβonly skill names/descriptions load initially (~50 tokens/skill), full content on-demand.
π Why Use Local Skills MCP?
Feature | Local Skills MCP | Built-in Claude Skills |
Portability | Any MCP client | Claude Code only |
Storage | Multiple directories aggregated |
|
Invocation | Explicit via MCP tool | Auto-invoked by Claude |
Context Usage | Lazy loading (names only) | All skills in context |
β¨ Features
π Universal - Works with any MCP client (Claude Code/Desktop, Cline, Continue.dev, custom agents)
π Portable - Write once, use across multiple AI systems and LLMs (Claude, GPT, Gemini, Ollama, etc.)
β‘ Context Efficient - Lazy loading (~50 tokens/skill for names/descriptions, full content loads on-demand)
π₯ Hot Reload - Changes apply instantly without restart (new skills, edits, deletions)
π― Multi-Source - Auto-aggregates from built-in skills,
~/.claude/skills,./.claude/skills,./skills, custom pathsπ¦ Zero Config - Works out-of-the-box with standard locations
β¨ Focused API - Three tools:
get_skillto load one,validate_skillto check a SKILL.md,evaluate_skillto measure how reliably it triggers
π Quick Start
1. Install
Requirements: Node.js 22+
Choose one installation method:
# From npm (recommended)
npm install -g local-skills-mcp
# From GitHub
npm install -g github:kdpa-llc/local-skills-mcp
# Or clone and build locally
git clone https://github.com/kdpa-llc/local-skills-mcp.git
cd local-skills-mcp
npm install # Automatically builds via prepare script2. Configure MCP Client
Add to your MCP client configuration:
For Claude Code/Desktop (~/.config/claude-code/mcp.json or ~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"local-skills": {
"command": "local-skills-mcp"
}
}
}For Cline: VS Code Settings β "Cline: MCP Settings" (same JSON structure)
For other MCP clients: Use the same command/args structure
If cloned locally (not installed globally), use:
{
"mcpServers": {
"local-skills": {
"command": "node",
"args": ["/absolute/path/to/local-skills-mcp/dist/index.js"]
}
}
}Skill Discovery:
The server auto-aggregates skills from multiple directories (priority: low to high):
Package built-in skills (self-documenting guides)
~/.claude/skills/- Global skills./.claude/skills/- Project-specific (hidden)./skills- Project-specific (visible)$SKILLS_DIR- Custom path (if env var set)
Later directories override earlier ones, letting you customize built-in skills.
3. Create & Use Skills
Create Skills (Option 1: Ask AI - Recommended)
Simply ask your AI to create skills:
"Create a Python expert skill for clean, idiomatic code"
"Make a PR review skill focusing on security and best practices"The AI uses the built-in skill-creator skill to generate well-structured skills with proper YAML frontmatter and trigger keywords.
Create Skills (Option 2: Manual)
Create ~/.claude/skills/my-skill/SKILL.md:
---
name: my-skill
description: What this skill does and when to use it
---
You are an expert at [domain]. Your task is to [specific task].
Guidelines:
1. Be specific and actionable
2. Provide examples
3. Include best practicesUse Skills
Request any skill: "Use the my-skill skill"
Skills are auto-discovered and load on-demand. All changes apply instantly with hot reloadβno restart needed!
π SKILL.md Format
Every skill is a SKILL.md file with YAML frontmatter:
---
name: skill-name
description: Brief description of what this skill does and when to use it
---
Your skill instructions in Markdown format...Required Fields:
name- Skill identifier (lowercase, hyphens, max 64 chars)description- Critical for skill selection (max 200 chars)
Writing Effective Descriptions:
Use pattern: [What it does]. Use when [trigger conditions/keywords].
β Good Examples:
"Generates clear commit messages from git diffs. Use when writing commit messages or reviewing staged changes."
"Analyzes Excel spreadsheets and creates pivot tables. Use when working with .xlsx files or tabular data."
β Poor Example:
"Helps with Excel files"
Specific trigger keywords help the AI make better decisions when selecting skills.
π― Usage
How It Works:
AI sees all available skill names/descriptions (auto-updated, ~50 tokens each)
When you request a skill, AI invokes the
get_skilltoolFull skill content loads on-demand with detailed instructions
Built-in Skills:
Three self-documenting skills are included:
local-skills-mcp-usage- Quick usage guidelocal-skills-mcp-guide- Comprehensive documentationskill-creator- Skill authoring best practices
Skill Directories:
Auto-aggregates from multiple locations (later ones override earlier):
Package built-in skills
~/.claude/skills/- Global skills./.claude/skills/- Project-specific (hidden)./skills- Project-specific (visible)$SKILLS_DIR- Custom path (optional)
Custom Directory:
Configure via environment variable in your MCP client config:
{
"mcpServers": {
"local-skills": {
"command": "local-skills-mcp",
"env": {
"SKILLS_DIR": "/custom/path/to/skills"
}
}
}
}Example Skill:
---
name: code-reviewer
description: Reviews code for best practices, bugs, and security. Use when reviewing PRs or analyzing code quality.
---
You are a code reviewer with expertise in software engineering best practices.
Analyze the code for:
1. Correctness and bugs
2. Best practices and maintainability
3. Performance and security issues
Provide specific, actionable feedback with examples.β FAQ
More: See CONTRIBUTING.md, SECURITY.md, CHANGELOG.md
π€ Contributing
Contributions welcome! See CONTRIBUTING.md for detailed guidelines.
Quick start:
Fork and clone the repository
Create your feature branch (
git checkout -b feature/amazing-feature)Make changes and add tests
Commit (
git commit -m 'Add amazing feature')Push (
git push origin feature/amazing-feature)Open a Pull Request
This project follows a Code of Conduct.
π Complementary Projects
Optimize your MCP setup with these complementary tools:
MCP Compression Proxy
Aggregate and compress tool descriptions from multiple MCP servers
While Local Skills MCP provides expert prompt instructions, MCP Compression Proxy optimizes your tool descriptions with intelligent LLM-based compression.
Perfect combination:
Local Skills MCP - Expert skills with lazy loading (~50 tokens/skill)
MCP Compression Proxy - Compressed tool descriptions (50-80% token reduction)
Together they enable:
π― Maximum context efficiency across skills AND tools
π Access to multiple MCP servers through one connection
β‘ Minimal token consumption for large-scale workflows
π Professional AI agent setups with hundreds of tools
Learn more about MCP Compression Proxy β
π Support This Project
If you find Local Skills MCP useful, please consider supporting its development!
Ways to support:
π° Sponsor via the badges above
π License
MIT License - see LICENSE file. Copyright Β© 2025 KDPA
π Acknowledgments
Built with Model Context Protocol SDK β’ Inspired by Claude Skills
Made with β€οΈ by KDPA
Available Tools
3 toolsevaluate_skillA
Runs Anthropic skill-creator eval loop for a skill (requires Python, Claude CLI auth, and an eval set JSON; legacy layouts may also require ANTHROPIC_API_KEY + anthropic package).
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional model passed to Claude CLI (defaults to "sonnet") | |
| holdout | No | Optional holdout fraction for run_loop test split (defaults to 0.4, use 0 to disable holdout) | |
| skill_name | Yes | The skill directory name to evaluate | |
| num_workers | No | Optional evaluator parallel workers (defaults to 1 for stable trigger measurements) | |
| eval_set_path | No | Optional path to eval set JSON. If omitted, common default locations are checked. | |
| max_iterations | No | Optional max optimization iterations | |
| runs_per_query | No | Optional repeats per query (defaults to 1; increase for variance analysis) | |
| timeout_seconds | No | Optional timeout per query in seconds (defaults to 120) | |
| trigger_threshold | No | Optional trigger-rate threshold for pass/fail decisions (defaults to 0.5) | |
| description_override | No | Optional starting description override for what-if optimization without editing SKILL.md first |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It mentions prerequisites and legacy requirements, but does not disclose side effects, performance impact, or whether the tool modifies any files. This is a moderate disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence with a parenthetical, efficiently conveying the primary action and key requirements. Slightly dense, but no superfluous content; could be restructured for better readability.
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?
With 10 parameters (all optional except one), no output schema, and no annotations, the description provides essential prerequisites but lacks details on output behavior and eval loop outcomes. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter already has a description. The tool description adds prerequisite context but does not enhance understanding of individual parameters beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Runs Anthropic skill-creator eval loop for a skill', specifying the exact action and target resource. This distinguishes it from sibling tools get_skill and validate_skill, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description lists prerequisites (Python, Claude CLI auth, eval set JSON) which guide usage. It implies usage for evaluation, though lacks explicit when-to-use vs siblings or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_skillA
Loads specialized expert prompt instructions that transform your capabilities for specific tasks. Each skill provides comprehensive guidance, proven methodologies, and domain-specific best practices. Use when you need focused expertise, systematic approaches, or professional standards for any task that would benefit from specialized knowledge. Invoke with the skill name to receive detailed instructions that enhance your problem-solving approach with structured, expert-level guidance.
Available skills:
local-skills-mcp-guide: Repository implementation guide for the local-skills-mcp codebase. Use when asked: how src/index.ts and src/skill-loader.ts work together; where MCP tool handlers are defined and registered; how getAllSkillsDirectories priority and override behavior works; how local-skills-mcp discovers skills and merges metadata across directories; where validate_skill and evaluate_skill are implemented in this repository; or how integration tests are structured in this local-skills-mcp project.
local-skills-mcp-usage: Operational guide for using Local Skills MCP in day-to-day projects. Use when asked: where skills should live (~/.claude/skills, ./.claude/skills, ./skills, SKILLS_DIR); directory precedence and override rules; how to configure local-skills-mcp in Claude Code mcp.json; fastest way to create a new skill folder and make it discoverable; how to add project skills to git so the team gets them; or how Local Skills MCP hot-reloads skill edits without restarting.
skill-creator: Use this skill when building, writing, reviewing, or fixing a SKILL.md file for a new or existing skill. Covers choosing skill names, writing and correcting YAML frontmatter (name and description fields), crafting effective 'Use when' trigger phrases, structuring skill body instructions, improving an existing skill's routing quality with better trigger keywords, and interpreting or evaluating a skill description against an eval set using validate_skill or evaluate_skill.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_name | Yes | The name of the skill to retrieve (e.g., "code-reviewer", "test-generator") |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read operation loading instructions but does not disclose behavioral traits such as idempotency, permission requirements, or potential side effects.
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 structured with a general purpose paragraph followed by a list of specific skills. It is front-loaded with the main action but slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and one parameter, the description adequately covers what the tool returns (detailed instructions) and how to call it, including examples. Lacks info on error cases but sufficient for a simple retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single string parameter described. The description adds value by listing available skill names, going beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it loads specialized expert prompt instructions and transforms capabilities for specific tasks, distinguishing it from siblings evaluate_skill and validate_skill which assess skills.
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?
Provides explicit when-to-use guidance ('when you need focused expertise') and lists specific skill examples, but does not explicitly state when not to use or contrast with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_skillB
Validates a SKILL.md file against name/description/frontmatter rules and returns errors + warnings.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_name | Yes | The skill directory name to validate |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It does not disclose whether the tool is read-only or has side effects, what happens if the file is missing, or any required permissions. The description only states it validates and returns errors/warnings, lacking critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and to the point. It contains no unnecessary words or filler, and every part of the sentence adds value.
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 simple tool with one parameter and no output schema, the description is fairly complete. It explains the function and the type of output (errors/warnings). However, it could mention whether the file must exist or what rules are checked, but these are minor omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'skill_name' has 100% schema coverage, and its description in the schema matches the tool description. The tool description adds no additional meaning beyond what the schema already provides. Baseline 3 applies since schema coverage is high.
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?
Description clearly states the tool validates a SKILL.md file against specific rules and returns errors/warnings. The verb 'validates' and resource 'SKILL.md' are precise, and the output ('errors + warnings') is specified. It distinguishes from siblings like 'evaluate_skill' and 'get_skill' by focusing on validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like evaluate_skill or get_skill. There is no mention of prerequisites, context, or when not to use it. The description only states what it does, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.4.4- First observed
evaluate_skill - First observed
get_skill - First observed
validate_skill
TDQS
Scored across 3 tools
Each tool has a distinct purpose: validate_skill validates SKILL.md files, get_skill loads skill instructions, evaluate_skill runs an evaluation loop. No overlap.
All tool names follow a consistent verb_noun pattern (evaluate_skill, get_skill, validate_skill), making the API predictable.
Three tools is slightly minimal for a skill management system, but covers core operations. A few more (e.g., create_skill, list_skills) could improve completeness without being excessive.
Missing basic lifecycle operations: no tool to create, update, or delete skills. The get_skill tool lists available skills but this is atypical. Validation and evaluation alone are insufficient for managing a skill inventory.
Maintenance
Related MCP Connectors
- UnifAPIOAuthcom.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Nifty's MCP server β exposes tasks, projects, messages, and files as tools for AI agents.
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
MCP server for AI dialogue using various LLM models via AceDataCloud
Related MCP Servers
- AlicenseBqualityDmaintenanceProduction-grade MCP server that gives AI agents safe access to your local dev environment: filesystem, databases, processes, and OpenAPI specs.1528 npm3MIT
- AlicenseNot gradedqualityFmaintenanceAn MCP server that makes superpowers skills available to any LLM that supports the Model Context Protocol.1,234 npm17MIT
- AlicenseNot gradedqualityBmaintenanceA self-hostable MCP server that turns a folder of skills into callable tools via MCP and REST APIs.2MIT
- AlicenseNot gradedqualityBmaintenanceA complete MCP server that gives LM Studio's Qwen3 (or any local LLM) full coding agent capabilities including 80+ tools for file operations, command execution, git, web search, memory, planning, and a full skills system.13MIT