add_experience

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

没有注释，因此描述承担全部责任。它确实披露了一个真实的行为特征：status='draft' 会存储为待审批草稿，而 'approved' 直接入库，这暗示了审批工作流。但未提及权限、去重处理或非标输入会发生什么。

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?

前置一句话说明目的，然后是紧凑的参数列表。没有冗余，编辑得干净利落，尽管格式为简单的列表语法而非行文说明。

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?

存在输出架构，因此无需解释返回值。描述涵盖了目的、所有参数及审批工作流。主要缺口是缺少使用指南，说明何时新建记录与更新现有记录，这对于创建工具来说是合理的遗漏。

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?

架构描述覆盖率为 0%，因此描述必须弥补。它确实为全部六个参数提供了含义和示例（例如 title 'Nginx 403 绕过'、scenario_tags ['WAF绕过','SQL注入']），并明确了 status 的枚举值。tool_code 和 tool_type 的描述较为简短，但足够。

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?

明确说明具体动词+资源：将一条渗透测试经验添加到经验库。与 list_/search_/update_ 等同级工具明确区分。但是，仅凭类型名称没有明确排除或与 update_experience 进行对比。

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?

没有说明何时选择此工具而不是 update_experience 或 approve_experience 等替代工具。仅隐含表示这是创建路径。完全没有前提条件或排除条件。

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.