Premiere Pro MCP Server

Add To Timeline

add_to_timeline

Insert a project item at a specified timeline position, optionally rippling sync-locked or target tracks and razor-splitting a spanning clip to preserve its tail when possible.

Instructions

Insert a project item at a timeline position. Experimental: if a target clip spans that point, QE razors it before insertion to attempt to preserve its tail; both target and sync-locked track changes are read back. A host may still displace a tail, in which case the edit is reported as committed_unverified. Pass scope 'target_tracks' to ripple only the named pair (this will desync other tracks).

Input Schema

TableJSON Schema

Name	Required	Description
`scope`	No	Which tracks shift: 'sync_locked' (default) matches Premiere's insert; 'target_tracks' ripples only the named pair and WILL desync other tracks.
`item_id`	Yes	Node ID or name of the project item to add
`track_index`	No	Video track index (0-based, default: 0)
`start_seconds`	No	Start time in seconds on the timeline (default: 0)
`audio_track_index`	No	Audio track index for the audio portion (default: 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; on failure, diagnostic detail when the tool provides it.
`tool`	Yes	The registered MCP tool name.
`error`	No	Failure detail when ok is false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.18.6Sep 30, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / properties / data / description

Previous value: -"Tool-specific result data when ok is true."New value: +"Tool-specific result data when ok is true; on failure, diagnostic detail when the tool provides it."

Changed1 schema field changedv1.16.1Sep 18, 2026

addedInput schema / properties / scope

Added value: +{
+  "description": "Which tracks shift: 'sync_locked' (default) matches Premiere's insert; 'target_tracks' ripples only the named pair and WILL desync other tracks.",
+  "enum": [
+    "sync_locked",
+    "target_tracks"
+  ],
+  "type": "string"
+}

Changed2 schema fields changedv1.14.4Aug 29, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "data": {
+      "description": "Tool-specific result data when ok is true."
+    },
+    "error": {
+      "description": "Failure detail when ok is false.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "Whether the tool completed successfully.",
+      "type": "boolean"
+    },
+    "tool": {
+      "description": "The registered MCP tool name.",
+      "minLength": 1,
+      "type": "string"
+    }
+  },
+  "required": [
+    "ok",
+    "tool"
+  ],
+  "type": "object"
+}

Changed1 schema field changedv1.4.0Jul 27, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
First observedv1.1.1May 28, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Goes well beyond the annotations, disclosing that QE razors a spanning clip, that tail preservation is only an attempt, that the result may be reported as committed_unverified, and that scope 'target_tracks' desyncs other tracks. This is exactly the kind of side-effect/auth/verification context that annotations (readOnly=false, destructive=false, idempotent=false) cannot carry. Note mild tension: the razor/desync side effects sit close to the line of destructiveHint=false, but since no data is deleted the annotations are not formally contradicted.

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?

Front-loaded with the core action, then caveats in order of importance. Some experimental framing ("attempt to preserve its tail", committed_unverified mechanics) is dense but each clause conveys a distinct behavioral risk, so little is wasted.

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?

With annotations present and an output schema covering the committed_unverified return, the description supplies the missing behavioral context (razoring, tail displacement, desync tradeoff). Only a brief note on sibling routing is absent, which is a minor 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 coverage is 100% and each parameter is already documented, including the scope enum with its desync warning. The description's scope note largely restates that, so it adds little beyond the schema; a baseline 3 is appropriate.

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+resource ("Insert a project item at a timeline position"), and adds experimental QE razor/tail detail that distinguishes it from plain inserts. It does not explicitly differentiate from nearby siblings like batch_add_to_timeline or insert_from_source, but the purpose is unmistakable.

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?

Gives one conditional ("Pass scope 'target_tracks' to ripple only the named pair") but never states when to prefer this over batch_add_to_timeline, insert_from_source, or overwrite_from_source. Usage is implied rather than routed.

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

Deploy Server