Skip to main content
Glama

Render (write)

render_write
Destructive

Configure DaVinci Resolve render formats, presets, settings, and jobs, then queue or start renders and verify changes by reading them back from Resolve.

Instructions

Change render state; may overwrite current values. Every change is read back from Resolve (receipt.verified=false means it did not take). op.action (params; * = required):

  • add_render_job(): Queue a render job from the current render settings; returns its id.

  • export_render_preset(name*, path*): Export a render preset to a file.

  • import_render_preset(path*): Import a render preset from a file and select it.

  • load_render_preset(name*): Load a render preset as the current render settings.

  • quick_export(preset*, target_dir, name, video_quality, enable_upload): Render the current timeline with a Quick Export preset (21.1+, long-running). [job]

  • render_timeline(preset*, target_dir*, name*, format, codec, settings): One-shot: load preset, set target and name, queue and start (long-running). [job]

  • save_render_preset(name*): Save the current render settings as a new preset.

  • set_quick_export_preset(name*, enabled): Enable or disable a render preset for Quick Export (21.1+).

  • set_render_format(format*, codec*): Set the render format and codec (validated against the live list).

  • set_render_mode(mode*): Set the render mode (single clip or individual clips).

  • set_render_settings(settings*, base_preset): Apply render settings (on top of the loaded preset).

  • start_rendering(job_ids, interactive): Start rendering queued jobs (long-running; poll with job_wait). [job]

  • stop_rendering(): Stop any current render. Shortcuts (prefer them for whole tasks):

  • workflow_write.build_vertical_reel: Build a vertical timeline from clips, add subtitles and optionally render it. One call instead of render_timeline.

  • workflow_write.deliver: Render one or more outputs (preset/format/size) and report the real files produced. One call instead of set_render_settings, set_render_format, add_render_job, start_rendering, render_timeline. Calls known in advance (a sequence, the same change on several items): ONE batch_run.

Input Schema

NameRequiredDescriptionDefault
opYes{action, ...params}. Parameters per action: see the description or this server's describe_action tool.
dry_runNotrue: return the planned effect, change nothing.
snapshotNotrue: back up the timeline/project first; omitted: server policy.

Output Schema

NameRequiredDescriptionDefault
jobNo
planNo
statusYes
receiptNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.4
    • addedInput schema / properties / dry_run / description
      Added value: +"true: return the planned effect, change nothing."
    • addedInput schema / properties / snapshot / description
      Added value: +"true: back up the timeline/project first; omitted: server policy."
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well past the annotations (destructive/not-idempotent): it discloses that values may be overwritten, that every change is read back from Resolve with receipt.verified=false meaning it did not take, that quick_export/render_timeline/start_rendering are long-running and must be polled with job_wait, and that format/codec are validated against the live list. These are operational facts an agent cannot get from structured fields.

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

Conciseness4/5

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

Front-loads the critical overwrite/verify warning, then a scannable bullet-per-action list, then shortcut routing. Dense for 13 actions but nearly every line is load-bearing; only the '[job]' tags and version notes add minor visual noise.

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

Completeness5/5

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

For a 13-action polymorphic mutation tool with a nested op object, the description covers action inventory, required vs optional params, long-running/polling behavior, version gating (21.1+), and verification semantics. An output schema exists, so return-shape explanation is correctly omitted.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% on the three top-level params, but the schema defers per-action params to free-form additionalProperties. The description supplies them per action with '* = required' markers and defaults (e.g. render_timeline's optional format/codec/settings vs required preset/target_dir/name), which is meaning the schema does not carry.

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

Purpose5/5

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

Opens with a specific verb and resource plus scope: 'Change render state; may overwrite current values.' It then enumerates all 13 actions with one-line semantics, so an agent can match intent to action without opening the schema, and the write framing cleanly separates it from the sibling render_read.

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

Usage Guidelines5/5

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

Explicitly routes the agent: 'Shortcuts (prefer them for whole tasks)' names workflow_write.deliver and workflow_write.build_vertical_reel with the exact low-level calls each replaces, and 'Calls known in advance... ONE batch_run' covers the batch case. Both alternatives and the conditions that select them are stated.

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