Skip to main content
Glama
Sign In
Sync MCP Server

Sync MCP Server

Official
by synchronicity-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

read a transcription

transcriptions_get
Read-only

Retrieve a transcription job by ID to check status and, when complete, read transcript segments, speaker details, timing, revision, and source URL; wait for completion or inspect failure errors.

Instructions

Read one transcription job by id. Returns:

  • status: PENDING, PROCESSING, COMPLETED or FAILED.

  • Once COMPLETED, transcript.segments, each with an id and words. A word has text, startMs and endMs in milliseconds from the start of the source (not of the transcribed window), and a speakerId that is null or absent when unknown.

  • speakerCount, a top-level field beside transcript.

  • revision (once there is a transcript) and sourceVideoUrl (null for an audio source), which transcriptions_analyze-speakers takes.

  • On FAILED, error.code. NO_AUDIO, NO_AUDIO_TRACK and SOURCE_TOO_LONG will not succeed on retry.

  • While running, estimate.estimatedFinishAt may give an expected finish. estimate is null or absent when there is too little history. Use it after transcriptions_create. id is the UUID that call returned: a malformed id is a 400 error, and a well-formed id not in the current organization is a 404. With wait: true the server keeps reading for up to about 50 seconds and returns once the job is COMPLETED or FAILED. If it is still running, call again with wait: true; never start another transcription to check progress. Not for Edit Dialogue transcriptions (dialogue-transcriptions_get, when available) or face matches (transcriptions_get-speaker-analysis). jobs_get and jobs_wait with kind transcription, when available, read the same job with the cross-kind statuses.

Input Schema

NameRequiredDescriptionDefault
idYesTranscription id from transcriptions_create.
waitNoWait on the server until the job finishes or about 50 seconds pass, then return its latest state. If it is still running, call again with wait: true instead of sleeping.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / id / description
      Previous value: -"Transcription job id"New value: +"Transcription id from transcriptions_create."
  2. Addedv0.1.5

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare this as a safe read-only operation, and the description adds substantial behavioral context beyond them: job status lifecycle, failure codes that will not succeed on retry, 400 versus 404 meanings for the id, and the roughly 50-second server-side wait behavior. It also warns against starting another transcription to check progress.

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 purpose is front-loaded in the first sentence, and the remaining details are organized into a bulleted return-shape section followed by usage caveats. Despite its length, every section supplies information the agent needs, particularly because there is no output schema.

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?

With no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: status values, segment and word structure, speakerCount, revision, sourceVideoUrl, error.code, and estimate behavior. It also covers the wait lifecycle and the relevant alternatives.

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 coverage is 100%, so the schema already documents both parameters well. The description still adds useful semantics by explaining that a malformed id produces a 400 and an id outside the organization produces a 404, and by clarifying the retry pattern for wait: true.

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 specific verb and resource: 'Read one transcription job by id.' It explicitly distinguishes this tool from dialogue-transcriptions_get, transcriptions_get-speaker-analysis, and the cross-kind jobs_get/jobs_wait alternatives.

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 states when to use the tool ('Use it after transcriptions_create'), when not to use it (Edit Dialogue transcriptions, face matches), and what to do when a waited job is still running. The guidance is explicit enough that an agent can choose correctly without inspecting sibling schemas.

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

Deploy Server

Other Tools