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

没有 annotations，因此说明文字需要承担全部披露义务。它确实提供了结构化字段没有的重要计费语义：按次计费，仅在业务成功时扣费，内容违规、模型超时或生成失败会自动全额退款。但它没有说明如何使用返回的代码、延迟预期或长度限制。

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 完全描述，计费风险也已覆盖。但该工具没有输出 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?

Schema 描述覆盖率为 100%，四个参数都在 schema 中有完整文档，包括 prompt 的 4000 字符限制以及 requestId 的幂等用途。说明文字没有为这些参数增加任何信息，因此基线 3 分是合适的。

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?

明确写出动词+资源：根据需求描述生成「可运行的示例代码」。这足以区别于 docgen、copywriter、translate 等工具。不过，它没有说明与 script 和 sqlgen 等相近同类工具的区别，而这两个工具同样会生成代码。

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?

用途只能从动词推断（把自然语言需求描述变成代码）。没有说明何时改用 script/sqlgen/testgen，也没有前提条件或排除项。至少所需输入（需求描述）是明确的，但缺少选择工具时的规则。

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