flow_generate_scene

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

With no annotations provided, the description carries the full behavioral burden. It adds useful context: silent headless background execution and a completion signal in the form of a local MP4 path. Yet it omits failure behavior, timeout semantics, file-overwrite behavior, and any indication of required credentials or credits.

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 short, front-loaded, and has no filler; both sentences carry meaning. However, for a tool with 13 parameters and multiple close siblings, this level of brevity borders on under-specification, which costs one point.

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?

This is a complex, long-running generation tool with no annotations and no schema-level parameter descriptions, so the description must do heavy lifting. It does not explain how to call it correctly, what output_path means, when to use it versus flow_submit_scene or yenflow_generate_scene, or what silent headless mode implies for execution. The output schema mitigates return-value questions but not the missing input and workflow context.

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?

All 12 schema parameters have 0% description coverage, and the description compensates for none of them. It never explains required inputs like prompt or start_frame, nor optional controls like duration, resolution, model, or output_path. The only operational fact mentioned is the MP4 return value, which is not parameter semantics.

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 clearly states the verb and resource: it generates a single video scene end-to-end and returns the local MP4 path. It distinguishes itself from poll/submit/stitch siblings by claiming end-to-end generation, but it does not differentiate from the near-identical sibling yenflow_generate_scene.

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 phrase 'silent headless background mode' implies the tool is meant for unattended single-scene generation, and 'end-to-end' suggests it should be used instead of separate submit/poll steps. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named among the many scene-generation siblings.

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