Render Video Frames

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

Adds real value beyond the annotations: it discloses that rendering executes the project's own code (explaining the destructiveHint/openWorldHint risk), that the server runs locally and writes/renders inside projectDir, and that a checklist comes back with the images. It does not say whether rendered files persist on disk or are cleaned up, which is the one behavioral detail still missing.

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?

Front-loaded with the action and the "preview before the full render" rationale in the first sentence, with security caveat and local-execution note layered after. Slightly redundant with the schema on the frame-picking advice, and the local-render/returns-images point is effectively stated twice.

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?

With 7 parameters, no output schema, and a nested props object, the description carries the burden of explaining the return ('returns the images' plus 'the returned checklist') and the security/prerequisite context, which it does. It could be more specific about the shape/format of the returned images, but the agent has enough to call it correctly.

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 100%, so the baseline is 3; the description goes above it by motivating scale ("0.5 keeps the images small enough to read back"), explaining projectDir's local-render semantics, and giving a selection heuristic for the frames array. entry, props, composition and context are left entirely to the schema.

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?

States a specific verb and resource ("Render chosen frames of a Remotion composition") and explicitly scopes it against the sibling activity of a full render ("so you look at your work before the full render"). An agent can distinguish it from the other video-related siblings without opening the schema.

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?

Clear when-to-use context (preview frames before rendering the film) plus a concrete procedure ("Pick the first, the settled and the last frame of each beat") and a follow-up loop (check the checklist, fix, then render). It stops short of naming an explicit alternative tool for the full render or stating exclusory conditions.

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