Skip to main content
Glama

transcript_read

Read-only

Read bounded, incremental original transcript text for an audio or video task, using sequence offsets and optional time ranges to retrieve only new or relevant text.

Instructions

Read bounded incremental original text for an audio or video task. No images. trackId is the UUID returned by transcript_start; omitted selects the latest eligible same-source track. When subtitles and ASR coexist, explicitly read each desired trackId; no automatic merging or preference. after is last event sequence (initial0); pass nextAfter on subsequent calls so waits do not reread old events. Higher revision for a stable segment ID replaces prior text. limit1..500, default100. Optional source-second [start,end) filter; waitSeconds0..20 waits only for text. Returns source, original/mapped timestamps, final/provisional, requested/processed coverage and text status. acquisition separately reports decodedThrough, queueDepth, spooledBytes/maxSpoolBytes and its status; acquisition=complete does NOT mean transcription is complete. audioTransfer records streaming/retry/download-fallback status and provenance; use it to report whether a full audio download occurred. complete+speechStatus=no_speech differs from not_enabled/running/error. Untimed text stays unaligned.

The HOST chooses evidence depth from the user request and actual subtitle/ASR quality and coverage: text alone, selected storyboards, all storyboards, or targeted higher-quality follow-up. Subtitles, ASR and images are independently optional; choose any combination. For text-only media use audio_start/audio_url_start (audio-bearing video files/pages are accepted) without a visual job. No mandatory image retrieval, all-images rule, fixed answer format or mandatory ASR. Use video_review action=plan to record visual=none|selected|all; revise as evidence changes. Missing subtitles do NOT block usable images, and a video-only stream does not prove missing source audio. Each image response has a pending batch. Return images AND timestamp metadata to the model, inspect the chosen images, then call video_review action=ack with batchId and explicit viewedIndices (empty [] releases uninspected images without credit). ONLY THEN fetch another batch. Never accumulate many video_read calls inside one code/exec result: return control to the model after each bounded batch. Transport errors leave the batch pending: video_review replay retries it; status/reviewId support resume. Acknowledgement is a caller assertion, not proof of comprehension. Keep any semantic working notes in the Agent workspace, not in MCP evidence. Before finishing, video_review finish checks only the HOST-CHOSEN visual scope and pending image receipts, not text reading completion. The host must still judge if that scope answers the user, and state relevant gaps. Honest incomplete-work disclaimers do not justify abandoning feasible work. session_stop cleanup cancels processing but does not complete reading; user_cancelled is only for an explicit user cancellation. Audio-only workflows remain independent.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "transcript_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
endNo
afterNo
limitNo
startNo
trackIdNo
waitSecondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.0

TDQS

A4.1/5.0
Behavior5/5

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

The annotations only say readOnly/not destructive/not idempotent; the description supplies far more: the nextAfter pagination contract so waits do not reread old events, revision-replaces-prior-text semantics, waitSeconds blocking only on text, and the distinction between acquisition=complete and transcription being complete. It also flags that complete+speechStatus=no_speech differs from not_enabled/running/error, and that audioTransfer records retry and download-fallback provenance.

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 purpose is front-loaded and the transcript-specific sentences are dense but efficient. However, a large share of the text is scope creep about the video_review tool's image batches, batchId/viewedIndices acknowledgement, session_stop cleanup, and audio-only workflows, which belong to siblings rather than to transcript_read. That dilutes the signal an agent needs for this call.

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 no output schema, the description does the needed work of describing the return shape: source, original/mapped timestamps, final/provisional, requested/processed coverage, acquisition counters and status fields. Combined with the parameter and pagination guidance, an agent can call this correctly; the unexplained required 'id' is the remaining hole.

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 description coverage is 0%, so the description has to carry all seven parameters. It covers six well: trackId (UUID from transcript_start, omitted selects latest eligible), after (last event sequence, initial 0, pass nextAfter), limit 1..500 default 100, optional source-second [start,end) filter, and waitSeconds 0..20. The required 'id' parameter is never explained, which is the main gap.

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 states a specific verb and resource: 'Read bounded incremental original text for an audio or video task. No images.' The 'No images' clause usefully separates it from the video_read sibling that returns frames. It stops short of naming that sibling explicitly, but the boundaries are inferable.

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?

It gives concrete when-to-use guidance: omit trackId to select the latest eligible same-source track, explicitly read each trackId when subtitles and ASR coexist because there is no automatic merging, and use audio_start/audio_url_start for text-only media without a visual job. There are no explicit when-not-to-use statements, though the alternative paths are named.

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