proofcut

Overview Schema Source Related Servers Discussions Admin

unspoken_ls

Read-onlyIdempotent

List every word marked never-spoken, showing the current transcript text alongside. Detect stale marks where recorded and current text disagree, surfacing re-attached transcripts as a list to re-check.

Instructions

Every word marked never-spoken, with what the transcript says now.

Read-only. stale is a mark whose recorded text and current text disagree — the transcript was re-attached under it. A stale mark is never applied, so re-transcribing surfaces as a list to re-check rather than as words disappearing from a caption file.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.25.0Sep 16, 2026

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: -"unspoken_lsArguments"
```

First observedv0.24.0Sep 15, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already establish read-only/idempotent/non-destructive behavior, so the description adds meaningful value by defining the 'stale' state and its consequence: stale marks are never applied, and re-transcriptions appear as a list to re-check. This goes beyond the structured hints without contradicting them.

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 compact and front-loaded: a one-line purpose, followed by a pithy, high-value explanation of stale marks. No filler or repetition of schema content.

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 read-only listing tool with an output schema, complete parameter documentation, and annotations covering safety, the description provides the one missing piece of domain behavior — the stale-mark distinction — and is therefore sufficient for correct invocation.

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?

Only one parameter, path, is fully documented in the schema (100% coverage), including bound/unbound server behavior. The description adds no path-specific information, which is fine because the schema carries the full burden.

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 sentence 'Every word marked never-spoken, with what the transcript says now' states the operation as a listing of a specific resource (unspoken marks) and the key data returned. It is clearly distinct from sibling unspoken_add/rm/detect, which manage or detect marks.

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?

Usage is implied rather than explicitly stated. The stale-mark explanation gives one concrete scenario — after re-transcribing, use this to re-check marks — but the description never says when to prefer it over unspoken_detect or a general transcript tool.

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

Deploy Server