Skip to main content
Glama
Sign In
Sync MCP Server

Sync MCP Server

Official
by synchronicity-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

read any sync job

jobs_get
Idempotent

Read any sync job once by kind and ID to check status consistently across all job types without waiting or polling.

Instructions

Read any sync. job once, by kind and id, with one status vocabulary for all six kinds. Use it to check a job without waiting or to track jobs of different kinds the same way. Not for waiting: use jobs_wait instead of calling this in a loop. For a kind's extra read options, such as generations_get include or batches_get results, call that tool directly. 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 PENDING and PROCESSING mean still running: never create the job again. COMPLETED, FAILED, REJECTED (the API refused it, such as an import limit or a moderation rejection) and CANCELED are final. result is the job as the kind's own read tool returns it, with its original status; a COMPLETED import's result is the saved asset, whose id is the asset id, and 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. Reading an import resends the identical assets_create request, which returns the running import or its saved asset and starts the import if none exists; that is why this is not read-only. An unknown id, an auth failure or a translation_preview without projectId returns a tool error, not a status.

Input Schema

NameRequiredDescriptionDefault
idYesThe job id for the chosen kind, as listed in the tool description; for import it is the social video link itself.
kindYesWhich kind of job id is.
projectIdNoRequired for translation_preview; for import, the project passed to assets_create.
projectIntentNoimport only: pass it when the assets_create call for this link needed it.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.4
    • 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."
  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 declare destructiveHint=false and idempotentHint=true, but the description adds crucial context the annotations cannot: why readOnlyHint is false ('Reading an import resends the identical assets_create request... and starts the import if none exists'). It also defines the status lifecycle, explains REJECTED semantics, describes result shapes per kind, and flags the recoveryRequired uncertainty case.

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 and organized into scannable sections (usage, ids by kind, statuses, caveats). It is long but nearly every clause carries operational value. Minor deductions for the stray typo 'sync. job' and some density that could be tightened.

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?

For a tool with six kinds, an output schema, and partial annotation coverage, the description supplies the missing pieces: id provenance per kind, status vocabulary, result shape per kind, non-read-only caveat, and error conditions ('An unknown id, an auth failure or a translation_preview without projectId returns a tool error, not a status'). Nothing an agent needs to call it correctly appears to be missing.

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 already 100%, so the baseline is 3, but the description adds meaning the schema cannot express: what 'id' actually is for each of the six kinds (e.g. the social video link for import, the transcription id for speaker_analysis) and when projectId/projectIntent are required. This materially reduces wrong-parameter calls.

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?

Opens with a specific verb+resource: 'Read any sync job once, by kind and id, with one status vocabulary for all six kinds.' It immediately distinguishes itself from siblings jobs_wait (waiting) and jobs_get-many, and the per-kind id list makes the scope concrete.

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 exclusions and alternatives: 'Not for waiting: use jobs_wait instead of calling this in a loop' and 'For a kind's extra read options... call that tool directly', naming generations_get and batches_get. It also tells the agent never to re-create a job on PENDING/PROCESSING, which is usage guidance in practice.

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