Skip to main content
Glama
Miinwan

MCP Premiere Pro

by Miinwan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

rough_cut_by_cues

Create a rough cut sequence by detecting on-set slate cues in each raw clip's audio, arranging every take back to back with markers for dialogue and confidence.

Instructions

Rough-cut a folder of raw footage by the slate cues called on set ("3, 2, 1", "action", "diễn", "đi" to start; "cắt", "cut", "ok", "được rồi" to end), heard by Whisper in each file's own audio through the MCP Adobe media engine. One source can give many takes. Builds a NEW sequence with every take back to back, a→z by file then time, so the editor can reorder them; each take gets a sequence marker (take id, cue heard, dialogue, confidence) and low-confidence takes a red marker. Files with no cue are kept whole (unless dropNoCue). Analysis is cached next to the footage (.media/); a long first run returns status "running" — call again with the same arguments to pick up the result.

Input Schema

NameRequiredDescriptionDefault
binNoOnly the clips in this project bin
fastNoRun the media engine in fast mode instead of the quiet background mode (default true: the user is waiting)
frameNoSequence frame: "1920x1080" (default), "9:16", "1:1", "4:5" or "<w>x<h>". The media engine fits each take (4K → 50 %, other ratios fill the frame centred on faces) and the scale/position go into Motion
modelNoWhisper model (default large-v3)
dropNoCueNoLeave out files with no cue (B-roll) instead of keeping them whole (default false)
gapSecondsNoGap between takes in seconds (default 0)
analyzeOnlyNoOnly run the analysis and return the takes, do not touch Premiere
waitSecondsNoHow long to wait for the media engine in this call before returning "running" (default 45)
sequenceNameNoNew sequence name (default "Rough cut <folder>")
sourceFolderNoFootage folder. Default: the clips kept in the project after the junk was filtered out (with the proxies attached in Premiere); with a folder, only the project clips inside it, or the whole folder when none are imported
allowOriginalNoClips without a proxy: read the original file instead of stopping (heavier on the machine)
lowConfidenceNoTakes below this confidence get a red marker (default 0.6)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4.3/5.0
Behavior5/5

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

No annotations, so the description carries the full burden and does so richly: it builds a new sequence (non-destructive), adds sequence markers with take id/cue/dialogue/confidence, red markers for low confidence, caches analysis to .media/, and explains the async 'running' status with the retry contract. This is exactly the operational context an agent needs.

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 and cue vocabulary before behavioral detail. Dense but nearly every clause carries real information; only the doubled 'one source can give many takes' remark is slightly redundant.

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?

For a 12-param, zero-required tool with no annotations or output schema, the description is remarkably complete: workflow, output artifacts, caching, and the async retry contract are all covered. Minor gap is it doesn't describe what the returned result payload looks like beyond 'running'.

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 the schema already documents all 12 parameters thoroughly, establishing a baseline of 3. The description reinforces a few knobs (dropNoCue, the caching tied to waitSeconds/running) but adds little beyond the already-complete 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?

A specific verb (rough-cut) applied to a specific resource (folder of raw footage) using a specific method (slate cues heard by Whisper). It also states the output (a NEW sequence of takes) and enumerates the cue vocabulary, so the agent knows exactly what this does and can distinguish it from scene/shot detection siblings.

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?

Clear real-world context: on-set slate cues, takes back-to-back a→z for later reordering, files with no cues kept whole unless dropNoCue. It doesn't explicitly name alternative tools (detect_scene_edits, find_shots, select_best_takes) or state exclusions, so it falls short of a 5.

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