Skip to main content
Glama

continuity_check

Read-onlyIdempotent

Identify rewinds, replays, short shots, and stubs in a cut. Reports findings for your review rather than making automatic decisions.

Instructions

Rewinds, replays, short shots, and film-internal-cut stubs — reports, never decides.

Rewind: a shot lands behind where its own asset last left off, with under gap seconds of timeline since. Replay: an earlier shot's source range is re-shown, gap seconds or more later — reported, never refused, because a deliberate narrative rhyme and a mistake look identical from the cue table alone. short_shot: under min_shot seconds (stills excluded). stub: a shot ends or begins right where its own footage has a real internal cut — likely a fragment rather than the shot itself.

The stored cold open (head) is walked as a pseudo-shot before the first real one, so a body shot that rewinds into the head's own footage is caught the same way a body-to-body rewind is. Overrun is never a finding: mlt.plan_picture already refuses it structurally, so nothing reaches this walk having overrun its asset.

stubs=True costs a scene-cut decode per distinct asset placed — stubs=False skips it. scene_threshold defaults to the pinned 0.15 but is caller-settable: darker footage from a different film has needed 0.12.

Findings already acknowledged by continuity_accept are dropped unless the shot moved under the mark, in which case they are kept and marked accepted_stale: True rather than silently re-suppressed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gapNoHow much timeline may pass before re-showing an asset reads as a replay rather than a rewind, in seconds.
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.
stubsNoLook for stubs. On by default, and it costs a scene-cut decode per distinct asset placed — `false` skips that.
min_shotNoShortest a shot may run before it is reported as a short shot, in seconds. Stills are excluded.
stub_toleranceNoHow close a shot edge has to sit to its footage's own internal cut to be called a stub, in seconds.
scene_thresholdNoThe scene-cut threshold for the stub scan. It defaults to the pinned 0.15, but darker footage from a different film has needed 0.12.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changedv0.25.0
    • addedInput schema / properties / gap / description
      Added value: +"How much timeline may pass before re-showing an asset reads as a replay rather than a rewind, in seconds."
    • removedInput schema / properties / gap / title
      Removed value: -"Gap"
    • addedInput schema / properties / min_shot / description
      Added value: +"Shortest a shot may run before it is reported as a short shot, in seconds. Stills are excluded."
    • removedInput schema / properties / min_shot / title
      Removed value: -"Min Shot"
    • 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 / scene_threshold / description
      Added value: +"The scene-cut threshold for the stub scan. It defaults to the pinned 0.15, but darker footage from a different film has needed 0.12."
    • removedInput schema / properties / scene_threshold / title
      Removed value: -"Scene Threshold"
    • addedInput schema / properties / stub_tolerance / description
      Added value: +"How close a shot edge has to sit to its footage's own internal cut to be called a stub, in seconds."
    • removedInput schema / properties / stub_tolerance / title
      Removed value: -"Stub Tolerance"
    • addedInput schema / properties / stubs / description
      Added value: +"Look for stubs. On by default, and it costs a scene-cut decode per distinct asset placed — `false` skips that."
    • removedInput schema / properties / stubs / title
      Removed value: -"Stubs"
    • removedInput schema / title
      Removed value: -"continuity_checkArguments"
  2. First observedv0.24.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations that already declare readOnly/idempotent/non-destructive, the description discloses important behaviors: accepted findings can be marked accepted_stale, the cold open is walked as a pseudo-shot, overruns are structurally impossible, stubs=True has a decode cost, and scene_threshold tuning is sensitive to footage. This is rich, non-obvious behavioral information with no contradiction of the annotations.

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?

The description is longer than average, but every sentence carries distinct information: definitions, edge cases, cost implications, and acknowledgement-staleness behavior. It is front-loaded with a one-line summary and uses bold labels effectively, making dense content scannable without fluff.

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 six-parameter, multi-finding analysis tool, the description covers the full decision surface: findings, parameter effects, edge cases, cost, and interaction with continuity_accept. With an output schema present, the absence of return-value discussion is acceptable; the description answers essentially any question an agent would need before calling.

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, but the description adds semantic value by wiring parameters to finding definitions: gap separates rewind from replay, min_shot defines short_shot, stubs controls the expensive decode, and scene_threshold is given a real-world tuning example. It does not add new meaning to stub_tolerance, but the schema already covers it.

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 opening line names the tool's exact role: detecting rewinds, replays, short shots, and stubs, and 'reports, never decides.' Each finding type is defined in enough detail to distinguish for checking from sibling continuity_accept/continuity_reject/continuity_ls, which handle decisions and listing after the fact.

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?

The description conveys strong context for when this tool is appropriate: it is a non-deciding reporter, and it explains how acknowledged findings from continuity_accept are handled, implying the accept/reject workflow. It does not explicitly name alternatives or say 'use this instead of X,' but the never-decides framing and the continuity_accept reference make the usage context clear.

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