Skip to main content
Glama

hear

Read-onlyIdempotent

Listens to the specified span of a clip's source audio and reports the spoken words next to the transcript, revealing where transcript and audio disagree.

Instructions

What does clip_id's source audio actually say between start and end?

Use this when the transcript and the audio might disagree — a word with a suspect duration, a hole with no words in it, a stretch that reads clean but sounds wrong. It runs the same short-overlapping-window pass verify(windowed=True) runs, over the clip's own media across the span (source seconds), and comes back with heard_words/heard_text beside the attached transcript's own words over that span (transcript_words). No need to seed, export and verify to hear your source material.

Reports, never attaches — nothing is written and no word index moves. Where the two disagree, cut_by_time addresses what the transcript has no word for. heard_words can be empty: silence is a real answer. One whisper run over the span; end past the clip is refused.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endYesWhere to stop, in the same source seconds. Past the end of the clip it is refused rather than clamped.
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.
modelNoThe whisper model for this windowed pass.small
startYesWhere to start listening, in that clip's own **source** seconds — never timeline seconds and never a word index.
windowNoLength of each window, in seconds.
clip_idYesThe clip whose source audio to listen to.
overlapNoHow far each window overlaps the one before it, in seconds. The overlap is what stops a word straddling a boundary from being lost between two windows.
languageNoForce a language code, e.g. `en`. Unset, whisper detects it.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed21 schema fields changedv0.25.0
    • addedInput schema / properties / clip_id / description
      Added value: +"The clip whose source audio to listen to."
    • removedInput schema / properties / clip_id / title
      Removed value: -"Clip Id"
    • addedInput schema / properties / end / description
      Added value: +"Where to stop, in the same source seconds. Past the end of the clip it is refused rather than clamped."
    • removedInput schema / properties / end / title
      Removed value: -"End"
    • removedInput schema / properties / language / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / language / description
      Added value: +"Force a language code, e.g. `en`. Unset, whisper detects it."
    • removedInput schema / properties / language / title
      Removed value: -"Language"
    • addedInput schema / properties / language / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • addedInput schema / properties / model / description
      Added value: +"The whisper model for this windowed pass."
    • removedInput schema / properties / model / title
      Removed value: -"Model"
    • addedInput schema / properties / overlap / description
      Added value: +"How far each window overlaps the one before it, in seconds. The overlap is what stops a word straddling a boundary from being lost between two windows."
    • removedInput schema / properties / overlap / title
      Removed value: -"Overlap"
    • 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 / start / description
      Added value: +"Where to start listening, in that clip's own **source** seconds — never timeline seconds and never a word index."
    • removedInput schema / properties / start / title
      Removed value: -"Start"
    • addedInput schema / properties / window / description
      Added value: +"Length of each window, in seconds."
    • removedInput schema / properties / window / title
      Removed value: -"Window"
    • removedInput schema / title
      Removed value: -"hearArguments"
  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 the read-only/idempotent annotations, it discloses that the call reports and never attaches, writes nothing, moves no word index, may return empty `heard_words` as a valid silence answer, performs one whisper run over the span, and refuses `end` past the clip. This is substantive behavioral context the annotations do not provide.

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 dense but every sentence earns its place: purpose, trigger conditions, method, return fields, side effects, alternatives, and edge cases. The opening question front-loads the core purpose, and the bold 'Reports, never attaches' makes the side-effect statement highly scannable.

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 listening/verification tool with an output schema and well-documented parameters, this description covers everything an agent needs to call it correctly: when to use it, what it returns, what it does not do, cost/run characteristics, and refusal behavior. Nothing important is missing.

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 description coverage is 100%, and the schema already explains source seconds, refusal behavior, defaults, and language handling in detail. The description reinforces the source-seconds framing and mentions windowed passes, but it does not need to compensate because the schema already carries the parameter 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 opens with a precise question: what does a clip's source audio actually say over a span, and immediately ties it to comparing audio against the attached transcript. It also distinguishes itself from siblings by explicitly referencing `verify(windowed=True)` and `cut_by_time`, so an agent can disambiguate without opening schemas.

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 gives explicit trigger conditions: suspect word durations, holes with no words, or passages that read clean but sound wrong. It also names the relevant alternatives, saying there is no need to seed/export/verify and pointing to `cut_by_time` for disagreements, which is strong when-vs-alternative guidance.

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