生成项目快照

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

注解未提供关于副作用的细节（readOnlyHint为false，表示有写入），描述中提及'不可变'，暗示创建后不可更改，但未说明是否覆盖现有快照、是否需要权限、是否影响其他数据，或返回什么信息。对于非只读操作，行为披露不足。

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?

对于具有2个必需参数且无输出模式、无枚举、无嵌套对象的工具，描述提供了基本的功能概述，但缺少关键上下文，如快照的唯一性、覆盖行为、权限要求等。鉴于工具复杂度和兄弟工具的存在，描述显得不够完整。

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%，描述未解释label和project_id的具体用途。虽然从参数名可推断，但描述没有为其添加任何语义，例如label是否用于标识快照，project_id是否必填等。描述未能补偿模式的缺失。

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?

描述明确说明了工具的具体功能：将项目当前的多种元素（知识索引、证据、决策等）保存为不可变快照。动词'保存'和资源'项目快照'明确，且与兄弟工具（如project_create、project_get）区分明显，因为其他工具不专门用于快照操作。

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?

描述没有说明何时使用此工具，也没有提及替代方案或排除条件。虽然隐含地指用于创建快照，但未与project_get或project_list等其他工具进行对比，或说明何时不应使用。

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