generate_scene_images

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

There are no annotations, so the description carries the behavioral burden. It discloses that execution is background/asynchronous, that it must be preceded by an approved quote, and that the agent must not unilaterally confirm. It does not describe return values or job-status tracking, but the key behavioral traits are honestly and prominently stated.

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 main purpose and async behavior are front-loaded in the first clause, and the critical workflow warning follows without padding. Every sentence earns its place, and the warning is compressed but complete.

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?

Given no output schema and no annotations, the description covers purpose, async behavior, and the mandatory quote-confirmation flow well. It falls short by not stating what the async call returns or how to track completion (e.g., a job id or status tool), and the phrase '对应的 quote_* 工具' is slightly ambiguous among the many quote_* siblings, though quote_id's schema description narrows it.

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 50%: quote_id is described in the schema and additionally explained in the description as coming from the quote tool and requiring user approval. However, drama_id is left only with a type and minimum constraint, and the description adds no meaning for it. Partial compensation for the coverage gap.

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 states a specific action: after confirmation, batch-generate scene images, and notes it is asynchronous. It clearly separates this execution tool from the quoting step by requiring a quote_id from a quote_* tool, so an agent can distinguish generate_scene_images from quote_scene_images and upload_scene_image.

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?

The description gives an explicit workflow: first call the corresponding quote_* tool, relay estimated_points verbatim, wait for explicit user consent, then call this tool with the returned quote_id. It also warns 'don't confirm on your own', which is a clear exclusionary rule against invoking without approval.

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