proofcut

Overview Schema Source Related Servers Discussions Admin

get_transcript

Read-onlyIdempotent

Read a clip's transcript or search for word ranges to feed directly to cut_by_transcript, avoiding reading the whole transcript.

Instructions

Read a clip's transcript.

With search, returns each match as a word range ready to hand to cut_by_transcript — prefer this to reading the whole transcript. With first/last, returns that window of words. Indices are inclusive.

At most limit words come back per call. total_words is the whole transcript, last_word where this reply stopped, and next_first — only present when words were left out — is the first to ask for next.

Input Schema

TableJSON Schema

Name	Required	Description
`last`	No	Last word index to return, inclusive.
`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.
`first`	No	First word index to return, inclusive.
`limit`	No	Most words to return in one call, counted from `first`. The reply's `next_first` says where to continue. Bounded by default because a whole transcript can be past what a client will put in context.
`search`	No	Return each match as a word range ready to hand to `cut_by_transcript`, instead of the whole transcript. Prefer it: a transcript is a lot of words to read to find two.
`clip_id`	Yes	The clip to read.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed20 schema fields changedv0.25.0Sep 16, 2026

addedInput schema / properties / clip_id / description
```
Added value: +"The clip to read."
```
removedInput schema / properties / clip_id / title
```
Removed value: -"Clip Id"
```

removedInput schema / properties / first / anyOf

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

addedInput schema / properties / first / description

Added value: +"First word index to return, inclusive."

removedInput schema / properties / first / title
```
Removed value: -"First"
```

addedInput schema / properties / first / type

Added value: +[
+  "integer",
+  "null"
+]

removedInput schema / properties / last / anyOf

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

addedInput schema / properties / last / description

Added value: +"Last word index to return, inclusive."

removedInput schema / properties / last / title
```
Removed value: -"Last"
```

addedInput schema / properties / last / type

Added value: +[
+  "integer",
+  "null"
+]

addedInput schema / properties / limit

Added value: +{
+  "default": 300,
+  "description": "Most words to return in one call, counted from `first`. The reply's `next_first` says where to continue. Bounded by default because a whole transcript can be past what a client will put in context.",
+  "type": "integer"
+}

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 / search / anyOf

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

addedInput schema / properties / search / description

Added value: +"Return each match as a word range ready to hand to `cut_by_transcript`, instead of the whole transcript. Prefer it: a transcript is a lot of words to read to find two."

removedInput schema / properties / search / title
```
Removed value: -"Search"
```
addedInput schema / properties / search / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedInput schema / title

Removed value: -"get_transcriptArguments"

First observedv0.24.0Sep 15, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the tool is safe and idempotent. The description adds pagination details (total_words, last_word, next_first) and notes that next_first is only present when words are left out, which is useful behavioral context beyond 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 concise and well-structured. It front-loads the primary use case (search) and then explains pagination in a few clear sentences. No wasted words.

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?

With an output schema present and complete schema coverage, the description sufficiently covers the key aspects: modes, pagination, and continuation. It could be a bit more explicit about the output schema fields, but overall it's complete for an agent to use effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already describes all parameters. The description clarifies the interplay between first, last, limit, and search, and explains how next_first is used for continuation, but this is largely redundant with schema descriptions. It doesn't add major new semantics.

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 clearly states the tool reads a clip's transcript and explains the different modes (search, first/last). It distinguishes itself from siblings like cut_by_transcript by showing how search results are meant to feed into it.

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?

It explicitly says to prefer search over reading the whole transcript, and explains first/last semantics. It also mentions pagination with limit and next_first, providing complete guidance on when and how to use the tool.

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

Deploy Server