lzwcai-mcp-server-package/.kilo/skills/mcp-tool-testing/SKILL.md

name, description, version

name	description	version
mcp-tool-testing	MCP 工具通用测试技能。自动发现、执行和组合测试任何 MCP 服务器中的工具，支持场景自动创造和风险前置询问。	0.1.0

MCP Tool Testing Skill

这是一个通用的 MCP（Model Context Protocol）工具测试技能。适用于任何 MCP 环境，无论是自研的还是第三方的。

核心原则

1. 通用性：不假设任何具体的服务器名称、工具名称或项目结构
2. 自动发现：通过 MCP 协议本身获取当前环境中可用的所有工具
3. 智能执行：能判断的入参自动执行，不能判断的询问用户
4. 场景自动创造：根据工具自动匹配并创造测试场景，无需用户指定
5. 风险前置：有风险的操作必须询问用户确认，绝不擅作主张
6. 结果汇总：最终只返回执行工具的入参、出参和理解

执行流程

第一步：发现可用工具

通过 MCP 的 tools/list 方法获取当前环境中所有可用的工具。

获取每个工具的信息：

• 工具名称（name）
• 工具描述（description）
• 入参 schema（inputSchema）：
  • 参数名称
  • 参数类型（string, integer, boolean, object, array, enum 等）
  • 是否必填（required）
  • 默认值（default）
  • 枚举值（enum）
  • 参数描述（description）

第二步：分析工具并分类

根据工具名称和描述，自动对工具进行分类：

1. 查询类：list_xxx, get_xxx, query_xxx, search_xxx, find_xxx
2. 创建类：create_xxx, add_xxx, insert_xxx, new_xxx
3. 更新类：update_xxx, edit_xxx, modify_xxx, alter_xxx
4. 删除类：delete_xxx, remove_xxx, drop_xxx
5. 执行类：execute_xxx, run_xxx, call_xxx, invoke_xxx
6. 状态类：toggle_xxx, enable_xxx, disable_xxx, start_xxx, stop_xxx
7. 其他：无法归类的工具

第三步：执行单个工具

对每个工具，按以下策略执行：

入参判断逻辑

对于每个必填参数（required 中的参数）：
  1. schema 有 default 值 → 使用该默认值
  2. schema 有 enum 且只有一个值 → 使用该值
  3. schema 有 enum 且有多个值 → 使用第一个，或询问用户
  4. 参数名是常见的通用类型：
     - pageNum, page, offset → 使用 1
     - pageSize, limit, size → 使用 10
     - target, environment → 使用 "prod" 或第一个 enum 值
     - status, enabled → 使用 0 或 true
     - name, title → 使用测试名称如 "test_item"
     - id, xxxId → 需要从其他工具查询获取，或询问用户
  5. 可以从之前执行的工具结果中获取 → 使用前一个工具的输出
  6. 以上都不满足 → 询问用户

对于非必填参数：
  - 一般不传，使用服务器默认值
  - 如果需要测试特定功能，可以传一个合理值

询问用户的标准

当遇到以下情况时必须询问：

1. 参数不明确

• 参数是必填的，且值完全不明确
• 例如：某个特定的业务 ID、密钥、路径等

2. 参数有多个合理选项且无法自动判断

• 例如：enum 有 ["mysql", "postgresql", "oracle"]，不知道测试用哪个

3. 参数涉及敏感信息

• 例如：password, token, apiKey, secret 等

4. 高风险操作必须询问（绝不擅作主张）

以下类型的工具/操作在执行前必须先询问用户确认：

• 删除类：delete_xxx, remove_xxx, drop_xxx, destroy_xxx

  • 风险：数据丢失，不可恢复
  • 询问内容：确认是否要执行删除操作，指定删除目标或使用测试数据

• 泄密风险类：export_xxx, dump_xxx, download_xxx, get_all_xxx（大量数据）

  • 风险：可能导出敏感业务数据、用户信息、密钥等
  • 询问内容：确认是否要导出数据，是否使用脱敏测试数据

• 政治敏感类：涉及政府、政策、领导人等相关内容的工具

  • 风险：可能触及政治敏感话题
  • 询问内容：确认测试方向和范围

• 似黄/色情风险类：涉及用户生成内容、图片、文本审核等相关工具

  • 风险：可能接触到不当内容
  • 询问内容：确认是否使用安全的测试数据

• 生产环境操作类：影响生产环境数据的工具

  • 风险：可能影响真实业务
  • 询问内容：确认是否在测试环境执行，或使用只读模式

5. 更新/修改类操作需要确认

• 例如：update_xxx, modify_xxx 可能改变真实数据

高风险操作询问格式：

