Skip to main content
Glama

reframe_sheet

DestructiveIdempotent

Review framing decisions by drawing each placement's window on its source frame, with split rows per crossed boundary and red rects. Use it to see what a crop leaves out, exposing misplacements that motion hides.

Instructions

Draw every placement's framing window on its own source frames.

A framing decision is unreviewable without this. The hand-framed teaser had 2 of its 15 windows wrong and neither was visible in motion — a badly-placed window reads as framing. Drawn on the whole source frame, what the window leaves out sits right beside it.

Every placement the render shows is walked window by window, the window in force drawn in red and labelled with its rect. A row is a window shown, not a placement: each placement is split at the boundaries it crosses, so a window covering a small slice of a long placement still gets a row. window on a row is the source address reframe --src-start takes; windows is how many the whole placement crosses. Stills come back under skipped — a card is re-authored, never cropped.

A tile is evidence about an instant, not an approval of the span. A static rect over a moving subject has a best moment and a sample can land on it; extremes draws where the subject is leftmost, median and rightmost instead, worst first, with worst_offset on the row to sort by.

A page of rows comes back as an image, six windows by default, at a width vision reads verbatim; row keeps its project-wide number on every page. per_page: null is the whole project as a PNG path, for a person.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
outNoWrite the image to this path as well, replacing whatever file is there. Unset, it goes to the project's own sheet cache and only the bytes come back.
pageNoWhich page of rows to draw, from 1. Unset, the first.
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.
momentsNoFractions of each window to draw tiles at, e.g. `[0.1, 0.5, 0.9]`. A tile is evidence about one instant while a rect is a claim about a stretch, so where the subject moves these decide what the sheet can see. Refused alongside `extremes`.
extremesNoDraw the subject's own leftmost and rightmost moments, worst first, instead of fixed fractions — the rect does not move inside a stretch, so that is where a static window is worst. Off by default: it costs the face detector and about half a second a probe. Read `worst_offset` beside `multi_face`, never after it.
per_pageNoRows per page. `null` draws the whole project in one montage, which returns a path rather than readable bytes — for a person to open, not for an agent to read.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed22 schema fields changedv0.25.0
    • addedInput schema / properties / extremes / description
      Added value: +"Draw the subject's own leftmost and rightmost moments, worst first, instead of fixed fractions — the rect does not move inside a stretch, so that is where a static window is worst. Off by default: it costs the face detector and about half a second a probe. Read `worst_offset` beside `multi_face`, never after it."
    • removedInput schema / properties / extremes / title
      Removed value: -"Extremes"
    • removedInput schema / properties / moments / anyOf
      Removed value: -[
      -  {
      -    "items": {
      -      "type": "number"
      -    },
      -    "type": "array"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / moments / description
      Added value: +"Fractions of each window to draw tiles at, e.g. `[0.1, 0.5, 0.9]`. A tile is evidence about one instant while a rect is a claim about a stretch, so where the subject moves these decide what the sheet can see. Refused alongside `extremes`."
    • addedInput schema / properties / moments / items
      Added value: +{
      +  "type": "number"
      +}
    • removedInput schema / properties / moments / title
      Removed value: -"Moments"
    • addedInput schema / properties / moments / type
      Added value: +[
      +  "array",
      +  "null"
      +]
    • removedInput schema / properties / out / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / out / description
      Added value: +"Write the image to this path as well, replacing whatever file is there. Unset, it goes to the project's own sheet cache and only the bytes come back."
    • removedInput schema / properties / out / title
      Removed value: -"Out"
    • addedInput schema / properties / out / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • addedInput schema / properties / page / description
      Added value: +"Which page of rows to draw, from 1. Unset, the first."
    • removedInput schema / properties / page / title
      Removed value: -"Page"
    • 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"
      +]
    • removedInput schema / properties / per_page / anyOf
      Removed value: -[
      -  {
      -    "type": "integer"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / per_page / description
      Added value: +"Rows per page. `null` draws the whole project in one montage, which returns a path rather than readable bytes — for a person to open, not for an agent to read."
    • removedInput schema / properties / per_page / title
      Removed value: -"Per Page"
    • addedInput schema / properties / per_page / type
      Added value: +[
      +  "integer",
      +  "null"
      +]
    • removedInput schema / title
      Removed value: -"reframe_sheetArguments"
  2. First observedv0.24.0

TDQS

A3.6/5.0
Behavior4/5

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

The description adds significant behavioral detail beyond the annotations: the `out` parameter replaces any existing file (destructive), `extremes` costs face-detection time (~half a second a probe), and `per_page: null` returns a path for a person rather than readable bytes. It also clarifies row semantics and skipped stills. This matches the idempotent/destructive annotations and provides operational insights without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is much longer than necessary and uses metaphorical language ('A tile is evidence about an instant, not an approval of the span') that adds literary style but not operational clarity. It is front-loaded with the purpose, but subsequent paragraphs contain rationale and tangential details (e.g., 'A badly-placed window reads as framing.') that do not directly help an agent invoke the tool. It could be condensed and structured more clearly.

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 tool with 6 parameters and no output schema, the description covers the key behavioral aspects: how windows are drawn, row splitting across placement boundaries, skipped stills, extremes selection, pagination, and the difference between returning bytes vs. a path. It is thorough enough for an AI agent to understand the tool's behavior, though it omits edge cases like empty projects or error conditions.

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?

With 100% schema description coverage, the baseline is 3, but the tool description enriches several parameters: `moments` are explained as 'evidence about one instant,' `extremes` draws leftmost/median/rightmost worst-first with `worst_offset`, and `per_page: null` is explicitly for human consumption. These additions go beyond the schema's own descriptions and aid correct parameter selection.

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?

The description opens with a specific verb and resource: 'Draw every placement's framing window on its own source frames.' This clearly distinguishes the tool from likely siblings like `reframe` or `reframe_detect`, which probably perform the actual reframe, though it does not explicitly name alternatives. The heavy use of domain jargon ('placement', 'framing window') may require background knowledge but does not obscure the core purpose.

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 gives a strong contextual reason to use the tool ('A framing decision is unreviewable without this') and explains the informational value of the drawn windows. However, it does not explicitly contrast the tool with sibling visualization tools (e.g., `footage_sheet`, `contact_sheet`) or provide conditions for when not to use it. The guidance is contextual but lacks explicit alternatives or exclusions.

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