talkthrough-mcp

Overview Schema Source Related Servers Discussions Admin

get_transcript

Read-onlyIdempotent

Retrieve paginated transcripts of processed recordings in segments, plain text, or SRT subtitles. Filter by time range to extract specific moments for summarization or review.

Instructions

Retrieve the transcript of a processed job, lazily and paginated. Formats: "segments" (default — seq, t_ms, t_wall when known, speaker when diarized, text), "text" (plain prose; "S1:" prefixes at speaker changes), "srt" (subtitles, speaker-prefixed cues). Diarized jobs also return the roster, attribution_precision, saved speaker_name values, raw OCR name_candidates, and bounded pending-review names plus old-roster context after a relabel. Pre-0.3.1 video jobs may return name_candidates_note because their flat OCR is readable but less useful for hints. Pending names are evidence to re-check, never active identities. A stale pending label can only be removed with label_speakers(..., labels={"Sx":null}). Raw S labels remain canonical. Responses are capped (~8k tokens): when truncated=true, continue from the returned next_start_ms. When NOT to use: to find one keyword (use search) or to inspect one moment with visuals (use get_moment). Examples:

get_transcript(job_id="a1b2c3d4e5f60718") — whole transcript of a short recording
get_transcript(job_id="a1b2c3d4e5f60718", start_ms=0, end_ms=120000) — just the first two minutes
get_transcript(job_id="...", format="text") — prose block for summarization
get_transcript(job_id="...", format="srt") — subtitle export the user asked for
diarized job: segments carry "speaker" + a roster header (top-12 by talk time; speakers_truncated counts the rest)
"what did S2 say?" → format="segments", collect entries with speaker=="S2" (labels are in order of first voice)
got truncated=true with next_start_ms=421500 → get_transcript(job_id="...", start_ms=421500)
user: "what was said between 5:00 and 6:30?" → start_ms=300000, end_ms=390000
legacy video name_candidates_note → explain the limitation; safe regeneration uses force=true+diarize=true
correlate speech with logs: each segment's t_wall lines up with your log timestamps
no speaker fields on a meeting job → re-run process_media with diarize=true (adds them without re-transcribing)
attribution_precision="segment" → force=true+diarize=true is required for exact word boundaries
pending context points to old evidence; stale labels accept null removal, never a new name
anti-example: "where did they mention checkout?" → search(job_id, "checkout"), not full paging
anti-example: screenshots around a remark → get_moment(job_id, start_ms, end_ms)

Input Schema

TableJSON Schema

Name	Required	Default
`end_ms`	No
`format`	No	segments
`job_id`	Yes
`start_ms`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.4Aug 3, 2026
Removedv0.2.0Jul 17, 2026
First observedv0.1.0Jul 11, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already mark readOnly, idempotent, non-destructive. The description substantially adds context: pagination truncation with next_start_ms, diarized roster details, speaker label semantics, stale-label removal, and legacy caveats. No contradiction with annotations; description enriches the safety profile with operational behavior.

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?

Though lengthy, it is dense and well-organized: core purpose first, then format spec, then pagination, then 'When NOT to use', then a long list of concrete examples with anti-examples. Every sentence adds value—no filler. Structure front-loads the most critical info and uses formatting (bullets) to aid scanning.

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?

The tool has complex behavior (diarization, multiple formats, pagination, legacy notes). The description covers every aspect an agent needs to call it correctly: output shapes, pagination continuation, roster/attribution details, speaker label handling, and correlation with logs. No missing context even without an output schema.

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

Parameters5/5

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

Schema coverage is 0%, so the description must fully compensate. It explains job_id implicitly, start_ms/end_ms for range, and format by listing the three enum values and their output structures. It goes beyond schema by describing what each format returns (segments fields, text prefixes, srt cues) and how to use start_ms for continuation. Complete semantic coverage.

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 states a specific verb ('Retrieve'), resource ('transcript of a processed job'), and key behaviors (lazily, paginated). It explicitly differentiates from siblings by naming search and get_moment as alternatives for different intents, so an agent can select it correctly just from the description.

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?

Includes a dedicated 'When NOT to use' section naming alternatives (search, get_moment), plus extensive examples and anti-examples covering format selection, paging, diarized handling, and legacy cases. Guidance is explicit and conditions for choosing alternatives are crystal clear.

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

Deploy Server