Skip to main content
Glama
Sign In
Sync MCP Server

Sync MCP Server

Official
by synchronicity-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

check an edit dialogue transcription

dialogue-transcriptions_get
Read-only

Poll an Edit Dialogue transcription job by ID to get its status, transcript segments, speaker count, or failure details before creating dialogue previews.

Instructions

Read one Edit Dialogue transcription job by id, the step between dialogue-transcriptions_create and dialogue-previews_create. It first confirms access to projectId and that the job was made from the stored video of videoAssetId; a job from any other source is rejected. Returns status: PENDING or PROCESSING while running, then COMPLETED or FAILED. Once COMPLETED: transcript.segments, each with words { id, text, startMs, endMs } in milliseconds from the start of the source, plus a top-level speakerCount (both are null before then). On FAILED: error { code, message }; NO_AUDIO, NO_AUDIO_TRACK and SOURCE_TOO_LONG will not succeed on retry. It has no wait option: call it again while the job runs, or, when available, use jobs_wait with kind transcription to wait on the server for up to about 50 seconds; never start another transcription to check progress. Word ids feed the edits of dialogue-previews_create, but Edit Dialogue supports one speaker, so do not create a preview when speakerCount is above 1. Not for jobs from the general transcriptions_create (read those with transcriptions_get, when available).

Input Schema

NameRequiredDescriptionDefault
idYesThe id field of the dialogue-transcriptions_create result; later passed to dialogue-previews_create as transcriptionJobId.
projectIdYesThe projectId passed to dialogue-transcriptions_create. Used only to confirm project access; the job itself is read by id.
videoAssetIdYesThe videoAssetId passed to dialogue-transcriptions_create, or the copy's id when its result returned videoAssetId. It must be a VIDEO asset; its stored URL is compared with the job's source, and a job made from a different source video is rejected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.2.4
    • changedInput schema / properties / id / description
      Previous value: -"Transcription id from dialogue-transcriptions_create."New value: +"The id field of the dialogue-transcriptions_create result; later passed to dialogue-previews_create as transcriptionJobId."
    • changedInput schema / properties / projectId / description
      Previous value: -"Project the Edit Dialogue work belongs to, from projects_create."New value: +"The projectId passed to dialogue-transcriptions_create. Used only to confirm project access; the job itself is read by id."
    • changedInput schema / properties / videoAssetId / description
      Previous value: -"Saved VIDEO asset being edited. Use the videoAssetId dialogue-transcriptions_create returned when it made a copy."New value: +"The videoAssetId passed to dialogue-transcriptions_create, or the copy's id when its result returned videoAssetId. It must be a VIDEO asset; its stored URL is compared with the job's source, and a job made from a different source video is rejected."
  2. Changed3 schema fields changed
    • addedInput schema / properties / id / description
      Added value: +"Transcription id from dialogue-transcriptions_create."
    • addedInput schema / properties / projectId / description
      Added value: +"Project the Edit Dialogue work belongs to, from projects_create."
    • addedInput schema / properties / videoAssetId / description
      Added value: +"Saved VIDEO asset being edited. Use the videoAssetId dialogue-transcriptions_create returned when it made a copy."
  3. Addedv0.1.5

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already establish a safe read operation (readOnlyHint=true, destructiveHint=false), and the description adds substantial context beyond them: access confirmation for projectId, source-video matching rejection, the PENDING/PROCESSING/COMPLETED/FAILED lifecycle, null-before-completion fields, non-retryable error codes, and the absence of a wait option. The one gap is that it does not discuss rate limits or polling cadence, but for a read-only status tool the disclosure is rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loaded, starting with the read operation and placing workflow and polling guidance after the return-value details. It is long for a single paragraph and repeats some schema-level parameter semantics, but nearly every sentence carries operational value for a tool with a state machine and strict source validation.

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?

There is no output schema, so the description carries the return contract and does so thoroughly: status values, transcript.segments with word timing in milliseconds from source start, speakerCount nullability, and error codes. Combined with the polling guidance and preview gating rule, an agent has everything needed to call and interpret this tool correctly.

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 that id comes from dialogue-transcriptions_create, that projectId is only for access confirmation, and that videoAssetId must be a VIDEO asset compared against the job's source. The description largely restates those semantics, adding only the workflow link that word ids feed dialogue-previews_create edits; with the schema doing most of the work, baseline 3 is appropriate.

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?

States a specific verb and resource: 'Read one Edit Dialogue transcription job by id.' It also positions the tool in the workflow between dialogue-transcriptions_create and dialogue-previews_create, and explicitly excludes jobs from the general transcriptions_create, so an agent can distinguish it from siblings 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?

Gives explicit when-to-use guidance and alternatives: poll again while running, or use jobs_wait with kind transcription; 'never start another transcription to check progress'; and 'do not create a preview when speakerCount is above 1.' The exclusion for general transcriptions_create is named with its alternative, transcriptions_get.

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