Premiere Pro MCP Server

Plan Music Remix

plan_music_remix

Read-onlyIdempotent

Plan deterministic music shortening from a measured beat grid while protecting intro, outro, and crossfade handles. Returns exact segments and nearest-beat error for audible review before editing.

Instructions

Plan deterministic music shortening from an approved measured beat grid, protected intro/outro and crossfade handles. Returns exact segments and nearest-beat error for audible review. No DSP render or native Premiere Remix control.

Input Schema

Name	Required	Description
`plan`	Yes	Strict remix input: beats_ticks, source_duration_ticks, target_duration_ticks, protected_intro_ticks, protected_outro_ticks, optionalcrossfade_ticks, signal_classification music/silence/noise.
`expected_cep_target`	No	Optional reviewed CEP sequence/clip identity and exact tick ranges. Checked before every generated command; UXP refuses this CEP-only guard.
`expected_project_path`	No	Optional 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

Name	Required	Description
`ok`	Yes	Whether the tool completed successfully.
`data`	No	Tool-specific result data when ok is true; on failure, diagnostic detail when the tool provides it.
`tool`	Yes	The registered MCP tool name.
`error`	No	Failure detail when ok is false.
`receipt`	No	Versioned common mutation receipt; success never implies rendered verification.
`idempotency`	No	Present 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.

Changed1 schema field changedv1.25.0Oct 24, 2026

addedOutput schema / properties / idempotency

Added value: +{
+  "additionalProperties": true,
+  "description": "Present when idempotency_key deduplicated this call: replayed is true when the original outcome was returned instead of running again.",
+  "type": "object"
+}

Addedv1.24.0Oct 12, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description reinforces the planning-only nature by explicitly disclaiming DSP rendering and native Premiere Remix control. It adds genuine behavioral context by stating the output is exact segments plus a nearest-beat error intended for audible review, which tells the agent this is a verifiable, human-checkable plan rather than a mutation.

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 sentences, none padded: the action and inputs come first, the return contract second, and the capability exclusion last. Every sentence carries distinct information and there is no restatement of the title or name.

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 read-only planning tool with an output schema and a fully documented nested input, the description covers the essential behavior and its boundaries. What remains unstated is how the plan is consumed downstream (which apply/execution tool takes these segments) and what makes a beat grid 'approved', leaving a small integration 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 nested plan fields (beats_ticks, protected_intro_ticks, optionalcrossfade_ticks, signal_classification) are already documented. The description echoes those concepts in prose but adds no format, unit, or constraint detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Plan') plus the exact resource ('deterministic music shortening') and enumerates the inputs it consumes: an approved measured beat grid, protected intro/outro, and crossfade handles. The final clause distinguishes it from a renderer, so an agent can tell it apart from execution tools like speed_change or apply_edit_plan, though no sibling is named directly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'From an approved measured beat grid' implies a prerequisite (a prior, reviewed beat-detection step) without naming detect_beats or the approval workflow. The 'No DSP render or native Premiere Remix control' line usefully scopes when the tool does not apply, but it stops short of routing the agent to whatever tool actually applies the plan.

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

Deploy Server