Skip to main content
Glama
deenesjakoruzh
Guslaier

MCP-skill-library-dynamic

by Guslaier
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

MCP-skill-library-dynamic 🚀

一个企业级的 MCP（Model Context Protocol）服务器，可按需从本地目录向 AI 代理提供技能和规则文件。它允许 AI 代理动态列出并获取以 Markdown 格式编写的特定技能指令，而不会遭受上下文膨胀（Context Bloat）的问题。

✨ 功能特性（v1.2.0）

  • 原生 TypeScript：100% 类型安全，编译为优化的 ES Modules。

  • 精选 200+ 核心技能库：高质量、去重且符合社区标准的技能集，已预先索引在 skills-base.json 中。

  • 确定性离线优先下载器：使用 npx skills add 直接从精选基础列表中快速、可靠地批量下载，并带有指数退避重试机制。

  • 智能搜索与过滤：list_skills 支持可选的 query 参数（例如 list_skills({ query: "react" })）来直接过滤技能并节省 token。

  • 递归多文件规则聚合：fetch_skill_rule 自动扫描并合并所有嵌套的 Markdown 文件（例如 rules/*.md、references/*.md），不会跳过更深层的文档。

  • 零配置自动路径解析：智能地相对于编译后的服务器位置解析 .agents/skills，消除了手动设置 SKILLS_DIR 的问题。

  • 幽灵技能消除：自动忽略空目录，仅提供包含已验证 .md 规则文件的文件夹。

  • 内存安全缓存：利用 TTL 缓存进行目录列表，并使用异步 I/O 进行文件读取，即使有 100,000+ 个技能，也能保证 0% 的内存溢出（OOM）崩溃几率。

  • 路径遍历防护：采用加密级路径解析，将 AI 严格限制在 .agents/skills/ 目录的沙箱中。

  • 优雅关闭：正确处理 SIGINT/SIGTERM 和未捕获的异常，确保 MCP 套接字干净关闭。

  • Token 精简架构（节省成本）：

    • list_skills 仅返回原始文件夹名称（slugs），即使有 1,000+ 个技能，也能将注入的上下文最小化到仅约 ~1,500 个 token。

    • fetch_skill_rule 严格按需获取内容，一次只获取一个技能，防止 AI 幻觉和巨额 API 费用。

Related MCP server: docubridge

📦 安装与构建

  1. 克隆或下载仓库：

git clone https://github.com/Guslaier/MCP-skill-library-dynamic.git
cd skill-library-mcp

  1. 安装依赖：

npm install

  1. 编译 TypeScript 源代码：

npm run build

🧠 下载与管理技能

技能被加载到项目根目录下的 .agents/skills/ 中（或通过 SKILLS_DIR 配置）。

精选基础技能（skills-base.json）

下载器使用 skills-base.json 作为唯一事实来源，其中包含来自官方和顶级仓库（anthropics/skills、obra/superpowers、affaan-m/ecc、browser-use 等）的 200+ 个精选且去重的技能。

CLI 命令

命令

描述

npm run download

下载并安装所有 200+ 基础技能

npm run download -- <skill-name>

仅下载与给定名称筛选条件匹配的技能

示例

# Download all 200+ curated base skills
npm run download

# Download only specific skills matching 'caveman'
npm run download -- caveman

# Download all React / Frontend related skills
npm run download -- react

📁 目录结构

skill-library-mcp/
├── package.json
├── tsconfig.json
├── skills-base.json        # Curated index of 200+ skills (name, repo url, description)
├── src/
│   ├── index.ts            # MCP Server entry point
│   └── download-skills.ts  # Batch downloader from skills-base.json
├── dist/
│   ├── index.js
│   └── download-skills.js
└── .agents/
    └── skills/             # Local skill files served to AI agents
        ├── code-review/
        │   └── SKILL.md
        ├── test-driven-development/
        │   └── SKILL.md
        └── ...

🚀 运行服务器

使用以下命令启动服务器：

npm start

⚙️ MCP 配置

要将此服务器与 MCP 客户端（如 Antigravity、Cursor、Roo Code 或 Cline）连接，请将以下配置添加到客户端的设置文件中：

{
  "mcpServers": {
    "skill-library": {
      "command": "node",
      "args": [
        "C:/path/to/skill-library-mcp/dist/index.js"
      ],
      "env": {
        "SKILLS_DIR": "C:/path/to/skill-library-mcp/.agents/skills"
      }
    }
  }
}

重要提示： 将 C:/path/to/skill-library-mcp 替换为你的实际仓库路径，指向 dist/index.js。

🤖 系统提示词（知识库协议）

将以下提示词添加到你的 AI 代理规则（.clinerules、.cursorrules 或自定义指令）中，以便代理自动使用技能库：

# UNIVERSAL KNOWLEDGE BASE PROTOCOL
You are equipped with the Enterprise "Skill Library MCP". Before starting any architectural planning, refactoring, or feature implementation, you MUST:
1. Use `list_skills` (or `list_skills({ query: "keyword" })`) to check for relevant domain rules or coding standards.
2. If found, use `fetch_skill_rule({ skill_name: "..." })` to read the full context and nested rule guidelines.
3. Explicitly acknowledge the rules and apply them strictly to your code generation.

📜 许可证

MIT

Available Tools

2 tools
fetch_skill_ruleA
Read-onlyIdempotent

Fetch the full markdown content and nested rule guidelines of a specific skill.

NameRequiredDescriptionDefault
skill_nameYesExact name of the skill folder (e.g., 'nestjs-best-practices')

Output Schema

NameRequiredDescription
filesNo
contentNo
skill_nameNo

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by specifying exactly what is returned (full markdown content and nested rule guidelines), which is beyond the annotations. It does not claim any side effects, and the read-only nature is consistent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence of 12 words. It is front-loaded with the verb and clearly states the output. No unnecessary words or repetition; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool, the description is quite complete given the presence of an output schema (which presumably explains the return format) and annotations covering safety. It does not mention error behavior (e.g., missing skill), but that is likely handled by the output schema. Overall, adequate for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema provides a clear description for skill_name. The tool description does not add any additional meaning to the parameter, so it relies on the schema. Baseline 3 is appropriate when the schema already documents the parameter fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific verb 'Fetch' and the resource (full markdown content and nested rule guidelines of a skill). It distinguishes this from list_skills, which likely only provides an overview. The purpose is unambiguous and distinct from its sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage context is implied by the description and the presence of list_skills as a sibling, but it does not explicitly state when to use this tool versus list_skills. No exclusions or alternative conditions are mentioned, so guidance is only implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_skillsA
Read-onlyIdempotent

List all available skills/rules in the knowledge base. Supports optional search query for token efficiency.

NameRequiredDescriptionDefault
queryNoOptional keyword to filter skills (e.g., 'react', 'python', 'review')

Output Schema

NameRequiredDescription
countNo
skillsNo

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds the behavioral context that it returns the full list unless filtered, plus the token-efficiency rationale. This supplements the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence packs the core purpose and the optional usage hint with zero redundancy or filler. The most important information is front-loaded, and every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple nature of the tool, the presence of an output schema, and comprehensive annotations, the description covers the essential aspects. It does not explicitly address when to use fetch_skill_rule, but that is a minor omission for a list operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single optional 'query' parameter, so the description's addition of 'token efficiency' provides extra semantic value beyond the schema, explaining why one would use the filter. This meaningfully enhances the parameter's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all available skills/rules in the knowledge base, using a specific verb ('List') and resource. It distinguishes from sibling fetch_skill_rule by semantic contrast (list vs fetch), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions an optional search query for token efficiency, which hints at usage for large lists, but does not explicitly contrast with fetch_skill_rule or state when to use one over the other. The guidance is implied rather than explicit.

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.

  1. 2 tool updatesv1.0.0
    • First observedfetch_skill_rule
    • First observedlist_skills
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.2/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: one lists available skills, the other fetches a specific skill's content. There is no overlap or ambiguity between them.

Naming Consistency5/5

Both tools follow the same verb_noun pattern (list_skills, fetch_skill_rule), making the naming predictable and consistent.

Tool Count3/5

With only 2 tools, the set is on the thin side, but it fits the narrow scope of a read-only skill library. It feels borderline rather than clearly inadequate.

Completeness4/5

For a read-only knowledge base, list and fetch cover the essential operations. The search option on list_skills adds flexibility. Minor gaps like versioning or metadata retrieval are not critical.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers