Skip to main content
Glama

retime_add

Idempotent

Add a speed change to a clip's span, defined by start and end words, phrases, or events, with a target render duration. Speeds up or slows down that segment while muting its audio.

Instructions

Play a span of the film faster or slower: "from event sent to event words in 1.0 s".

The span starts at a word, phrase or event of clip_id and ends at one; it is resolved through the timeline on every build, never stored as seconds. Everything outside every stretch plays at 1x, with the speed eased in and out over half a second either side. The film's own audio is muted wherever it plays off speed; music, sounds, overlays and captions keep 1x and land where the retime puts their moment. Stretches may not overlap.

The reply gives the span in Edit seconds and render seconds, its speed, and the render's new length; plan=true writes nothing. Any retime routes export through the MLT writer. A film-audio hold cannot share a project with a retime yet, and the window previews at 1x.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoThe project directory to act on. Omit it — the usual case — when this server is bound to a project (started as `proofcut -C DIR mcp`, or inside a project; `ping` says which): it then resolves to that one bound project, a relative path resolves against it, and a path outside it is refused by name. Unbound, `path` is the whole address and omitting it refuses rather than guessing.
planNoResolve the whole call and report what it would do, writing nothing. Prefer it over doing the thing and undoing it.
afterNoA forward cursor over a phrase's matches: any match at or before this word index is skipped. -1, the default, means from the start.
eventNoStart on this event of clip_id: `name`, or `name#k` when the name repeats.
phraseNoStart on this phrase's FIRST word, resolved against clip_id's transcript.
clip_idYesThe clip whose words or events address the span — the transcript the word indices index, or the recording the events belong to.
secondsYesHow long the span plays for in the render. Shorter than the span speeds it up (a 31 s wait in 1.0), longer slows it down.
occurrenceNoDisambiguate a phrase by count when it matches more than once, **1-based** in transcript order among the matches after `after`: 1 is the first, 2 the second. Unset, an ambiguous phrase is refused — listing every candidate's range and text — rather than guessed at.
word_indexNoThe word the stretch starts on. One of word_index, phrase or event.
until_eventNoEnd on this event of clip_id.
until_phraseNoEnd as this phrase's LAST word ends.
until_word_indexNoEnd as this word ends. One of until_word_index, until_phrase or until_event.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.36.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark idempotentHint=true and destructiveHint=false, but the description adds substantial behavioral context: spans are resolved through the timeline on every build (not stored as seconds), speed is eased over half a second, film audio is muted off-speed while other audio stays 1x, stretches cannot overlap, plan=true writes nothing, and export routes through the MLT writer. This far exceeds annotation information and gives the agent a clear model of the tool's effects.

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?

The description is dense but every sentence earns its place: purpose+example, span resolution, global playback behavior, audio behavior, overlap constraint, reply format, plan behavior, export and compatibility notes. It is front-loaded with the core purpose, followed by progressively more specific details. No filler or repetition of schema content.

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 12-parameter tool with an output schema, this description covers all essential behavioral aspects: span addressing, speed easing, audio handling, constraints (no overlap), dry-run via plan, reply contents, export pipeline, and a critical incompatibility with film-audio holds. An agent has enough context to invoke the tool correctly and interpret its effects, with output schema covering return values.

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

Parameters4/5

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the span concept ('starts at a word, phrase or event of clip_id and ends at one') and referencing how parameters like seconds are used ('from event sent to event words in 1.0 s'). It clarifies the relationship between start/end parameters and the timeline, which is not fully spelled out in individual parameter descriptions.

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?

The description opens with a specific verb and resource: 'Play a span of the film faster or slower', and illustrates with a concrete example ('from event sent to event words in 1.0 s'). It clearly distinguishes this from siblings like hold_add by focusing on temporal speed adjustment. The purpose is unmistakable.

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?

The description provides clear context for when to use this tool: whenever a span needs non-1x playback. It also gives an implicit alternative constraint by noting 'A film-audio hold cannot share a project with a retime yet', which warns against combining with hold tools. It does not explicitly name sibling tools as alternatives, but the context and constraints are sufficient for an agent to select it.

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

Deploy Server

Other Tools