⚠️ 高风险操作提醒

工具：[工具名]
风险类型：[删除/泄密/政治敏感/似黄/生产环境影响]
具体风险：[描述可能的风险]

请选择：
1. 确认执行，使用测试数据
2. 确认执行，使用真实数据（我知道风险）
3. 跳过此工具
4. 其他指示

普通询问格式：

工具：[工具名]
参数：[参数名]（类型：[类型]，必填：是/否）
用途：[从 description 中提取]

请选择：
1. [建议选项1，如果有]
2. [建议选项2，如果有]
3. 提供自定义值

或者告诉我使用什么值。

执行顺序策略

1. 先执行无参数或少参数的查询工具

   • 如 list_xxx、get_all_xxx 等
   • 这些工具通常不需要太多参数，可以直接执行
   • 执行结果可以为后续工具提供 ID 等参数

2. 利用查询结果作为后续工具的入参

   • 例如：list_datasources 返回的 id 用于 get_datasource_detail
   • 例如：list_tables 返回的 tableId 用于 query_table_data

3. 最后执行创建/修改/删除类工具

   • 这些通常需要更多上下文参数
   • 删除操作要特别小心，确认是测试数据

第四步：场景自动创造与搭配测试

这是本技能的核心能力：根据当前所有可用工具，自动创造有意义的测试场景，无需用户指定。

场景识别规则

根据工具的名称、描述和参数，自动匹配以下 8 种场景模式：

1. 查询链路场景

• 匹配规则：存在 list_xxx + get_xxx_detail/xxx_detail + query/get_data 类工具
• 创造方式：list 获取列表 → 取第一条的 ID → get detail 获取详情 → 用详情中的 ID 查询关联数据
• 示例：list_datasources → get_datasource_detail(id) → list_tables(datasourceId) → get_table_detail(tableId)

2. 完整 CRUD 场景

• 匹配规则：存在 create_xxx + list/query_xxx + update_xxx + delete_xxx 类工具
• 创造方式：create 创建测试数据 → list 确认存在 → update 修改 → list 确认修改 → delete 删除 → list 确认删除
• 示例：create_api_key → list_api_keys → toggle_api_key_status → list_api_keys → delete_api_key → list_api_keys

3. 状态变更验证场景

• 匹配规则：存在 get/list_xxx + toggle/enable/disable/start/stop_xxx 类工具
• 创造方式：get 初始状态 → toggle 变更状态 → get 验证状态已变更 → toggle 恢复 → get 验证恢复
• 示例：get_datasource_detail → toggle_datasource_status(status=1) → get_datasource_detail → toggle_datasource_status(status=0) → get_datasource_detail

4. 参数传递链路场景

• 匹配规则：工具 A 的输出字段与工具 B 的输入参数名匹配或语义相关
• 创造方式：执行 A → 从结果提取字段 → 作为 B 的输入 → 执行 B → 继续传递给 C
• 示例：list_datasources 返回 datasourceId → get_datasource_detail(datasourceId) 返回 connectionId → execute_sql(connectionId, sql)

5. 批量操作场景

• 匹配规则：存在接受 array 类型参数的工具（如批量删除、批量授权）
• 创造方式：list 获取多条记录 → 提取 IDs 数组 → 传递给批量操作工具 → 验证结果
• 示例：list_api_keys → 提取 ids → grant_api_key_permissions(batchDatas=[{...}])

6. 条件分支场景

• 匹配规则：工具支持不同枚举参数或可选参数，产生不同行为
• 创造方式：同一工具传不同参数 → 对比输出差异
• 示例：query_table_data(tableId, target="prod") vs query_table_data(tableId, target="test")

7. 异常处理场景

• 匹配规则：任何工具
• 创造方式：传入无效 ID、空参数、错误类型 → 验证错误处理是否合理
• 示例：get_datasource_detail(datasourceId="invalid") → 验证返回错误信息

8. 跨服务器场景（当有多个 MCP 服务器时）

• 匹配规则：不同服务器的工具之间存在业务关联
• 创造方式：服务器A的输出 → 作为服务器B的输入
• 示例：IoT 获取设备列表 → Dify workflow 处理设备数据 → SQL 执行存储结果

场景自动创造流程

1. 收集所有工具，建立工具字典
   - key: 工具名
   - value: {description, inputSchema, outputSample, category}

2. 构建参数依赖图
   - 分析每个工具的输入参数名（如 datasourceId, tableId, apiKeyId）
   - 分析每个工具的输出字段（从执行结果中提取）
   - 建立 "输出字段 → 输入参数" 的映射关系

3. 匹配场景模式
   - 遍历上述 8 种场景规则
   - 对每种规则，检查当前工具集是否满足匹配条件
   - 满足则创造具体场景实例

