Skip to main content
Glama

pr_addMarkers

Adds sequence markers to Premiere Pro timelines at specified times for review points, chapters, or segments, with optional names, comments, durations, colors, and URLs.

Instructions

Premiere Pro: add sequence markers [{time, name?, comment?, duration?, color 0-7?, type comment|chapter|segmentation|weblink, url?}] — e.g. review points before cuts.

Input Schema

NameRequiredDescriptionDefault
markersYes
sequenceNoSequence name; omit for the active sequence.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is known. The description adds nothing beyond that on behavior — it doesn't say whether markers append or replace, whether the sequence must be active, or what is returned. Some value from the marker shape spec, but no behavioral disclosure.

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?

A single front-loaded line naming the app, the action, and the payload shape with zero filler. The bracketed field list is dense and slightly hard to scan, which keeps it just below top marks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and a mutation tool, the description should say what the call returns (created marker IDs, counts) and how it interacts with existing markers. The parameter shape is well covered, but the outcome and sequencing prerequisites are left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%, and the description fills part of the gap by enumerating marker fields and adding a constraint the schema omits: color range 0-7. It doesn't describe the 'sequence' parameter (deferred to the schema) or clarify duration units, but it substantially compensates for the coverage shortfall.

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?

Specific verb plus resource ('add sequence markers') with an inline shape spec for the marker objects and a concrete example use case. An agent can identify it distinctly from pr_deleteMarkers, pr_getMarkers, or the AE analog ae_addMarkers without opening the schema.

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 'e.g. review points before cuts' clause implies a usage context, but there is no explicit when-to-use versus alternatives (e.g. pr_addCaptions vs pr_addMarkers) and no exclusions or prerequisites such as requiring an open sequence.

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

Deploy Server

Other Tools