Skip to main content
Glama

reframe

DestructiveIdempotent

Set or read which part of each clip survives into the frame, adjusting crops per clip or shot so the canvas fills correctly when subjects are off-center.

Instructions

Read or set which part of each clip survives into the frame.

What makes a swapped canvas fill the frame instead of pillarboxing it. The default is a centre crop, which is wrong whenever the subject is not centred. Call with no clip_id to read the crops in force for every clip; clips[].windows is each clip's whole series.

A rect is a floor rather than a frame: grown to the canvas's shape, never shrunk into it, stored as asked and refit whenever the canvas moves; the reply gives both asked and the crop it became. src_start makes it a per-shot window, addressed on the source's own clock, so every placement of the clip picks it up. pane makes that window a stacked split for a shot one crop cannot hold; interp slides into it rather than stepping; fill="blur" draws it whole over a blurred copy of itself instead of cropping, for a shot every crop loses something from.

reset drops overrides (one clip, one window, or all); plan resolves without writing. Nothing here analyses the picture — reframe_detect proposes crops and writes through this tool. Judge a window on reframe_sheet, never on a watch: a wrong one reads as framing in motion.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fillNo`blur` draws this window **blur-filled**: the whole source contained in the frame, over a blurred, darkened copy of the same moment covering the canvas. For a shot every crop loses something from and no split divides. Takes no `rect`, `pane` or `interp`; set `src_start` for one shot.
paneNoA second rect making this window a **stacked split**: `rect` on top, `pane` below, each about twice the width one 9:16 window gets. For the shot one window cannot frame. Both are grown to the full source height — nothing masks a pane, so a shorter crop scales into the other half at exit 0.
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.
rectNo`X,Y,W,H` in that clip's **own source pixels** — the region kept. An override is a floor rather than a frame: a rect that is not the canvas's shape is grown to it, so nothing named is pushed off screen, and the reply gives both `asked` and the `crop` it became.
resetNoWith `clip_id`, drop that clip's overrides; with `src_start` as well, only the window there. Alone, drop every override.
interpNoSlide into this window from whatever governed before it instead of stepping to it. It needs `src_start` past 0 — there is nothing before the head of the source to slide from — and cannot be combined with `pane`.
clip_idNoThe clip to read or frame. Omit it to read the crops in force for every clip, including how much of each is kept.
src_startNoFrame a **shot** rather than a clip: seconds into that clip's own source, the rect holding from there until the next window. Because the address is the source's own clock, a clip used seven times picks up the right window at each placement. Omitted, it is the window from the head of the file.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed28 schema fields changedv0.25.0
    • removedInput schema / properties / clip_id / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / clip_id / description
      Added value: +"The clip to read or frame. Omit it to read the crops in force for every clip, including how much of each is kept."
    • removedInput schema / properties / clip_id / title
      Removed value: -"Clip Id"
    • addedInput schema / properties / clip_id / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • addedInput schema / properties / fill
      Added value: +{
      +  "default": null,
      +  "description": "`blur` draws this window **blur-filled**: the whole source contained in the frame, over a blurred, darkened copy of the same moment covering the canvas. For a shot every crop loses something from and no split divides. Takes no `rect`, `pane` or `interp`; set `src_start` for one shot.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / interp / description
      Added value: +"Slide into this window from whatever governed before it instead of stepping to it. It needs `src_start` past 0 — there is nothing before the head of the source to slide from — and cannot be combined with `pane`."
    • removedInput schema / properties / interp / title
      Removed value: -"Interp"
    • removedInput schema / properties / pane / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / pane / description
      Added value: +"A second rect making this window a **stacked split**: `rect` on top, `pane` below, each about twice the width one 9:16 window gets. For the shot one window cannot frame. Both are grown to the full source height — nothing masks a pane, so a shorter crop scales into the other half at exit 0."
    • removedInput schema / properties / pane / title
      Removed value: -"Pane"
    • addedInput schema / properties / pane / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedInput schema / properties / path / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / path / description
      Added value: +"The 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."
    • removedInput schema / properties / path / title
      Removed value: -"Path"
    • addedInput schema / properties / path / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • addedInput schema / properties / plan / description
      Added value: +"Resolve the whole call and report what it would do, writing nothing. Prefer it over doing the thing and undoing it."
    • removedInput schema / properties / plan / title
      Removed value: -"Plan"
    • removedInput schema / properties / rect / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / rect / description
      Added value: +"`X,Y,W,H` in that clip's **own source pixels** — the region kept. An override is a floor rather than a frame: a rect that is not the canvas's shape is grown to it, so nothing named is pushed off screen, and the reply gives both `asked` and the `crop` it became."
    • removedInput schema / properties / rect / title
      Removed value: -"Rect"
    • addedInput schema / properties / rect / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • addedInput schema / properties / reset / description
      Added value: +"With `clip_id`, drop that clip's overrides; with `src_start` as well, only the window there. Alone, drop every override."
    • removedInput schema / properties / reset / title
      Removed value: -"Reset"
    • removedInput schema / properties / src_start / anyOf
      Removed value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / src_start / description
      Added value: +"Frame a **shot** rather than a clip: seconds into that clip's own source, the rect holding from there until the next window. Because the address is the source's own clock, a clip used seven times picks up the right window at each placement. Omitted, it is the window from the head of the file."
    • removedInput schema / properties / src_start / title
      Removed value: -"Src Start"
    • addedInput schema / properties / src_start / type
      Added value: +[
      +  "number",
      +  "null"
      +]
    • removedInput schema / title
      Removed value: -"reframeArguments"
  2. First observedv0.24.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=true, and the description is fully consistent with these (no contradiction). It adds rich behavioral context beyond annotations: the rect is 'a floor rather than a frame' that is grown to the canvas and never shrunk, the reply gives both 'asked' and the 'crop' it became, src_start addresses on the source's own clock so repeated clips pick up the right window, and pane details like 'nothing masks a pane'. This substantially exceeds what annotations alone convey.

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 information-dense — every sentence carries distinct semantic weight, from the core purpose to the key conceptual warning (centre crop is wrong for off-centre subjects) to per-parameter behaviors. It is front-loaded with the purpose and the most critical concept. It loses one point only because its density demands careful reading; it is thorough rather than concise.

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 9-parameter, 0-required, complex tool with an output schema, the description covers all operational modes (read, set, reset, plan), explains response format ('the reply gives both asked and the crop it became'), explains the clip-vs-shot distinction, addresses the path binding behavior, and names its complementary siblings. An agent has everything needed to invoke this tool correctly.

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%, so the baseline is 3, and the description clearly exceeds it. It adds meaning the schema cannot: the floor-vs-frame growth semantics for rect, why src_start matters for clips used multiple times, the stacking behavior for pane, and the interp constraint of needing src_start past 0. The description genuinely enriches parameter understanding rather than restating 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 precise verb+resource statement ('Read or set which part of each clip survives into the frame') and then explicitly differentiates itself from siblings: 'Nothing here analyses the picture — reframe_detect proposes crops and writes through this tool' and 'Judge a window on reframe_sheet'. This is unambiguous 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 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 guidance for every mode: call with no clip_id to read all crops, use src_start for per-shot windows, use pane for stacked splits, use fill='blur' when every crop loses something. It explicitly names the analysis sibling (reframe_detect) and the judging tool (reframe_sheet), with the instruction 'never on a watch'. Nothing is left to inference.

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