Skip to main content
Glama
leancoderkavy

Premiere Pro MCP Server

Create Source Freeze Frame

create_source_freeze_frame

Creates a freeze-frame image from a source project item at a specified source-media time, saves it to a new image path, and can place it on an empty video track range.

Instructions

Create a freeze frame from a project item at a SOURCE-media time (not a sequence time; for a sequence time use freeze_frame). Decodes the frame with ffmpeg from the item's media file (requires ffmpeg/ffprobe on PATH; no Source Monitor or QE state is used), refuses to overwrite an existing output file, imports the still and sets its Out mark to duration_seconds. Optional place puts it on an empty range of one video track (refuses an occupied or locked range rather than overwriting); optional zoom (requires place) adds Motion Scale and optional Position keyframes at the clip's first and last frame for a punch-in. Every step is read back; partial success reports which steps were committed but not verified. Refuses before any change when the item has no readable local media, the time is past the media end, or the item's interpreted frame rate differs from the file's.

Input Schema

NameRequiredDescriptionDefault
zoomNoOptional punch-in keyframes on the placed clip's Motion effect (requires place). Scale is percent as Premiere reports it for the placed still; Position is in sequence pixels.
placeNoOptional placement on the active sequence. The range must be empty; nothing is overwritten.
output_pathYesNew .png, .jpg or .jpeg path for the frame. Must not exist; its folder must exist.
source_item_idYesNode ID (preferred) or exact name of the source video project item.
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.
duration_secondsNoLength of the still in seconds, written as its Out mark and read back (default 2, at most 3600).
expected_cep_targetNoOptional reviewed CEP sequence/clip identity and exact tick ranges. Checked before every generated command; UXP refuses this CEP-only guard.
source_time_secondsYesSeconds from the first frame of the source media (media time zero, not its start timecode and not its In mark). Snapped down to the item's frame grid.
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.

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.9/5.0
Behavior5/5

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

The description discloses many behaviors beyond the annotations: ffmpeg decoding, refusal to overwrite, refusal to place on occupied or locked ranges, validation before any change, read-back verification, and partial-success reporting. It does not contradict the annotations and adds substantial operational context.

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: purpose, alternative tool, prerequisites, overwrite behavior, optional placement/zoom, and refusal conditions. Every sentence carries operational information, and none is filler.

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?

Given the complexity, 9 parameters, annotations, and an output schema, the description covers the essential agent-facing concerns: source-time semantics, prerequisites, safety/refusal behavior, optional placement and zoom, and partial-success outcomes. Remaining parameter details are well covered by the schema.

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 coverage is 100%, so the schema already documents most parameter details. The description still adds useful cross-parameter semantics, notably that source_time_seconds is media time zero rather than sequence time or In mark, that zoom requires place, and that duration_seconds becomes the clip Out mark.

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 starts with a specific verb and resource: it creates a freeze frame from a project item. It immediately distinguishes source-media time from sequence time and explicitly routes sequence-time use to the sibling tool freeze_frame.

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 explicitly states when to use this tool versus the alternative freeze_frame, and it also names the operational context: ffmpeg/ffprobe on PATH, no Source Monitor or QE state. This is unusually clear routing guidance.

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