render_video

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

With no annotations, the description carries the full burden and discloses substantial behavior: sequencer-vs-scene selection, fps-based playback speed, filepath directory and extension constraints, audio codec compatibility, and the return dict shape. It does not mention overwrite semantics, failure modes, or permissions, which are relevant for a file-writing render operation.

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 front-loaded with the core purpose and then uses concise, information-dense sentences plus Args and Returns sections. Every part is useful given the zero schema description coverage, and there is no filler.

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 annotations, 0% schema description coverage, and an output schema, the description covers purpose, selection behavior, all parameters, key constraints, and return shape. It is nearly complete, though edge cases such as overwriting existing files or error handling are not addressed.

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 description coverage is 0%, but the description documents all four parameters with meaningful constraints: filepath empty means temp directory and extension must match the container, container values are enumerated, quality is described as a preset range, and audio_codec notes that WEBM accepts only OPUS or NONE. This compensates well for the schema's lack of parameter descriptions.

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 verb and resource: render the scene's frame range to a single video file with sound. It also distinguishes behavior from related tools by explaining that sequencer strips are used when present and that frames rendered with render_animation can be assembled, while an empty sequencer renders the 3D 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 description gives clear usage context: sequencer strips take precedence, and an empty sequencer falls back to rendering the 3D scene. However, it does not explicitly state when an agent should choose render_video instead of render_animation or render_image beyond the output being a video file.

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