4. 场景优先级排序
   - P0: 查询链路（最基础，最先执行）
   - P1: CRUD 完整链路（验证完整生命周期）
   - P2: 状态变更验证（验证状态管理）
   - P3: 参数传递链路（验证工具间协作）
   - P4: 批量操作、条件分支、异常处理
   - P5: 跨服务器场景（最复杂，最后执行）

5. 执行场景
   - 按优先级依次执行
   - 前一步的输出自动传递给下一步
   - 任何一步失败则标记场景失败，继续下一个场景
   - 场景中包含高风险操作时，执行前询问用户

场景执行记录格式

### 场景：[场景名称]
- **触发规则**：[匹配的场景模式，如 "查询链路场景"]
- **涉及工具**：工具A → 工具B → 工具C
- **执行过程**：
  | 步骤 | 工具 | 入参 | 出参摘要 | 状态 |
  |------|------|------|---------|------|
  | 1 | list_xxx | {} | 返回 5 条记录 | ✅ |
  | 2 | get_xxx | {id: "从步骤1获取"} | 返回详情 | ✅ |
  | 3 | query_xxx | {xxxId: "从步骤2获取"} | 返回结果 | ✅ |
- **数据流**：步骤1.id → 步骤2.id → 步骤2.connectionId → 步骤3.connectionId
- **场景结果**：✅ 全部成功 / ❌ 步骤N失败（原因：...）
- **理解**：[对这个场景的整体理解，工具间如何协作]

场景测试要点：

• 记录完整的数据流转过程
• 验证工具之间的兼容性
• 检查数据格式是否一致
• 场景创造过程不需要用户干预，自动完成
• 只在遇到无法判断的参数或高风险操作时才询问用户

第五步：生成报告

最终只返回以下内容：

# MCP 工具测试报告

## 工具列表

共发现 [N] 个工具：

| 序号 | 工具名 | 描述 | 必填参数 | 分类 |
|------|--------|------|---------|------|

## 工具执行结果

### 1. [工具名]
- **描述**：[工具描述]
- **入参**：`{JSON}`
- **出参**：`{JSON 摘要}`
- **状态**：✅ 成功 / ❌ 失败 / ⚠️ 跳过（原因：...）
- **理解**：[你对这个工具功能的简要理解]

### 2. [工具名]
...

## 场景测试

### 场景1：[场景名称]
- **流程**：工具A → 工具B → 工具C
- **数据流**：[描述数据如何在工具间传递]
- **结果**：[最终结果摘要]
- **状态**：✅ 成功 / ❌ 失败

## 总结

| 指标 | 数量 |
|------|------|
| 发现工具总数 | N |
| 成功执行 | N |
| 执行失败 | N |
| 跳过（需用户提供信息） | N |
| 高风险操作（已询问用户） | N |
| 场景测试数 | N |

## 待确认事项

列出需要用户提供的参数或信息：
1. [工具名] 的 [参数名]：[说明]
2. ...

特殊处理

动态工具

有些服务器启动时从外部加载工具定义（如从 API、配置文件、工作流引擎等）：

1. 通过 MCP 协议获取实际可用的工具列表
2. 对动态获取的工具同样按照上述流程测试
3. 记录工具的来源信息（如果有）

需要认证/配置的服务器

某些 MCP 服务器需要特定的环境变量、API Key、Token 等：

1. 检查服务器是否正常运行
2. 如果启动失败，记录错误信息并跳过
3. 如果运行正常但工具调用失败（如 401），询问用户提供认证信息

失败处理

• 网络超时：记录错误，标记为失败，继续下一个
• 参数错误：检查是否需要补充参数，或询问用户
• 服务器未运行：记录原因，跳过该服务器的所有工具
• 工具不存在：可能工具定义已变更，重新获取工具列表

输出处理

• 输出过长时适当截断（如超过 2000 字符）
• 保留关键信息：状态码、主要数据、错误信息
• 对于列表类输出，显示前几条和总数

注意事项

1. 保持参数一致性：同一个 ID 在多个工具中保持相同
2. 风险前置：高风险操作必须先询问用户，绝不擅作主张
3. 记录完整：每个工具的入参、出参都要记录
4. 及时询问：遇到不明确的参数不要猜测，询问用户
5. 场景优先：优先测试有意义的场景组合，而不是孤立地测试每个工具
6. 自动创造：场景不需要用户指定，根据工具自动匹配和创造
7. 最终输出：只返回入参、出参和理解，不需要冗长的过程描述
8. 五类风险：删除、泄密、政治、似黄、生产环境影响——必须询问用户