Premiere Pro MCP Server

Audit Project Structure

audit_project_structure

Audits the Project panel against layout rules and reports violations by node ID. Read-only by default; with apply it creates missing bins and moves planned items, verifying each move.

Instructions

Audit the Project panel against explicit layout rules (allowed root names, extension-to-bin placement, a sequences bin, maximum bin depth, empty bins) and report violations by node ID. Read-only by default (inspect authority): walks up to 5000 items, reports truncation, and returns at most 200 proposed moves plus a plan_token bound to the project, rules, and those exact moves. With apply: true (edit authority) it requires that plan_token, re-reads the project and refuses if the plan changed, the walk was truncated, or any target path is ambiguous (two bins with one name at a level). It then creates missing target bins and moves only the planned items, reading back each item's parent bin; outcome is verified only when every move is verified, otherwise partial or failed with per-item details. It never deletes, renames, or moves bins; root-name, depth, and empty-bin findings are report-only.

Input Schema

Name	Required	Description
`apply`	No	false (default) audits without changing Premiere. true creates missing target bins and moves the planned items; requires plan_token and the edit capability.
`rules`	Yes	Layout rules; at least one must be set. Unknown keys are rejected.
`plan_token`	No	Required when apply is true: the planToken returned by the audit with the same rules. Apply refuses if the project's current plan no longer matches it.
`idempotency_key`	No	Optional 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.
`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.

Addedv1.25.0Oct 24, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The description adds substantial behavior beyond the annotations: the 5000-item walk, truncation reporting, 200-move cap, plan_token binding, re-read and refusal conditions, creation of missing target bins, read-back verification, and partial/failed outcomes. It also explicitly says it never deletes, renames, or moves bins and that some findings are report-only.

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?

Purpose and scope are front-loaded, then the default read-only path and the guarded apply path follow in logical order. Although dense, every clause conveys an operational constraint needed for safe invocation, with no boilerplate.

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 a complex audit-and-optional-mutation tool with nested rules, annotations, and an output schema, the description covers the decision points, safety behavior, limits, and failure handling an agent needs. Return-value details can be left to the output schema.

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%, and the schema already documents apply, rules, plan_token, idempotency_key, and expected identity guards in detail. The prose reinforces plan_token binding and apply requirements but provides limited parameter-level meaning beyond the schema.

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 gives a specific verb and resource: auditing the Project panel against named layout rules and reporting violations by node ID. It distinguishes itself from sibling project-listing and bin-manipulation tools by being a rules-based audit/plan/apply operation.

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?

It clearly explains the two modes: read-only audit by default, and apply:true only with a plan_token and edit authority. It states refusal conditions and report-only findings, but it does not explicitly route the agent to sibling alternatives such as move_item_to_bin or create_bin for manual edits.

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

Deploy Server