Skip to main content
Glama

render_preview

Generate a low-res MP4 preview to review the primary storyline before importing. Optionally render only a specific start/end section for quick checks.

Instructions

Render a quick low-res MP4 of the primary storyline (straight cuts, no effects, titles or connected clips) so the user can review an edit before importing. Optional start/end seconds render only part of it.

Input Schema

NameRequiredDescriptionDefault
endNo
startNo
heightNo
output_pathNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does useful work: it discloses the output format, resolution class, and exactly what content is omitted from the render. It says nothing about render duration/blocking behavior, where the file lands when output_path is null, or whether an existing file is overwritten.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the primary purpose and its scope caveats front-loaded; the optional partial-render note follows naturally. No filler or restated name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter, no-output-schema tool whose result is a file on disk, the gap around output_path destination and render timing is material — an agent cannot tell where the MP4 will be written or whether the call blocks. Core intent is covered, but these practical details are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 supplies units for start/end ('seconds') and clarifies that they render only a subrange, and 'low-res' loosely explains height, but output_path and the height default (360) are left completely undescribed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and output artifact ('render a quick low-res MP4 of the primary storyline') plus explicit scope limits (straight cuts, no effects, titles or connected clips). It implicitly separates itself from a full export, but never names fcp_export_project or any sibling, so an agent must infer the contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'so the user can review an edit before importing' gives a clear context for when to call it, and the 'quick low-res' framing implies it is not the tool for final delivery. No explicit when-not or named alternative (e.g. fcp_export_project) is provided.

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