Sync MCP Server

Official

by synchronicity-labs

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

wait for any sync job

jobs_wait

Idempotent

Wait up to 50 seconds for a job to reach a final status, then return its latest state; call after creating a job to avoid polling, and repeat if still processing.

Instructions

Wait on the server, for up to about 50 seconds, until any job reaches a final status, then return its latest state in the same shape as jobs_get. Use it after a create tool returns an id, instead of sleeping or calling jobs_get in a loop; if the job is still PENDING or PROCESSING when it returns, call jobs_wait again with the same input. For one check without waiting use jobs_get. It also returns early on result.recoveryRequired and sends progress notifications when the call has a progressToken. Ids by kind:

generation: the id from lipsync_create, dubbing_create, lipsync_create-timeline or dialogue-videos_create
transcription: the id from transcriptions_create or dialogue-transcriptions_create
speaker_analysis: the transcription id
translation_preview: the translation-previews_create id, plus its projectId
import: the social video link passed to assets_create, plus the same projectId (and projectIntent if that call needed it)
batch: the batches_create id Statuses:
PENDING, PROCESSING: still running. Never create the job again.
COMPLETED, FAILED, REJECTED (the API refused it, such as an import limit or a moderation rejection), CANCELED: final. A speaker analysis that is unavailable reads as FAILED. Results:
result keeps the kind's original status. A COMPLETED import's result is the saved asset, whose id is the asset id; a finished batch's result.results lists each item's generation status and output.
A translation_preview with result.recoveryRequired true has uncertain provider acceptance: do not create another job. Not read-only: an import read repeats the identical assets_create request, so it returns the running import or the saved asset, and starts the import for a link never imported (a non-social media URL is saved as a new VIDEO asset). Errors: an API failure that is not a job status, such as an unknown generation or transcription id or an auth failure, returns {error}; a translation_preview without projectId fails with a plain error message.

Input Schema

Name	Required	Description
`id`	Yes	The job id for the chosen kind, as listed in the tool description; for import it is the social video link itself.
`kind`	Yes	Which kind of job id is.
`projectId`	No	Required for translation_preview; for import, the project passed to assets_create.
`projectIntent`	No	import only: pass it when the assets_create call for this link needed it.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.4Nov 7, 2026

changedInput schema / properties / id / description

Previous value: -"The job to read; see the tool description per kind."New value: +"The job id for the chosen kind, as listed in the tool description; for import it is the social video link itself."

Addedv0.1.5Nov 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by explaining the ~50s server-side wait, early return on result.recoveryRequired, progress notifications when a progressToken is present, and the {error} shape for non-job-status failures. Critically, it explains why readOnlyHint=false: an import read re-issues the identical assets_create request and can start a new import for an unseen link, which an agent could not infer from the annotations alone.

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?

Front-loaded with the core behavior, then cleanly sectioned into ids-by-kind, statuses, results, and errors, so an agent can scan to the part it needs. It is long and occasionally repetitive (the projectId rule appears in both description and schema), but the density is justified by a six-kind, multi-status tool.

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?

An output schema exists, yet the description still supplies the one thing the schema cannot: how result varies per kind (saved asset id, batch item statuses, uncertain translation_preview acceptance). Error semantics and the non-read-only warning complete the picture for a complex polling tool.

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 baseline is 3, and the description earns an increment by mapping each 'kind' enum value to the specific sibling create tool that produced the id, and by clarifying that the import id is the social video link plus the assets_create projectId. The schema already states most of the projectId rules, so this is reinforcement plus genuine per-kind routing detail rather than wholly new information.

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 opening sentence names a specific verb (wait), the resource (any job), the timing bound (~50 seconds), the termination condition (final status), and the return shape (same as jobs_get). It is immediately distinguishable from jobs_get, jobs_get-many, and the various create tools.

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 when-to-use (after a create tool returns an id), explicit when-not (instead of sleeping or polling jobs_get in a loop), an explicit fallback (call again with the same input if still PENDING/PROCESSING), and an explicit alternative for a single non-blocking check (jobs_get). Nothing is left to inference.

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

Deploy Server