generate_tts

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

There are no annotations, so the description carries the full burden. It discloses that the operation runs in the background ('后台异步'), that billing is usage-based, and that there is a hard prerequisite on voice assignment. It does not mention how to check completion status or whether re-running overwrites existing TTS, which prevents a 5.

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?

The description is compact: four short clauses each carry a distinct fact — scope, pipeline timing, prerequisite, and async/billing behavior. The main purpose is front-loaded. The phrase '按用量后付不欠费' is slightly awkward and less essential than the other details, so it is concise but not perfectly smooth.

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?

For a one-parameter async tool with no output schema and no annotations, the description covers the key preconditions and async behavior well. However, it omits how the agent will know when the background job finishes or whether it returns a job identifier for status polling. This is a meaningful gap for an asynchronous pipeline step.

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 coverage is 0%, so the description must compensate. It indirectly clarifies episode_id by saying '整集' (whole episode), indicating that the parameter targets the episode whose dialogue should be dubbed. It does not explain how to obtain the episode_id or verify that the episode is ready for TTS, but the single simple integer parameter is reasonably contextualized.

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?

The description opens with a specific verb-object pair: '给整集所有对白批量配音(TTS)' — batch-dub all dialogue for a whole episode. This clearly distinguishes it from single-line TTS tools like speak_with_voice and from voice-assignment tools like assign_voices, and it further positions the tool in the pipeline as the audio step before final cut.

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?

It explicitly states when to use the tool: before final delivery, after assign_voices has been run. The prerequisite '前置:先 assign_voices 给角色分配音色' is concrete and actionable. However, it does not explicitly contrast with alternatives such as speak_with_voice or explain when not to use batch dubbing, so it falls just short of a 5.

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