Skip to main content
Glama
leancoderkavy

Premiere Pro MCP Server

Retime Caption File

retime_caption_file

Retimes local SRT/VTT caption files after ripple edits to keep captions aligned when Premiere captions do not follow ripple removals or inserts.

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).

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 one HTTP session) 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. Addedv1.25.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only say readOnly=false, destructive=false, idempotent=false, openWorld=false, so the description adds real value: it declares 'never changes Premiere' (local-only scope), discloses what is preserved (VTT header/NOTE/STYLE, cue settings, karaoke stamps, SRT renumbering), and prescribes the re-import path. It does not mention write-side safety beyond that, but the schema's output_path 'never overwritten' rule covers the destructive surface. No contradiction with annotations.

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 compact paragraph that leads with the verb+resource, then the motivating constraint, then the operation list, then the preservation guarantees and handoff. Every clause carries information; none restates the title.

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

Completeness4/5

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

With 24 parameters, a nested schema, and an output schema, the description correctly focuses on scope, side effects, and workflow rather than return values. It does not address the file-vs-inline output choice or the idempotency semantics, but those are fully documented in the schema. Adequate for a tool of this 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 description coverage is 100% and per-parameter descriptions already tie each parameter to its operation (e.g. from_seconds→shift, ranges→ripple_remove_ranges), so the description only needs to match that baseline. Its contribution is naming the four operation modes, which the schema enum already lists with an equally terse description. Nothing extra on parameter interaction is added beyond what is structured.

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?

States a specific verb and resource ('Retime a local SRT/VTT file after ripple edits') and immediately separates itself from Premiere-side caption behavior, which is the exact confusion an agent would have given the many caption/timeline siblings. Enumerating the four operations (shift, ripple_remove_ranges, ripple_insert, edit_cue) makes the scope concrete.

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?

Gives the trigger condition ('after ripple edits') plus the reason the tool exists ('Premiere captions do not follow ripple_remove_timeline_ranges or insert_from_source'), and names the follow-up siblings (create_caption_track, get_caption_style_guidance). The agent knows when to use this and what to do next without inference.

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