proofcut

Overview Schema Source Related Servers Discussions Admin

properties

Read-onlyIdempotent

Inspect project, clip, and cue details for a video editing project. Pass a clip ID to include asset data, framing windows, and cue tables; add a word index for cue context.

Instructions

Project/clip/cue detail for a properties inspector, composed only.

No arguments: status, canvas and caption_style's own reports. clip_id: adds that clip's assets entry, its reframe window table, and its whole cue_ls. Both clip_id and word_index: adds cue (the matching entry from that cue_ls, or null if the word carries none) and, only when cue is null, context — the word plus three either side, the same echo every word-indexed tool gives (a cue's own entry already carries this, so it is not duplicated). word_index needs clip_id.

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.
`clip_id`	No	Add this clip's assets entry, framing windows and cue table to the report.
`word_index`	No	With `clip_id`, add the cue at that word — or, when there is none, the word plus three either side. It needs `clip_id`.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedv0.25.0Sep 16, 2026

removedInput schema / properties / clip_id / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / clip_id / description

Added value: +"Add this clip's assets entry, framing windows and cue table to the report."

removedInput schema / properties / clip_id / title
```
Removed value: -"Clip Id"
```
addedInput schema / properties / clip_id / 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"
+]

removedInput schema / properties / word_index / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / word_index / description

Added value: +"With `clip_id`, add the cue at that word — or, when there is none, the word plus three either side. It needs `clip_id`."

removedInput schema / properties / word_index / title
```
Removed value: -"Word Index"
```
addedInput schema / properties / word_index / type
```
Added value: +[
+  "integer",
+  "null"
+]
```
removedInput schema / title
```
Removed value: -"propertiesArguments"
```

First observedv0.24.0Sep 15, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds genuinely useful behavioral context beyond annotations: conditional composition of reports, the null-cue fallback to a context window, and the dedup guarantee that a cue's own entry already carries context so it is not repeated.

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

Conciseness3/5

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

The description is compact and parameter detail is logically organized, but the opening 'composed only' phrasing and shorthand like 'the same echo every word-indexed tool gives' are jargon-heavy and hinder immediate comprehension. It is appropriately sized but not as clear as it could be given the density.

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 read-only composition tool with an output schema present, the description covers the key agent-facing concerns: the no-argument report set, each parameter's incremental contribution, the word_index-to-clip_id dependency, null-cue behavior, and deduplication. The main gap is the absence of explicit sibling routing, but the conditional behavior an agent needs to invoke it correctly is well specified.

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%, setting a baseline of 3, but the description materially enriches all three parameters: it spells out exactly what clip_id contributes (assets entry, reframe window table, cue_ls) and what word_index yields (the matching cue or the word±3 context fallback). The path parameter's semantics are already well-covered by the schema, so the description's added value is distributed where it matters.

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 identifies the resource ('Project/clip/cue detail for a properties inspector') and the composition behavior, which distinguishes it from dedicated sibling tools like cue_ls or assets. However, the phrase 'composed only' is cryptic and does not crisply convey that this aggregates existing reports rather than computing new data, leaving some ambiguity on first read.

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 clearly explains the within-tool parameter combinations (no args vs clip_id vs clip_id+word_index) and the dependency that word_index needs clip_id. It does not, however, explicitly guide when to choose this tool over siblings like describe_ls, cue_ls, or assets, leaving alternative routing to inference.

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

Deploy Server