init_project

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

无注解，描述承担全部责任。说明会分析和生成文档，但未提及是否修改文件或需要授权。行为透明但缺乏细节。

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?

虽然无输出 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?

参数描述覆盖100%，描述中补充了project_name的默认值（'新项目'），但input参数描述与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?

明确说明在用户提供一句话需求时使用，并基于Spec-Driven Development理念生成完整项目规格文档，包括需求分析、技术设计和任务拆解。与sibling工具（如start_feature、start_bugfix）区分清晰。

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?

描述中指出适合项目初期的需求澄清和规划，但未明确说明不适合的场景或替代方案。尽管如此，使用场景清晰，隐含了与其他工具的区分。

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