Agent Skill Loaderは、静的なClaude Codeスキルライブラリと動的なAIエージェント（Claude Desktop、Cursor、またはその他のMCPクライアント）の橋渡しをするModel Context Protocol (MCP) サーバーです。
スキルを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/ 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 |
|---|---|---|---|
| operation | Yes | Operation to perform | |
| path | No | Absolute path to add or remove (not required for 'list') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint: true, but the description describes write operations (add, remove). This is a clear contradiction. The description does not address other behavioral traits like error handling or authorization needs.
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 concise with two sentences, front-loading the purpose and adding key behavioral context (no restart, persistence). Every sentence adds value without redundancy.
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 (2 parameters, no output schema), the description covers the main actions and persistence behavior. However, the annotation contradiction weakens overall completeness, as the agent cannot trust the safety profile.
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% description coverage for both parameters. The tool description adds context about persistence and no restart needed, but does not add new parameter-level semantics beyond what the schema provides. Baseline score of 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?
The description clearly states the tool's purpose: adding, removing, or listing dynamic skill search paths. It specifies the resource (dynamic skill search paths) and the verbs (add, remove, list). This distinguishes it from sibling tools like install_skill and read_skill, which handle different resources.
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 implies usage for runtime modifications without restarting the server, but does not explicitly state when to use this tool versus alternatives. However, since no sibling tool performs the same operation, the implicit guidance is sufficient.
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. Dates show when Glama detected each change.
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_skillEach tool has a clearly distinct purpose: debugging, installation, listing, path management, and reading skills. No overlapping functionality.
All tools follow a consistent verb_noun snake_case pattern (e.g., debug_info, install_skill), making them predictable and easy to understand.
With only 5 tools, the server is well-scoped for its purpose of managing skills. Each tool serves a necessary function without redundancy.
Core operations are covered (install, list, read, debug, manage paths), but a missing uninstall/remove skill tool is a minor gap that may require manual intervention.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/back1ply/agent-skill-loader'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
