Skip to main content
Glama

render

Exports the active sequence to a media file and waits for completion, supporting MP4/H.264, MOV ProRes/DNxHR, GIF, PNG sequence, and WAV output.

Instructions

Export the active sequence to a media file and wait for it (H.264 .mp4 by default from the extension; also .mov ProRes/DNxHR, .gif, .png sequence, .wav…).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "output": "<output>"
    },
    "name": "render"
  }
}

Input Schema

NameRequiredDescriptionDefault
endNoRange end in seconds
scaleNoRender at a fraction of the frame size
startNoRange start in seconds
formatNoh264|hevc|prores|dnxhr|mjpeg|gif|png|wav|aac…
outputYesOutput path; the extension picks the format unless format/preset is given
presetNoExport preset name, e.g. "YouTube 1080p Full HD"
noAudioNo
projectNoPath to the .fcproj project file; omit to edit the FilmCraft app connected with connect_app
qualityNoFor formats that take one; H.264/HEVC size is set by bitrateMbps
bitrateMbpsNoTarget video bitrate for H.264/HEVC, e.g. 40
bitrateModeNo
allowOfflineNoAccept placeholder frames for missing media
maxRenderQualityNoTurn on the sequence's Maximum Render Quality first: sharper scaling of large (e.g. 4K) sources

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false and openWorldHint=false, so the description must add the rest. It usefully discloses the blocking semantics ('wait for it') and the default format resolution from the file extension, both of which affect how an agent sequences calls. It still omits overwrite behavior on an existing output path and rough cost/duration for a long-running export.

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?

A single sentence with the core action and default front-loaded, and the format enumeration tucked into one parenthetical. Nothing is padded or repeated for its own sake.

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 13-parameter, side-effecting export with no output schema, the description leaves the return value undescribed (path? status? job id?) and says nothing about overwriting or failure on missing media despite an allowOffline flag existing. Adequate to call the tool, but thin for its complexity.

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 85%, so the schema already documents nearly every parameter and the baseline of 3 applies. The description adds a modest mapping of formats to containers (.mov ProRes/DNxHR, .gif, .png sequence, .wav), but largely restates the schema's own note that the extension picks the format unless format/preset is given.

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 resource: 'Export the active sequence to a media file', plus a concrete default codec/container. An agent can distinguish it from render_frame (single frame) and ffmpeg_convert by the 'active sequence' scope, though the overlap with the sibling export_timeline is never addressed.

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

Usage Guidelines3/5

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

Usage is only implied: an agent infers this is the final-deliverable export path. There is no explicit statement of when to prefer this over export_timeline, export_frames, or render_frame, and no prerequisites such as needing a connected app or a saved project.

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