Premiere Pro MCP Server

Plan Speaker Checkerboard

plan_speaker_checkerboard

Read-onlyIdempotent

Generate a speaker checkerboard plan from a word-timed transcript, returning frame-snapped segments, split points, and track assignments without altering the Premiere sequence.

Instructions

Plan a speaker checkerboard (each speaker's turns on their own video/audio track) from a caller-supplied word timeline. Returns frame-snapped segments, split points, track assignments, and the add_track/razor_all_tracks/move_clip_to_track routes. Local-only; never changes Premiere.

Input Schema

TableJSON Schema

Name	Required	Description
`frame_rate`	No	Sequence frame rate used to snap times to frames; defaults to 30.
`handle_frames`	No	Frames to pad each segment outward, clamped so adjacent turns never overlap; defaults to 2.
`speaker_order`	No	Optional speaker labels fixing track slot order; unlisted speakers append in first-appearance order.
`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.
`min_turn_seconds`	No	Interior turns shorter than this are absorbed into the surrounding speaker; defaults to 0.8.
`merge_gap_seconds`	No	Same-speaker words separated by at most this gap merge into one turn; defaults to 0.5.
`track_per_speaker`	No	true (default) assigns one track per speaker; false alternates consecutive segments between two tracks.
`base_audio_track_index`	No	Audio track holding the source clip; defaults to 0.
`base_video_track_index`	No	Video track holding the source clip; 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.5/5.0

Behavior5/5

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

The description explicitly states 'Local-only; never changes Premiere', directly disclosing the read-only, non-destructive behavior and reinforcing the readOnlyHint and destructiveHint annotations. It also frames the output as a plan with routes rather than direct edits, so the agent knows no timeline mutation occurs.

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?

Two sentences, front-loaded with the core purpose and immediately followed by output and side-effect clarity. No filler or redundant wording.

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 high complexity (nested objects, 9 parameters, output schema present), the description sufficiently states the input source, what is produced, and the key safety property. Since an output schema exists, detailed return-value description is unnecessary.

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?

All 9 parameters have full schema descriptions, so the description contributes little beyond the schema. The tool description mentions 'word timeline' and output concepts but does not add meaning to individual parameters; baseline 3 applies given 100% schema coverage.

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?

Description clearly states the verb 'Plan' and the specific object 'speaker checkerboard', defines what that means (each speaker's turns on their own track), and names the exact return elements: frame-snapped segments, split points, track assignments. It distinguishes itself from other plan_* tools by specifying the caller-supplied word timeline and the local-only nature.

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?

Provides clear context: use when you have a caller-supplied word timeline and need to plan a speaker checkerboard without modifying Premiere. It does not explicitly name alternatives or say when not to use it, but the scope is specific enough to guide tool selection.

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

Deploy Server