proofcut

Overview Schema Source Related Servers Discussions Admin

finish_report

Read-onlyIdempotent

Report Finish-mode project status: duration, canvas, captions, picture, marks, seams, unused clips, and warnings naming the fixing mode. Optional framing, holds, and continuity checks.

Instructions

Duration/canvas/caption/picture/marks/seams report for Finish mode, composed only — the truth strip's own numbers.

duration: edit seconds, tail seconds, and their sum. canvas: the stored or footage-fallback canvas, plus each export preset's own ok/refusal-message. captions: whether a style is configured, its resolved font, and whether the last render actually burned it in ("yes"/"no"/"unknown" — unknown when no render log exists). picture: cue count, pinned count, and the picture plan's own refusal message when it has one. marks: unspoken marks applied vs. still stale. seams: the transcript's own overlap count. unused_clips: registered clips on no lane, cued nowhere, held nowhere, not the music bed — a clip imported and forgotten (TRIAL.md § Registered-and-not-on-the-timeline has no report of its own), clearable with clip_rm or by cueing it. flags: the rolled-up warnings behind all of the above, each one naming the mode that fixes it.

framing adds reframe_coverage's stale-framing numbers and their two flags, and is off by default because it decodes placed footage for a scene-cut scan — 5.7s wall and 46s of CPU on the film, uncached, every call. Off, framing is None, which means "not measured" rather than "nothing stale".

holds adds hold_check's own per-hold seam/transcription report against the last render — off by default for the same reason framing is: it decodes and transcribes render spans. None when not asked for, and also None when asked for but nothing has rendered here yet.

continuity adds continuity_check's finding count by kind (rewind, replay, short_shot, stub) and how many are currently accepted — also off by default, its stubs=True half paying the identical scene-cut decode framing does. None when not asked for.

Input Schema

TableJSON Schema

Name	Required	Description
`path`	No	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.
`holds`	No	Add the per-hold seam and transcription report against the last render. Off by default for the same reason: it decodes and transcribes render spans. Null when not asked for, and also null when nothing has rendered here yet.
`framing`	No	Add stale-framing numbers. Off by default because it decodes placed footage for a scene-cut scan (5.7s wall, 46s of CPU on the film, uncached, every call). Off, `framing` is null, which means not measured rather than nothing stale.
`continuity`	No	Add the continuity finding counts by kind and how many are accepted. Off by default — its stub half pays the same scene-cut decode `framing` does.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv0.25.0Sep 16, 2026

addedInput schema / properties / continuity / description

Added value: +"Add the continuity finding counts by kind and how many are accepted. Off by default — its stub half pays the same scene-cut decode `framing` does."

removedInput schema / properties / continuity / title
```
Removed value: -"Continuity"
```

addedInput schema / properties / framing / description

Added value: +"Add stale-framing numbers. Off by default because it decodes placed footage for a scene-cut scan (5.7s wall, 46s of CPU on the film, uncached, every call). Off, `framing` is null, which means *not measured* rather than nothing stale."

removedInput schema / properties / framing / title
```
Removed value: -"Framing"
```

addedInput schema / properties / holds / description

Added value: +"Add the per-hold seam and transcription report against the last render. Off by default for the same reason: it decodes and transcribes render spans. Null when not asked for, and also null when nothing has rendered here yet."

removedInput schema / properties / holds / title
```
Removed value: -"Holds"
```

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 / title

Removed value: -"finish_reportArguments"

First observedv0.24.0Sep 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is known. The description adds substantial behavioral context beyond that: it explains the cost of optional sections (5.7s wall, 46s CPU for framing), the meaning of None (not measured vs. nothing stale), and the special semantics of unused_clips and its clearable methods. No contradiction with annotations; instead, it enriches the behavioral model.

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 long but exceptionally well-organized: it opens with a one-line summary, then uses a bulleted list for the core sections, and separately details the optional flags with their costs. Every sentence earns its place; nothing is redundant. The front-loading of the main purpose and the structured breakdown make it easy to scan despite its length.

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?

The description thoroughly covers all sections and optional flags, including return semantics (None cases), performance trade-offs, and even how to clear unused clips. Since an output schema exists, the description need not spell out the return structure, and indeed it doesn't. Nothing an agent needs to decide whether to call this tool or how to set its flags 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?

The input schema covers all four parameters with descriptions (100% coverage), so the baseline is 3. The description adds extra nuance, especially for 'holds' and 'framing', explaining when they return None and reiterating the cost rationale. This goes slightly beyond the schema's one-liners, providing the agent with better context for deciding when to pass true.

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 states a specific verb and resource: it produces a comprehensive report for Finish mode, listing the exact components (duration, canvas, captions, picture, marks, seams, unused clips, flags). It also differentiates from siblings by emphasizing 'the truth strip's own numbers' and by referencing optional sections that mirror dedicated check tools (framing, holds, continuity), making its aggregating role clear.

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 explains when to enable each optional section (framing, holds, continuity) and notes the computational cost for each, giving clear context for choosing to include them. It implies this tool is the go-to Finish report rather than calling the individual check tools, but it does not explicitly state 'use this instead of X' or list alternative tools for specific scenarios. Still, the cost warnings effectively guide usage.

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

Deploy Server