Skip to main content
Glama

cue_set

DestructiveIdempotent

Set or clear a crossfade or scale punch on one picture cue or across every cue. Adjust dissolve duration, punch zoom, and easing, with plan mode to preview.

Instructions

Set or clear a crossfade or a scale punch on one picture cue, or on every cue.

Address one cue as cue_rm does, or pass every for all of them: "a scale punch per cut" is one call. dissolve crossfades into the cue (0 clears); punch scales the shot about the canvas centre from its cut (1 clears). A field not given is left alone. A punch and a crossfade on one cue are refused: the crossfade removes the cut the punch is on.

Checked against the picture plan before writing, and each crossfade is echoed: from: "outgoing" means the incoming clip had nothing before its in-point, so the fade starts on the cue's word rather than ending on it — pin the cue later into its clip (src_start) to move it. The first shot has nothing to cross from and is reported in crossfades_skipped. A vignette is not this: it is an overlay, card_new from the vignette template. plan writes nothing; undo reverses the call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoThe project directory to act on. Omit it — the usual case — when this server is bound to a project (started as `proofcut -C DIR mcp`, or inside a project; `ping` says which): it then resolves to that one bound project, a relative path resolves against it, and a path outside it is refused by name. Unbound, `path` is the whole address and omitting it refuses rather than guessing.
planNoResolve the whole call and report what it would do, writing nothing. Prefer it over doing the thing and undoing it.
afterNoA forward cursor over a phrase's matches: any match at or before this word index is skipped. -1, the default, means from the start.
eventNoThe event the cue sits on, spelled as `cue_add` was given it.
everyNoSet every cue (of `clip_id`, if given) in one call: a punch or crossfade per cut.
punchNoA scale punch from the cut, about the canvas centre: 1.1 zooms in 10%. Not with a dissolve on the same cue. 1 clears it.
phraseNoAddress the cue by wording; it resolves to its first word, as `cue_add` placed it.
clip_idNoThe transcript the cue is addressed against. With `every`, narrows to that clip's cues; omitted with `every`, every cue.
dissolveNoCrossfade into this cue over this many seconds: the incoming shot's frames before its in-point fade in, reaching the shot on the cue's word. Where the clip has none (an unpinned first use), the outgoing shot fades out from the word instead. 0 clears it.
occurrenceNoDisambiguate a phrase by count when it matches more than once, **1-based** in transcript order among the matches after `after`: 1 is the first, 2 the second. Unset, an ambiguous phrase is refused — listing every candidate's range and text — rather than guessed at.
punch_easeNoThe punch's curve. Default ease-out.
punch_modeNo`in` (default) zooms to `punch` and holds for the shot; `settle` starts there and eases back.
word_indexNoThe word the cue sits on. Give this, `phrase` or `event`, or pass `every`.
dissolve_easeNoThe crossfade's curve: linear (the default), ease, ease-in or ease-out.
punch_secondsNoHow long the punch moves. Default 0.2.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.43.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations mark the tool as destructive and idempotent, but the description adds substantial behavioral detail: the call is checked against the picture plan before writing, punch and crossfade on the same cue are refused, the first shot is reported in `crossfades_skipped`, and `from: "outgoing"` explains fade-direction edge cases. This goes well beyond what annotations alone provide.

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?

The description is long but the tool is genuinely complex, and the core operation is front-loaded in the first sentence. It is organized into overview, constraints, and edge cases, though a few details such as '0 clears' and '1 clears' duplicate the schema descriptions.

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

Completeness5/5

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

For a 15-parameter mutation tool with an output schema, the description covers the essential failure modes, edge cases, and alternatives. It informs the agent about plan-checking, skipped crossfades, partial updates, the punch/dissolve conflict, and the plan/undo escape hatches, so nothing critical is missing.

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 100% with detailed per-parameter descriptions, so the baseline is 3. The description adds valuable cross-cutting semantics: 'A field not given is left alone', the relationship to cue_rm-style addressing, and how `every` applies a punch or crossfade per cut. These ties between the 15 optional parameters are not fully captured in the 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?

The description opens with a specific verb and resource: 'Set or clear a crossfade or a scale punch on one picture cue, or on every cue.' It also distinguishes itself from related tools by referencing how cue_rm addresses cues and explicitly says a vignette is not this, directing to card_new instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use and when-not-to-use guidance: address one cue as cue_rm does or pass `every` for all cues, and use card_new for vignettes rather than this tool. It also clarifies that `plan` writes nothing and `undo` reverses the call, giving the agent alternative workflows.

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