Premiere Pro MCP Server

Preview Extended Edit Plan

preview_extended_edit_plan

Read-onlyIdempotent

Preview and validate up to 100 bound CEP edit steps—trim, split, move, enable, effect, and keyframe actions—before issuing tokens, refusing unsupported operations or mismatched identities.

Instructions

Preview up to100 distinct bound CEP targets for supported trim, experimental QE split, same-track move, enable, scalar effect and keyframe steps. All targets and descriptor identities validate before token issuance; unsupported links/retiming/unknown source handles refuse. Requires exact saved project path and active sequence. No mutation or atomicity claim.

Input Schema

Name	Required	Description
`plan`	Yes	Strict compound plan; one operation per host clip, canonical state binds identities and source handles.
`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.9/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, so safety is covered; the description adds real value beyond that by disclosing the validate-before-token ordering, the refusal conditions, and the honest 'no mutation or atomicity claim' caveat. It could have said whether the preview mutates session state or how long a token stays valid, which would complete the picture.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense, front-loaded sentences with no filler; supported routes and refusal cases come before prerequisites. Minor flaws: the typo 'up to100' and heavy jargon ('descriptor identities', 'token issuance') that assumes domain knowledge.

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?

Covers purpose, prerequisites, refusal behavior and supported operations for a nested 3-parameter tool, and an output schema exists so return values need no description. What is missing is the workflow link to apply_extended_edit_plan and any statement about how the issued token is used.

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% with only 3 parameters, so the schema carries most of the load and baseline 3 applies. The description adds only marginal semantics: that project_path must point to an exact saved project and that the plan is capped at 100 targets, without explaining the snapshot or expected_cep_target guard objects.

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?

Names a specific verb (Preview) and resource (extended edit plan) and enumerates exactly which step routes are supported: trim, QE split, same-track move, enable, scalar effect, keyframe. It is clear what the tool does, but it never distinguishes itself from the sibling preview_edit_plan, so an agent cannot tell which preview tool to pick without opening both schemas.

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?

Gives concrete preconditions (exact saved project path, active sequence) and negative cases that will refuse (unsupported links, retiming, unknown source handles), which is strong selection guidance. It stops short of naming the follow-up tool that consumes the issued token (apply_extended_edit_plan) or stating when to prefer the simpler preview_edit_plan.

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

Deploy Server