Premiere Pro MCP Server

Preview Brand Spot

preview_brand_spot

Read-onlyIdempotent

Preview a brand-spot assembly from existing project items with an optional workspace-contained MOGRT overlay. Run local-only preview without importing MOGRT media.

Instructions

Preview a brand-spot assembly from existing project items with an optional workspace-contained MOGRT overlay. Preview is local-only; it does not read or import the MOGRT file.

Input Schema

TableJSON Schema

Name	Required	Description
`mogrt_path`	No	Optional absolute .mogrt path, which must be inside approved_workspace_path.
`sequence_id`	Yes	Exact ID of an existing empty destination sequence. It must be active at apply time.
`motion_style`	No	Scale-motion style for product and brand spots; defaults to alternate.
`asset_item_ids`	Yes	Exact existing project-item node IDs in playback order; external media paths are deliberately not imported by this workflow.
`transition_name`	No	Transition name; defaults to Cross Dissolve. Use none to disable transitions.
`audio_track_index`	No	Empty destination audio track index, default 0.
`title_track_index`	No	Empty title-overlay video track index, default 1 and distinct from video_track_index.
`video_track_index`	No	Empty destination video track index, default 0.
`title_start_seconds`	No	MOGRT start time in seconds, default 0.4.
`clip_duration_seconds`	No	Planned spacing between asset starts; defaults to 5 seconds for a motion demo and 4 seconds for spots.
`approved_workspace_path`	No	Operator-approved root containing mogrt_path; required whenever mogrt_path is supplied.
`transition_duration_seconds`	No	Transition duration, default 0.75 seconds for demos and 0.5 seconds for spots.

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.18.6Sep 30, 2026

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.14.9Sep 8, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
Addedv1.14.4Aug 29, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover safety (readOnlyHint=true, idempotentHint=true, destructiveHint=false), but the description adds a genuinely non-obvious trait: the supplied mogrt_path is not read or imported during preview, which matters because that parameter otherwise looks like a real file dependency. It stops short of describing what the preview returns.

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?

Two tightly written sentences with zero filler. The core action leads and the surprising caveat (local-only, MOGRT not read) follows immediately.

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, full schema coverage, and complete annotations, the description only needs to supply the behavioral surprise, which it does. Slightly incomplete on routing among the many preview_* siblings, but nothing needed to invoke the tool correctly is missing.

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 all 12 parameters documented in the schema, so the baseline is 3. The description only echoes the workspace-containment constraint on mogrt_path and adds no new syntax, defaults, or ordering semantics beyond what the schema already provides.

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 (preview) and resource (brand-spot assembly) plus its input basis (existing project items) and the optional MOGRT overlay. It is clearly distinct from most siblings, though it never names the closest ones (preview_product_spot, preview_motion_graphics_demo) to explain which preview variant applies.

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 description implies the use case (dry-run an assembly before applying) and gives one important boundary: preview is local-only and does not read or import the MOGRT file. However, it never states when to choose this over preview_product_spot, preview_motion_graphics_demo, or apply_spot_workflow_plan.

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

Deploy Server