Agent Skill Loader는 정적 Claude Code 스킬 라이브러리와 동적 AI 에이전트(Claude Desktop, Cursor 또는 기타 MCP 클라이언트) 사이의 가교 역할을 하는 MCP(Model Context Protocol) 서버입니다.
이 서버는 스킬을 MCP 프롬프트(슬래시 명령, 도구 호출 불필요)와 MCP 도구(프로그래밍 방식 사용)로 모두 노출합니다. 스킬은 구성된 디렉토리에서 자동으로 검색되며 실시간으로 유지됩니다. 새로운 SKILL.md를 추가하면 클라이언트에 자동으로 알림이 전송됩니다.
MCP 프롬프트: 스킬이 클라이언트에서 슬래시 명령으로 나타납니다. 주입을 위해 도구를 호출할 필요가 없습니다.
실시간 업데이트: 스킬이 추가되거나 제거되면(파일 감시자를 통해) listChanged 알림이 발생합니다.
검색: list_skills — 구성된 스킬 디렉토리를 스캔하며, 선택적으로 검색 필터를 사용할 수 있습니다.
동적 학습: read_skill — SKILL.md 콘텐츠를 가져옵니다.
영구 저장: install_skill — 스킬을 프로젝트에 영구적으로 복사합니다.
구성: manage_search_paths — 런타임에 스킬 디렉토리를 추가/제거합니다.
문제 해결: debug_info — 구성 및 경로 문제를 진단합니다.
Related MCP server: llama-mcp-server
Node.js >= 18
npm install -g agent-skill-loader그런 다음 .mcp.json에 등록합니다:
"agent-skill-loader": {
"command": "agent-skill-loader"
}git clone https://github.com/back1ply/agent-skill-loader.git
cd agent-skill-loader
npm install
npm run build그런 다음 .mcp.json에 등록합니다:
"agent-skill-loader": {
"command": "node",
"args": ["<path-to-repo>/build/index.js"]
}서버는 작업 공간을 자동으로 감지하고 다음 위치에서 스킬 경로를 집계합니다:
기본값: %USERPROFILE%\.claude\plugins\cache (표준 위치)
동적 구성: skill-paths.json (프로젝트 루트에 위치)
변수 | 설명 |
| 추가 스킬 경로의 JSON 배열 또는 세미콜론/쉼표로 구분된 목록 |
| 자동 감지된 작업 공간 루트 재정의 |
| 파일 감시자를 비활성화하려면 |
구성 파일을 수동으로 편집할 필요가 없습니다. 도구를 사용하여 런타임에 경로를 관리하세요:
추가: manage_search_paths(operation="add", path="F:\\My\\Deep\\Skills")
제거: manage_search_paths(operation="remove", path="...")
목록: manage_search_paths(operation="list")는 skill-paths.json을 생성/업데이트합니다.
클라이언트가 MCP 프롬프트를 지원하는 경우(Claude Desktop, Cursor 등), 스킬이 슬래시 명령으로 자동 나타납니다. 슬래시 명령 메뉴에서 스킬을 선택하여 콘텐츠를 직접 주입하세요. 도구 호출이 필요하지 않습니다.
에이전트는 다음 5가지 도구에 액세스할 수 있습니다:
list_skills(query?): 사용 가능한 스킬의 JSON 목록을 반환합니다. 선택적 query는 이름/설명 하위 문자열로 필터링합니다(대소문자 구분 안 함).
read_skill(skill_name): 스킬에 대한 마크다운 지침을 반환합니다.
install_skill(skill_name, target_path?): 스킬 폴더를 .agent/skills/<name>으로 복사합니다. 보안을 위해 target_path는 현재 작업 공간 내에 있어야 합니다.
manage_search_paths(operation, path?): 스킬 검색 경로를 추가, 제거 또는 나열합니다.
debug_info(): 진단 정보(경로, 상태, 경고)를 반환합니다.
"DAX 측정값을 작성해야 하는데 모범 사례를 잘 모르겠어."
에이전트가 자동으로 list_skills를 호출하고 writing-dax-measures를 찾아 read_skill을 호출한 다음 전문가 지식으로 답변합니다. 또는 사용자가 슬래시 명령으로 직접 스킬을 호출할 수도 있습니다.
스킬이 검색되지 않으면 debug_info()를 사용하여 다음을 확인하세요:
search_paths: 스캔 중인 디렉토리
path_status: 각 경로의 존재 여부 및 읽기 가능 여부
warnings: 스캔 중 발생한 오류(권한 거부, 빈 파일 등)
출력 예시:
{
"workspace_root": "C:/projects/agent-skill-loader",
"search_paths": {
"base": ["C:/Users/pc/.claude/plugins/cache"],
"dynamic": ["F:/My/Skills"],
"effective": ["C:/Users/pc/.claude/plugins/cache", "F:/My/Skills"]
},
"path_status": [
{ "path": "C:/Users/pc/.claude/plugins/cache", "exists": true, "readable": true },
{ "path": "F:/My/Skills", "exists": false, "readable": false }
],
"skills_found": 12,
"warnings": [
{ "path": "F:/My/Skills", "reason": "Directory does not exist" }
]
}src/index.ts: 메인 서버 로직 (도구 + 프롬프트 + 감시자).
src/utils.ts: 스킬 스캔, 설명 추출, 프롬프트 도우미, 디바운스.
build/: 컴파일된 JavaScript 출력.
package.json: 종속성 (@modelcontextprotocol/sdk, chokidar, zod).
새로운 스킬을 추가하려면 감시 중인 디렉토리 중 하나에 SKILL.md 파일이 포함된 폴더를 추가하세요. 서버가 자동으로 이를 감지하고 listChanged 알림을 보냅니다. 재시작은 필요하지 않습니다.
Returns diagnostic information about server configuration, search paths, and any warnings from the last scan. Use this when skills aren't being found or to verify configuration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds details on the content of the diagnostic info, consistent with a read-only operation. No contradictions.
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?
Two sentences, front-loaded with the tool's function and followed by usage context. No unnecessary words.
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 no parameters and no output schema, the description adequately covers what the tool returns and when to use it.
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?
Input schema has zero parameters, so schema coverage is 100%. Baseline of 4 is appropriate since no param explanation needed.
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 returns diagnostic information about server configuration, search paths, and warnings, using a specific verb and resource. It distinguishes from sibling tools (which deal with skills) by being diagnostic.
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?
Explicitly says to use it when skills aren't found or to verify configuration. Provides clear context, though it doesn't mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copies an entire skill directory (including SKILL.md and any supporting files) to the target workspace. By default, installs to .agent/skills/<skill_name> in the current working directory.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_name | Yes | Name of the skill to install | |
| target_path | No | Destination path within current workspace. Defaults to .agent/skills/<skill_name>. Must be within the current working directory for security. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set destructiveHint=true, and the description reinforces this with 'Copies... to target workspace' and adds details about path constraints (must be within current working directory). No contradictions.
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?
Two sentences, front-loaded with key action, no wasted words.
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?
Explains main action, default path, and security constraint. Lacks information about return values or overwrite behavior, but is sufficient for a copy/install tool with no output schema.
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?
Input schema covers both parameters with full descriptions. The description adds minimal extra value beyond the schema, only reiterating default behavior and workspace security.
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 action 'Copies an entire skill directory' and specifies the target workspace. It distinguishes from siblings like list_skills and read_skill by focusing on installation.
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 explains default behavior and security constraints, but does not explicitly state when not to use or suggest alternatives like list_skills or read_skill for non-destructive tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a JSON list of all available skills with their names, descriptions, and source directories. Use this to discover what skills are available before reading or installing them.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional filter: return only skills whose name or description contains this substring (case-insensitive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true; description reinforces readonly nature and adds detail about return fields (names, descriptions, source directories) without contradiction.
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?
Two concise, front-loaded sentences with zero wasted words; purpose and usage guidance are efficiently communicated.
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 simplicity of tool, no output schema, description adequately explains return content (names, descriptions, source directories) and optional filtering, making it complete.
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% and description does not add meaning beyond the schema's parameter description; baseline of 3 applies.
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?
Clearly states tool returns a JSON list of all available skills with detailed fields, and distinguishes from sibling tools by mentioning its role before reading or installing.
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?
Explicitly advises usage for discovery before reading or installing skills, providing clear context of when to use; could be improved by also stating when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add, remove, or list dynamic skill search paths without restarting the server. Persists to skill-paths.json in the workspace root.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Absolute path to add or remove (not required for 'list') | |
| operation | Yes | Operation to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (destructiveHint=true, readOnlyHint=false, idempotentHint=true), so the description's burden is lighter. It still adds meaningful behavior beyond the annotations by disclosing the persistence file (skill-paths.json in the workspace root) and the no-restart property, which tells the agent changes are durable and immediately effective.
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?
Two tight sentences with zero filler; the operation set and the persistence side effect are both stated up front with nothing redundant.
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 small two-parameter, no-output-schema tool with annotations covering safety, the definition is nearly complete: it covers operations, persistence location, and the restart-free behavior. Minor gaps remain around error cases (invalid path, duplicates) and whether removal affects already-loaded skills.
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 both parameters are already documented in the schema, including the note that path is unneeded for 'list'. The description adds no further syntax, format, or validation detail (e.g., whether the path must already exist), so it sits at the baseline for schema-covered parameters.
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 names specific verbs (add, remove, list) and a precise resource (dynamic skill search paths), so the agent knows exactly what class of operation this is. It implicitly separates itself from the skill-content siblings (install_skill, read_skill) by scoping to search-path configuration, though it never names a sibling explicitly.
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?
There is no guidance on when to reach for this tool versus install_skill or list_skills, nor any exclusion criteria or prerequisites. The operation enum implies the three modes but the description never states a use case that would select this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches and returns the full SKILL.md content for a specific skill. The content includes instructions and context that can be used to learn the skill's capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_name | Yes | The name of the skill to read (e.g., 'writing-dax-measures') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds context about the content structure ('instructions and context'), but does not disclose other behavioral traits like error handling or limitations. No contradiction with annotations.
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 two sentences long, front-loaded with the primary purpose, and contains no extraneous information. Every 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?
Given the tool's simplicity (single parameter, read-only), the description adequately explains the return value ('full SKILL.md content' with instructions and context). However, it omits details about potential errors or output format, but for a read tool this is sufficient.
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 covers 100% of parameters and provides a clear description for 'skill_name.' The description does not add additional meaning beyond the schema, so baseline score of 3 applies.
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 explicitly states 'Fetches and returns the full SKILL.md content for a specific skill,' which clearly defines the action (fetch) and resource (SKILL.md content). It is distinct from siblings like list_skills (lists skill names) and install_skill (installs).
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?
While the description implies usage when needing full content of a skill, it does not explicitly state when to use it versus alternatives (e.g., when not to use, prerequisites). Guidance is inferred but not directly provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0list_skills2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / queryAdded value: +{
+ "description": "Optional filter: return only skills whose name or description contains this substring (case-insensitive)",
+ "type": "string"
+}debug_infoinstall_skilllist_skillsmanage_search_pathsread_skillScored across 5 tools
Each tool has a clearly distinct purpose: manage_search_paths handles configuration, debug_info provides diagnostics, install_skill copies directories, list_skills enumerates available skills, and read_skill retrieves content. There is no meaningful overlap between them.
All tool names use snake_case with a consistent verb_noun structure (manage_search_paths, debug_info, install_skill, list_skills, read_skill). The pattern is predictable and easy to parse.
Five tools is well-scoped for a skill loader: discovery, reading, installation, path management, and debugging. Each tool earns its place without redundancy.
The core lifecycle of discovering, reading, and installing skills is covered, plus configuration and diagnostics. However, there is no tool to uninstall or remove an installed skill or update an existing one, which are minor gaps.
MCP server for AI dialogue using various LLM models via AceDataCloud
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Cloud-hosted MCP server for durable AI memory
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
