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., "@skill-composer-mcp compare 'code-review' and 'test-gen' 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.
一个本地运行的 AI 技能组合器。它能读取、分析、对比和组合多个 SKILL.md 技能文件，让不同的 AI 技能像乐高积木一样拼接使用。
核心原则：所有原始技能文件只读不写，永不污染源文件。
Related MCP server: mcp-skills
工具 | 一句话说明 |
| 首次使用配置技能目录 |
| 列出/搜索所有技能 |
| 六维分析（速度/准确度/鲁棒性/输出质量/提示策略/工具使用）+ 逆向工程 |
| 两个技能差异对比 + 六维雷达图 |
| 组合技能（diff/temp/persist/dry-run） |
| AI 自动推荐最佳组合方案 |
| 模板管理 |
| 搜索模式库（成功率/分类/标签） |
| 进化分析（六维差异 + 路线图） |
| 逐维度渐进注入，一步一确认 |
| 注入步骤决策 |
| 手动热加载配置 |
每个技能从 6 个维度打分（0-10），生成雷达图：
speed ─ 执行效率与性能
accuracy ─ 校验与精确度
robustness ─ 错误处理与容错
output_quality ─ 输出结构化与可读性
prompt_strategy─ 提示词设计策略
tool_usage ─ 工具调用与编排从技能中自动提取可复用设计模式，持久化到 ~/.composed_skills/pattern-library.json，追踪每次使用的成功/失败和生命周期。
git clone https://github.com/K-Host/skill-composer-mcp.git
cd skill-composer-mcp
uv sync在 opencode.json 或 MCP 客户端配置文件中添加：
{
"mcp": {
"skill-composer": {
"type": "local",
"command": ["uv", "run", "python", "-m", "skill_composer_mcp"],
"enabled": true
}
}
}启动后调用 configure_skills 告诉工具去哪找你的技能文件：
configure_skills(skill_paths=[
"~/.config/opencode/skills",
"./skills"
])配置完成后直接说：
"列出所有技能"
"分析一下 xxx 技能"
"对比 A 和 B"
"把 A 和 B 组合起来"
本项目六维评估框架、模式库提取、渐进式注入等核心技术受 Taotie Skill 启发。Taotie 是一套开源的技能进化框架，提供了技能质量评估、模式复用和持续优化的完整方法论，推荐参考。
├── 介绍.md ← 本文档
├── opencode.json ← MCP 客户端配置
├── pyproject.toml ← 项目依赖
├── src/
│ └── skill_composer_mcp/
│ ├── server.py # MCP 协议层（13 个工具）
│ ├── config.py # 配置 + 热加载
│ ├── models.py # 数据模型
│ └── core/
│ ├── skill_loader.py # 技能扫描
│ ├── skill_parser.py # 技能解析
│ ├── skill_analyzer.py # 六维分析 + 逆向工程
│ ├── skill_composer.py # 组合引擎 + 渐进注入
│ ├── pattern_library.py # 持久化模式库
│ ├── security_guard.py # 安全沙箱
│ ├── template_manager.py # 模板管理
│ └── llm_factory.py # LLM 封装
├── skills/ ← 自定义技能目录
└── examples/ ← 示例技能逆向进化分析：对比两个技能的六维评分差异，生成逐步进化路线图。自动从源技能提取模式存入模式库。
| Name | Required | Description | Default |
|---|---|---|---|
| base_skill | Yes | 当前技能名称 | |
| source_skill | Yes | 目标进化技能名称 | |
| include_pattern_extraction | No | 是否自动提取模式入库（默认 true） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing full burden on the description. It mentions automatic pattern extraction and storage into a pattern library, which implies a write operation, but does not disclose potential side effects, required permissions, or whether the operation is reversible. The absence of behavioral context makes it difficult for an agent to anticipate consequences.
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, but the information is not front-loaded for quick scanning. The key action (compare and generate roadmap) is in the first sentence, which is good, but the sentence structure could be more concise and avoid redundancy with parameter descriptions.
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 lack of output schema and annotations, the description should cover return format and workflow context. It does not explain what the generated roadmap looks like, whether it requires further steps like approve_step, or how pattern extraction affects the pattern library. This gap reduces completeness.
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% with each parameter described. The description adds context about comparing six-dimensional ratings and automatic pattern extraction, but the latter is redundant with the parameter description for include_pattern_extraction. No additional meaning beyond the schema is provided, so a 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 identifies the tool as performing reverse evolution analysis by comparing six-dimensional ratings of two skills and generating a step-by-step roadmap. It mentions automatic pattern extraction, which differentiates it from sibling tools like compare_skills. However, it lacks specificity on what the 'evolution roadmap' entails and how it differs from similar analysis tools.
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 does not provide guidance on when to use this tool versus alternatives like compare_skills or search_patterns. There is no mention of prerequisites, when not to use it, or any context for its selection among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
深度分析指定技能。提取能力模块、技术栈、设计模式等。
| Name | Required | Description | Default |
|---|---|---|---|
| skill_name | Yes | 技能名称 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the behavioral transparency burden. It discloses that the tool extracts capability modules, tech stack, design patterns, implying a read-only analysis. However, it does not mention any side effects, required permissions, rate limits, or output format.
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?
Extremely concise: one sentence that front-loads the purpose. Every word adds value. No extraneous information.
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 1 parameter and no output schema, the description lacks completeness. It does not describe the return value structure or any constraints. While the tool is simple, without output schema, the description should at least hint at what the output looks like.
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% for the single parameter (skill_name). The description adds context about what is extracted but does not add meaning to the parameter itself (e.g., valid name formats, examples). Baseline 3 is appropriate as schema covers parameter definition.
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: deeply analyze a specified skill, extracting capability modules, technology stack, design patterns. Verb and resource are specific. However, it does not distinguish from sibling analysis tools like analyze_evolution or compare_skills, which could lead to confusion.
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 on when to use this tool versus alternatives. The description only states what it does, without any when-to-use or when-not-to-use context. With multiple sibling analysis tools, explicit usage guidelines are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
批准渐进式注入的某个步骤。接收 progressive_inject 返回的 plan_json 和 step_index。
| Name | Required | Description | Default |
|---|---|---|---|
| plan_json | Yes | progressive_inject 返回的完整 plan JSON 字符串 | |
| step_index | Yes | 要批准的步骤索引（从0开始） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only mentions 'approve' but does not specify if it is destructive, requires authorization, or what side effects occur. Minimal transparency beyond the action.
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 with no unnecessary words. The purpose and inputs are front-loaded, making it easy to scan.
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?
No output schema and minimal description. Lacks details on what happens after approval (e.g., execution, return values, error states). For a tool with side effects, this is insufficient.
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 schema has 100% coverage with descriptions for both parameters. The description adds value by explicitly linking the parameters to progressive_inject's output, providing context beyond the schema.
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 verb 'approve' and the resource 'step of progressive injection'. It specifies the tool receives plan_json and step_index from progressive_inject, which distinguishes it from sibling tools like reject_step.
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 after progressive_inject by referencing its outputs. It does not explicitly contrast with reject_step, but the context is clear enough for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
对比两个技能的差异。输出共同能力、独有能力、改进点和建议优先级。
| Name | Required | Description | Default |
|---|---|---|---|
| base_skill | Yes | 基础技能名称 | |
| candidate_skill | Yes | 候选技能名称 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action and outputs, but does not disclose behavioral traits such as whether the comparison is read-only, has side effects, requires permissions, or handles missing skills. The lack of any behavioral context makes it insufficient.
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 no redundant information. Every word 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 two-parameter tool with no output schema, the description adequately covers what the tool does and what it returns. It could include details about error handling or prerequisites, but it is complete enough for a basic comparison tool.
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% with clear parameter descriptions ('基础技能名称', '候选技能名称'). The description adds the output structure but does not add new meaning beyond the schema for the parameters themselves. 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?
The description clearly states it compares two skills and lists specific outputs (common abilities, unique abilities, improvement points, suggested priorities). It distinguishes from siblings like 'analyze_evolution' or 'compose_skills' by specifying a direct comparison of two 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?
The description implies when to use (comparing two skills) but gives no guidance on when not to use or alternatives. Sibling tools like 'analyze_skill' or 'recommend_combo' could be related, but no explicit differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
组合多个技能。支持diff模式（仅差异清单）、temp模式（临时返回）、persist模式（持久保存）、dry-run预演。
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | 基础技能名称（作为骨架） | |
| dry_run | No | 是否仅预演（不生成文件） | |
| additions | Yes | 要融合的技能列表 | |
| output_mode | No | 输出模式，默认diff | |
| conflict_choices | No | 冲突决策，key为冲突描述，value为A/B/C |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions modes but does not describe side effects (e.g., what gets persisted, how conflicts are handled if not specified), permission requirements, or error cases. The tool is a composer, so behavioral details for each mode are essential.
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 short and front-loaded with the main action. It uses Chinese which is appropriate given the context. However, the list of modes could be clearer with brief explanations.
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 5 parameters (including a nested object), no output schema, and no annotations, the description is insufficient. It does not explain return values, how conflict_choices works, or what happens in each mode. The tool's complexity demands more detail.
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 the description adds no new meaning beyond the schema. The description lists modes but that is already captured by the output_mode enum. Baseline 3 applies here.
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: combining multiple skills. It lists supported modes (diff, temp, persist, dry-run), which gives a good overview. However, it does not differentiate from sibling tools like compare_skills or recommend_combo, which might have overlapping functionality.
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 provides no guidance on when to use this tool versus alternatives, nor does it explain when each mode should be chosen. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
配置技能目录路径。第一次使用时必须调用此工具指定技能文件所在目录。保存后会写入配置文件并自动热加载。
| Name | Required | Description | Default |
|---|---|---|---|
| skill_paths | Yes | 技能目录路径列表，例如 ["~/.config/opencode/skills", "./skills"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses that after saving, it writes a config file and automatically hot reloads, which are critical behavioral traits.
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 sentences, no redundant information, ideally front-loaded.
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 one-parameter tool without output schema, the description fully covers purpose, usage timing, and behavioral effect (persistence and hot reload). 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% with a good description for skill_paths. The tool description doesn't add new parameter details but reinforces the purpose.
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 '配置技能目录路径' (configure skill directory path) and specifies it's a one-time setup tool, distinguishing it from sibling tools like list_skills or analyze_skill.
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 '第一次使用时必须调用此工具指定技能文件所在目录' (must be called on first use), providing clear usage context. No explicit when-not-to-use but adequate for a configuration tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出所有本地技能，支持模糊搜索。返回技能名称、路径和哈希。
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | 搜索关键词（可选，支持模糊匹配） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description carries the burden. It mentions fuzzy search and return fields but omits details like pagination, ordering, or read-only nature. Provides minimal behavioral context beyond what is obvious.
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?
Single sentence that is concise, front-loaded, and contains no superfluous information. Every word 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 list tool with one optional parameter and no output schema, the description adequately covers purpose and returns. Could mention if results are paginated or limited, but not critical.
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% (query parameter described). The tool description does not add semantic value beyond the schema; it restates the same information. 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 lists local skills with fuzzy search support and specifies return fields (name, path, hash). It differentiates from sibling tools like analyze_skill or compare_skills, though it does not explicitly mention distinctions.
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 on when to use this tool versus alternatives (e.g., search_patterns or list_templates). The description implies usage for listing skills but lacks contextual exclusions or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出所有已保存的组合模板。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond listing. It is adequate for a simple read operation but lacks detail.
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?
Single sentence, entirely focused on the tool's purpose with no extraneous information.
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 has no parameters and no output schema, the description adequately covers the core functionality, though it could mention return format or behavior.
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?
No parameters are present, and schema coverage is 100%. The description adds no parameter info, but none is 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?
Description clearly states verb 'list' and resource 'saved combination templates', distinguishing it from sibling tools like load_template or save_template.
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 explicit when/when-not guidance is provided, though the purpose is straightforward. Implied usage is to retrieve all templates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
加载已保存的组合模板。
| Name | Required | Description | Default |
|---|---|---|---|
| template_name | Yes | 模板名称 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the basic action without disclosing whether loading modifies state, requires authentication, or returns a result. No side effects or return value described.
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?
A single sentence that immediately conveys the action. No unnecessary words, perfectly front-loaded.
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 one-parameter tool, the description is adequate but lacks behavioral details such as return value or side effects. Given the absence of an output schema, more context would be beneficial.
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% for the single parameter. The description adds no extra meaning beyond 'template name' and the context that it is a combination template. 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?
The description clearly states it loads a saved combination template ('加载已保存的组合模板'). It distinguishes from sibling tools like save_template or list_templates, but does not explicitly contrast with other template-related tools.
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 on when to use this tool versus alternatives such as list_templates or recommend_combo. No conditions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
渐进式注入：将源技能的维度能力逐步注入基础技能。一次一个维度，每个步骤需要用户确认（approve/reject）。
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | 基础技能名称（待增强） | |
| source | Yes | 源技能名称（从中提取维度增强） | |
| output_mode | No | 输出模式，默认 diff | |
| step_filter | No | 仅关注指定维度，例如 ["speed", "robustness"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: stepwise injection, user confirmation via approve/reject. However, it omits details on final output, side effects, prerequisites, or error conditions, leaving significant gaps for an agent.
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 efficiently convey the core purpose and process. No wasted words, front-loaded with the action and key characteristics (progressive, user confirmation). Ideal conciseness.
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 moderate complexity (4 parameters, no output schema, no annotations), the description is too brief. It fails to explain output modes (diff/temp/persist), the role of step_filter, or how the tool integrates with sibling tools like approve_step. Leaves critical gaps for an agent to use correctly.
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% with clear parameter descriptions. The description adds context about the process (e.g., source supplies dimensions) but does not enhance parameter meaning beyond what the schema already provides. Baseline score 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: progressive injection of source skill dimensions into a base skill, one dimension at a time with user approval. It distinguishes itself from siblings like 'compose_skills' by emphasizing the stepwise process and user confirmation, though not explicitly contrasting them.
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 gradual skill enhancement with user confirmation, but does not provide explicit guidance on when to use this versus alternatives like 'compose_skills' or 'approve_step'. No when-not-to-use or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据任务描述自动推荐最佳技能组合。支持本地Ollama模型和云端LLM。
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | 任务描述 | |
| llm_provider | No | LLM提供商（可选） |
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 discloses the tool's basic function and provider support, but lacks important behavioral details like whether it creates or modifies state, the format of the recommendation output, or any 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 two short sentences covering the core functionality and key support detail, with no unnecessary words. It is appropriately sized and front-loaded.
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?
The tool has no output schema, and the description does not explain what the recommendation looks like (e.g., a list, a single combo, structured format). It is incomplete for a recommendation tool, leaving the agent guessing about the return value.
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 the baseline is 3. The description does not add significant meaning beyond the schema; it just names the parameters implicitly.
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 verb ('recommend') and resource ('best skill combination'), and the context of 'based on task description' differentiates it from siblings like analyze_evolution or compare_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?
The description mentions support for local Ollama and cloud LLMs, providing context on compatible providers, but does not explicitly state when to use this tool versus alternatives or when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
拒绝渐进式注入的某个步骤。接收 progressive_inject 返回的 plan_json 和 step_index。
| Name | Required | Description | Default |
|---|---|---|---|
| plan_json | Yes | progressive_inject 返回的完整 plan JSON 字符串 | |
| step_index | Yes | 要拒绝的步骤索引（从0开始） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It states the input parameters and the action (reject), but does not describe the effect on the plan, whether it is destructive, or what the return value is. This lack of detail leaves ambiguity.
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 very concise with two sentences that front-load the purpose. Every sentence is necessary and there is no extraneous information.
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 essential information: what the tool does and where the inputs come from. It is adequate but could mention return value or side effects for completeness.
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 description only paraphrases the parameter names and their source, which adds no additional meaning beyond what is already in the input schema. Schema coverage is 100%, so 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 that the tool rejects a step of progressive injection, using a specific verb ('reject') and resource ('step'). It also references the source of inputs (progressive_inject output), distinguishing it from sibling tools like approve_step.
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 provides clear context on when to use this tool (to reject a step from a plan returned by progressive_inject). However, it does not explicitly state when not to use it or mention alternatives like approve_step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
重新加载配置文件（热加载）。适用于手动修改 ~/.skill-composer/config.yaml 后同步到运行中的服务。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'hot reload' implying non-destructive, but does not disclose error handling or validation behavior. Adequate but could be more explicit.
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?
Single sentence, front-loaded with key action and context. No 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 0 parameters and no output schema, description covers purpose and trigger. Could mention failure modes or confirmation, but sufficient for a simple operation.
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?
No parameters in schema; description adds no parameter info but is unnecessary. Baseline 4 for 0-parameter tools.
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 verb 'reload' and resource 'config file', specifies 'hot reload' and context of manual editing. No sibling tool has similar purpose, so it is well-distinguished.
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 when to use (after modifying config.yaml for syncing to running service). Does not provide when-not or alternatives, but no direct alternatives exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
保存常用组合为模板，便于后续一键复用。
| Name | Required | Description | Default |
|---|---|---|---|
| additions | Yes | 融合技能列表 | |
| base_skill | Yes | 基础技能 | |
| description | No | 模板描述 | |
| template_name | Yes | 模板名称 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It does not disclose whether saving overwrites existing templates, requires permissions, or has limits.
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?
Single sentence is concise and front-loaded with the verb. However, brevity sacrifices clarity on what 'combinations' means.
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 4 parameters, no output schema, and no annotations, the description is too brief to fully inform an AI agent about tool behavior and outcomes.
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 baseline is 3. Description does not add meaning beyond parameter names and descriptions in schema.
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 uses 'save' and 'template' to indicate the action and resource. It distinguishes from siblings like load_template by focusing on saving. However, could be more specific about what 'common combinations' refers to.
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 on when to use this tool vs alternatives. No discussion of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索模式库。从已分析技能中提取的复用模式支持搜索、分类和成功率追踪。
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | 按标签筛选 | |
| limit | No | 返回条数上限 | |
| query | No | 搜索关键词（可选） | |
| category | No | 按分类筛选 (prompt_design / error_handling / performance / ...) | |
| min_success_rate | No | 最低成功率 (0-100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states it supports search/classification/tracking without disclosing whether it is read-only, modifies data, or has any side effects. Behavioral traits are not addressed.
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 short sentences; front-loaded with main purpose. No wasted words, though brevity may sacrifice completeness.
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?
No output schema, yet description fails to explain return format, pagination, or how success rate tracking integrates. Incomplete for a 5-parameter search tool.
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 baseline is 3. Description does not add meaning beyond parameter descriptions; it only reiterates that patterns can be searched/classified/tracked.
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 states 'Search pattern library' and lists capabilities (search, classify, track success rate). Clearly identifies the resource and verbs, distinguishing it from sibling tools like list_skills which list skills rather than patterns.
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 on when to use this tool versus alternatives. Sibling tools like analyze_skill or recommend_combo are not mentioned, leaving the agent to infer usage context.
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.
v2.0.0analyze_evolutionanalyze_skillapprove_stepcompare_skillscompose_skillsconfigure_skillslist_skillslist_templatesload_templateprogressive_injectrecommend_comboreject_stepreload_configsave_templatesearch_patternsScored across 15 tools
Each tool has a clearly distinct purpose: analysis, comparison, composition, progressive injection with approval workflow, template management, pattern search, and configuration. No overlap or ambiguity.
All tools follow a consistent verb_noun snake_case pattern (e.g., analyze_evolution, compare_skills, list_templates). The pattern is uniform and predictable.
15 tools cover the domain of skill composition and analysis comprehensively without being excessive. Each tool serves a necessary function in the workflow.
The tool set covers listing, analysis, comparison, composition, progressive injection, template management, pattern search, and configuration. Minor gap: no explicit delete operation for templates or skills, but this is acceptable for the intended use.
Agent-first skill marketplace with USK open standard for Claude, Cursor, Gemini, Codex CLI.
Search, install and submit Markdown skills for AI agents; private Brain files when signed in.
Search, fetch, lint, and install Agent Skills (SKILL.md) from the SkillMD registry.
One place to build, share, and govern the skills and tools your AI agents use at work.
