Skip to main content
Glama
Sign In
Sync MCP Server

Sync MCP Server

Official
by synchronicity-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

transcribe a video

transcriptions_create
Destructive

Start a word-level transcription job for a video or audio source and get its job ID and status for speaker analysis, timelines, or lipsync reviews.

Instructions

Start a word-level transcription of a video or audio source and return its job id and status. Use it for general transcription, speaker analysis or timeline lipsync; for Edit Dialogue use dialogue-transcriptions_create when available. Read the result with transcriptions_get, or jobs_wait with kind transcription when available. Pass assetId to transcribe a saved VIDEO or AUDIO asset instead of a source URL. When supplying projectId, projectIntent=explicit is required: the user must explicitly ask to work in that project, select it in the interface, or this must be the project just created for this request. A matching workflow/name or an already-open editor is never permission to modify it. Default new work to a new project.

Input Schema

NameRequiredDescriptionDefault
endMsNoEnd of the window to transcribe, in milliseconds from the start of the source. Omit to transcribe to the end. The window cannot exceed 60 minutes. An end past the end of the source is clamped to it, and the job reports the end it used in `sourceEndMs`.
assetIdNoSaved VIDEO or AUDIO asset to transcribe; replaces sourceVideoUrl/sourceAudioUrl.
startMsNoStart of the window to transcribe, in milliseconds from the start of the source. Defaults to 0. A start at or past the end of the source video is refused with a 422 naming `startMs`.
projectIdNoOptional id of a project in your organization to file the job under.
projectIntentNoRequired with projectId. Set only for an explicit user project selection/update, or the new project just created for this request. Never infer intent from a matching project name, workflow name or active editor.
sourceAudioUrlNoURL of audio already extracted from the source, hosted in sync. storage. Skips the server-side audio extraction. Provide exactly one of `sourceVideoUrl` or `sourceAudioUrl`.
sourceVideoUrlNoURL of the source video, hosted in sync. storage (upload it via POST /v2/assets/upload first). Provide exactly one of `sourceVideoUrl` or `sourceAudioUrl`.
maxSourceSecondsNoRefuse the source if it is longer than this many seconds. Useful when a later step, such as a dialogue edit (10 minute window), cannot consume a longer transcript. Cannot exceed the endpoint ceiling of 3600 seconds.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A4.1/5.0
Behavior3/5

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

Annotations declare destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description never explains what is destructive or why the call is non-idempotent. It does add genuinely useful policy context beyond the annotations — the explicit project-intent rule and the warning never to infer permission from a matching name or open editor.

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?

Purpose, alternatives and follow-up reads are front-loaded, then the safety rule. Some redundancy: the projectIntent requirement is spelled out in both the description and the schema, costing a few sentences.

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?

For an 8-parameter job-creating tool with no output schema, the description covers what is returned (job id and status), how to poll it, and the project-safety constraints. It does not mention credit/cost implications or source-size limits, which for a destructive, open-world job are meaningful omissions.

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 coverage is 100%, with startMs/endMs windows, assetId substitution and projectIntent already documented in the schema. The description restates the projectId/projectIntent coupling and the assetId alternative but adds little syntax or constraint detail beyond what structured fields provide; baseline 3 applies.

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 first sentence gives a specific verb and resource ("Start a word-level transcription of a video or audio source") plus the return shape (job id and status). It also names the sibling it is not (dialogue-transcriptions_create for Edit Dialogue), so an agent can discriminate without opening a schema.

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?

Explicit routing: use this for general transcription, speaker analysis or timeline lipsync; use dialogue-transcriptions_create for Edit Dialogue; read results via transcriptions_get or jobs_wait. It also states when to pass assetId instead of a source URL and the conditions that permit a projectId.

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