Skip to main content
Glama

Retime Caption File

retime_caption_file

Retimes local SRT/VTT caption files after ripple removals or inserts so captions stay aligned with an edited Premiere timeline; the project itself is not modified.

Instructions

Retime a local SRT/VTT file after ripple edits; Premiere captions do not follow ripple_remove_timeline_ranges or insert_from_source. Operations: shift, ripple_remove_ranges, ripple_insert, edit_cue. Keeps VTT header/NOTE/STYLE, cue settings, karaoke stamps; renumbers SRT. Local-only, never changes Premiere: re-import via create_caption_track, then reapply styling (get_caption_style_guidance).

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": {
      "operation": "<operation>"
    },
    "name": "retime_caption_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
fpsNoOptional sequence frame rate (e.g. 23.976, 25, 29.97). When set, every output time and every removal range snaps to the nearest frame, matching ripple_remove_timeline_ranges; otherwise times round to milliseconds. Required for offset_frames and duration_frames.
textNoedit_cue: replacement cue text; separate lines with a newline. Blank lines and "-->" are rejected.
rangesNoripple_remove_ranges: removed timeline ranges in seconds, sorted and non-overlapping (the same ranges passed to ripple_remove_timeline_ranges; overlapping ranges are rejected, not merged).
contentNoInline SRT or VTT text. Provide exactly one of input_path or content. A UTF-8 BOM and CRLF line endings are accepted.
cue_indexNoedit_cue: 1-based cue position in file order (SRT numbers are ignored).
operationYesshift, ripple_remove_ranges, ripple_insert, or edit_cue.
at_secondsNoripple_insert: timeline time of the insert; cues starting at or after it move right.
input_pathNoAbsolute path of an existing .srt or .vtt file inside approved_workspace_path (realpath-checked, at most 2097152 bytes). Provide exactly one of input_path or content.
end_secondsNoedit_cue: new cue end in seconds; must be after the start.
output_pathNoOptional absolute .srt/.vtt path to write the result to. Requires approved_workspace_path; the parent must exist inside it and the file must not already exist (never overwritten).
from_secondsNoshift: only shift cues whose start is at or after this time; earlier cues stay put.
input_formatNoSyntax of the input. Defaults to the input_path extension, else VTT when content starts with WEBVTT, else SRT.
offset_framesNoshift: whole frames to add at fps (negative moves earlier).
output_formatNoFormat of the result (default: the output_path extension, else the input format). SRT output drops VTT header/NOTE/STYLE/REGION blocks, cue settings, identifiers, and karaoke timestamps, with warnings.
start_secondsNoedit_cue: new cue start in seconds.
offset_secondsNoshift: seconds to add (negative moves earlier). Cues ending at or before 0 are removed; cues crossing 0 are trimmed. Use exactly one of offset_seconds or offset_frames.
return_contentNoAlso return the retimed text inline when output_path is set (default false). Inline text is always returned without output_path, up to 512 KiB.
duration_framesNoripple_insert: inserted duration in whole frames at fps.
idempotency_keyNoOptional client-chosen key (1-128 chars of A-Z a-z 0-9 . _ : -) for this intended edit. Pass a fresh key per edit and reuse it only when retrying that same edit, for example after a client-side timeout. A repeat with the same tool, key and arguments is not run again: while the first call is running it fails with IDEMPOTENCY_IN_PROGRESS (poll get_last_operations); after it finished it returns the original outcome marked replayed. A definite failure with nothing applied (receipt outcome not_applied) may be retried with the same key. Reusing a key with different arguments fails with IDEMPOTENCY_KEY_REUSED. Scoped to this MCP session (the stdio server process, or the HTTP server process when Streamable HTTP is stateless per request) and held in memory only (200 keys, 1 hour); it does not survive a restart or reconnect. Read-only invocations are never deduplicated.
straddle_policyNoripple_insert: a cue spanning at_seconds is split into two cues around the gap (split, default) or stretched across it (extend).
duration_secondsNoripple_insert: inserted duration in seconds. Use exactly one of duration_seconds or duration_frames.
expected_cep_targetNoOptional reviewed CEP sequence/clip identity and exact tick ranges. Checked before every generated command; UXP refuses this CEP-only guard.
expected_project_pathNoOptional absolute saved-project path. Every generated CEP command refuses before its body when the active project differs or is unsaved. UXP commands refuse this CEP-only guard; local-only tools do not inspect Premiere. Omit to keep existing behavior.
approved_workspace_pathNoAbsolute existing directory that must contain input_path and output_path. Required when either path is given.

Output Schema

NameRequiredDescriptionDefault
okYesWhether the tool completed successfully.
dataNoTool-specific result data when ok is true; on failure, diagnostic detail when the tool provides it.
toolYesThe registered MCP tool name.
errorNoFailure detail when ok is false.
receiptNoVersioned common mutation receipt; success never implies rendered verification.
idempotencyNoPresent when idempotency_key deduplicated this call: replayed is true when the original outcome was returned instead of running again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.30.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare a non-read-only, non-destructive local operation, and the description adds essential behavior beyond them: it is local-only, never changes Premiere, preserves VTT header/NOTE/STYLE, cue settings, and karaoke stamps, and renumbers SRT. The remaining behavioral details, such as output-path overwrite prevention and idempotency handling, are carried by the schema rather than the description.

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 front-loaded: it states the core action first, then the ripple-edit rationale, supported operations, preservation behavior, and local-only workflow. Every sentence carries useful selection or operational information, with no redundant restatement of the tool title.

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 complex 24-parameter caption-retiming tool with a full output schema, the description covers the key agent-facing concerns: purpose, operation set, preservation semantics, local-only scope, and the required follow-up workflow. Return values are rightly left to the output schema, and parameter constraints are fully documented in the schema.

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 description coverage is 100%, so the schema already documents all 24 parameters thoroughly, including operation-specific fields and constraints. The description adds the operation names and workflow context but does not provide syntax or per-parameter meaning beyond what the schema supplies, so the baseline of 3 is appropriate.

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: retime a local SRT/VTT file after ripple edits. It explicitly lists the four operations, which lets an agent distinguish it from Premiere-side caption tools and from the ripple tools it complements.

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?

It states the triggering condition after ripple edits and explains why the tool is needed: Premiere captions do not follow ripple_remove_timeline_ranges or insert_from_source. It also gives the downstream workflow, re-import via create_caption_track and reapply styling with get_caption_style_guidance, so the agent knows when and where this tool fits.

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