Premiere Pro MCP Server

Plan Active Speaker Reframe

plan_active_speaker_reframe

Read-onlyIdempotent

Plan reframes that follow the active speaker or static stacked/split layouts from a word timeline and speaker regions. Outputs keyframes and apply routes without altering Premiere.

Instructions

Plan an active-speaker vertical reframe (Motion Scale/Position keyframes that follow whoever is talking) or a static stacked/split layout from a word timeline and static speaker regions. Returns framings, switches, keyframes, and apply routes. Local-only; never changes Premiere.

Input Schema

TableJSON Schema

Name	Required	Description
`layout`	No	auto (default) picks active_speaker for 3+ speakers or a region wider than 0.6, stacked for exactly 2 speakers.
`headroom`	No	Fraction of the crop height reserved above the region top; defaults to 0.12.
`frame_rate`	No	Sequence frame rate used to snap times to frames; defaults to 30.
`ease_frames`	No	Frames to ease each switch with bezier keyframes; 0 (default) emits hold keyframes (hard cuts).
`source_frame`	Yes	Source clip frame size in pixels, e.g. 1920x1080 or 3840x2160.
`target_frame`	No	Target sequence frame size in pixels; defaults to 1080x1920.
`word_timeline`	Yes	Caller-supplied word-timed transcript for one Premiere source item. Words must be ordered by start time and bound to the transcript revision returned by get_clip_transcript_uxp.
`speaker_regions`	Yes	Normalized (0..1) face/body rectangle of every speaker that appears, measured in the source frame.
`min_hold_seconds`	No	Never switch faster than this; shorter turns are absorbed. Defaults to 1.5.
`switch_lead_seconds`	No	Switch this long before the speaker starts; defaults to 0.15.
`base_video_track_index`	No	Video track holding the source clip in the target sequence; defaults to 0.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Whether the tool completed successfully.
`data`	No	Tool-specific result data when ok is true.
`tool`	Yes	The registered MCP tool name.
`error`	No	Failure detail when ok is false.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.14.9Sep 8, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description explicitly states 'Local-only; never changes Premiere,' which is an unusually clear behavioral guarantee. It also discloses the nature of the output (framings, switches, keyframes, apply routes) without contradicting any annotation.

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?

Three concise sentences front-load the purpose, then state the return contents and the safety guarantee. There is no filler or repetition of schema details; every sentence earns its place.

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?

For a complex planning tool with 11 parameters and an output schema, the description covers the essential context: what it plans, what it returns, and its non-destructive local behavior. It does not mention how the returned apply routes should be consumed, but the output schema and sibling apply tools cover that gap.

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 input schema already documents every parameter in detail. The description maps high-level inputs ('word timeline', 'static speaker regions') to the required parameters but does not add meaning beyond what the schema already provides. Baseline 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 names a specific verb ('Plan'), a concrete resource (active-speaker vertical reframe, stacked/split layout), and the exact inputs (word timeline and static speaker regions). It also clearly separates this from apply tools by stating it only returns framings, switches, keyframes, and apply routes.

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 clearly conveys that this is a planning-only tool for generating reframe/keyframe plans from transcript and speaker-region data. It does not explicitly name alternative siblings like apply_edit_plan or plan_emphasis_zoom_keyframes, but the 'never changes Premiere' line provides a strong when-to-use/when-not-to-use signal.

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

Deploy Server