Premiere Pro MCP Server

Add Marker

add_marker

Places a marker on the active sequence or clip at a given time, with optional name, comments, color, and duration, then returns the marker's details.

Instructions

Add a marker to the active sequence or a clip and read its name, comments, color and duration back. EXPERIMENTAL (QE DOM): the receipt reports undoStackIndex movement, which does not prove QE can reverse the marker. Every marker attempt protects an engine undo boundary; undoTracked:false means the marker did not observably advance the QE index.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Name/label for the marker
`color`	No	Marker color index (0=Green, 1=Red, 2=Purple, 3=Orange, 4=Yellow, 5=White, 6=Blue, 7=Cyan)
`node_id`	No	Optional clip node ID to add the marker to that clip instead of the sequence. Premiere 25.2.3 timeline clips have no marker collection, so this refuses there and names the source time to use with add_marker_to_project_item.
`comments`	No	Comments for the marker
`time_seconds`	Yes	Time position in seconds for the marker
`duration_seconds`	No	Duration of the marker in seconds (0 for point marker)

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.

Changed1 schema field changedv1.19.0Oct 3, 2026

changedInput schema / properties / node_id / description

Previous value: -"Optional clip node ID to add marker to clip instead of sequence"New value: +"Optional clip node ID to add the marker to that clip instead of the sequence. Premiere 25.2.3 timeline clips have no marker collection, so this refuses there and names the source time to use with add_marker_to_project_item."

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."

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.6/5.0

Behavior4/5

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

Annotations already declare readOnly=false, idempotent=false, destructive=false, but the description adds real behavioral context beyond them: the QE DOM experimental status, that undoStackIndex movement does not prove reversibility, that each attempt protects an engine undo boundary, and what undoTracked:false means. This is valuable disclosure, though the jargon is dense.

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

Conciseness3/5

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

The purpose is front-loaded and correct, but the experimental/undo caveat is verbose and uses unexplained internal terms (QE DOM, undoStackIndex, undoTracked) that consume space without clearly helping an agent decide or act. Some of it could be tightened.

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 an output schema present, the return values need not be explained, and the safety profile is covered by annotations. The description fills the remaining gap by flagging the experimental nature and undo-tracking caveat, leaving only minor ambiguity about clip vs sequence routing.

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 all six parameters are already documented with types, enum-like color values, and the node_id alternative. The description merely restates the read-back fields (name, comments, color, duration) and adds no syntax or format detail beyond the schema.

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 and resource ('Add a marker') plus its two targets ('active sequence or a clip'), and the read-back of name/comments/color/duration. It does not explicitly name sibling alternatives like add_marker_to_project_item or add_markers_batch, so it stops short of full sibling differentiation.

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?

The body gives no explicit when-to-use guidance; the route to clips is implied through the node_id parameter rather than stated in the description. The alternative tool (add_marker_to_project_item) is named only inside the schema, not in the description itself.

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

Deploy Server