Skip to main content
Glama
deenesjakoruzh
Guslaier

MCP-skill-library-dynamic

by Guslaier
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

MCP-skill-library-dynamic 🚀

로컬 디렉토리의 스킬 및 규칙 파일을 AI 에이전트에게 온디맨드로 제공하는 엔터프라이즈급 MCP(Model Context Protocol) 서버입니다. AI 에이전트가 Context Bloat(컨텍스트 비대화) 없이 Markdown으로 작성된 특정 스킬 지침을 동적으로 나열하고 가져올 수 있게 해줍니다.

✨ 주요 기능 (v1.2.0)

  • TypeScript 네이티브: 100% 타입 안전, 최적화된 ES Modules로 컴파일됩니다.

  • 큐레이션된 200+ 핵심 스킬 베이스: skills-base.json에 사전 인덱싱된 고품질, 중복 제거, 커뮤니티 표준 스킬 세트입니다.

  • 결정적 오프라인 우선 다운로더: 지수 백오프 재시도를 사용하는 npx skills add를 통해 큐레이션된 기본 목록에서 빠르고 안정적인 일괄 다운로드를 제공합니다.

  • 스마트 검색 및 필터: list_skills는 선택적 query 매개변수(예: list_skills({ query: "react" }))를 지원하여 스킬을 직접 필터링하고 토큰을 절약합니다.

  • 재귀적 다중 파일 규칙 집계: fetch_skill_rule은 중첩된 모든 Markdown 파일(예: rules/*.md, references/*.md)을 자동으로 스캔하고 결합하여 더 깊은 문서를 건너뛰지 않습니다.

  • 제로 구성 자동 경로 해석: 컴파일된 서버 위치를 기준으로 .agents/skills를 지능적으로 해석하여 수동 SKILLS_DIR 설정 문제를 제거합니다.

  • 고스트 스킬 제거: 빈 디렉토리를 자동으로 무시하고 검증된 .md 규칙 파일이 있는 폴더만 제공합니다.

  • 메모리 안전 캐싱: 디렉토리 목록에 TTL 캐시를 사용하고 파일 읽기에 비동기 I/O를 사용하여 100,000개 이상의 스킬이 있어도 OOM(메모리 부족) 크래시 가능성을 0%로 보장합니다.

  • 경로 탐색 보호: 암호화급 경로 해석으로 AI를 .agents/skills/ 디렉토리에 엄격하게 샌드박싱합니다.

  • 우아한 종료: SIGINT/SIGTERM 및 처리되지 않은 예외를 적절히 처리하여 MCP 소켓을 깨끗하게 닫습니다.

  • 토큰 다이어트 아키텍처(비용 절감):

    • list_skills는 원시 폴더 이름(슬러그)만 반환하여 1,000개 이상의 스킬이 있어도 주입되는 컨텍스트를 약 1,500 토큰으로 최소화합니다.

    • 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

🧠 스킬 다운로드 및 관리

스킬은 프로젝트 루트(또는 SKILLS_DIR로 구성된 위치)에 있는 .agents/skills/에 로드됩니다.

큐레이션된 기본 스킬(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