Skip to main content
Glama

start many sync jobs

jobs_create-many
Destructive

Start up to 50 independent Sync jobs in one request by submitting each item’s own create arguments, such as lip-sync, dubbing, translation, dialogue, or speech previews.

Instructions

Start up to 50 independent Sync jobs at once by running one create tool once per item: lipsync_create, lipsync_create-timeline, dubbing_create, translation-previews_create, dialogue-previews_create, dialogue-videos_create, speech-previews_create. Use it whenever the user wants 2 or more jobs that do not depend on each other, such as one video lip-synced to several audios, one video dubbed into several languages (one dubbing_create item per language, when available), or one Edit Dialogue preview, then one video, per variant. It works on every plan and uses the same API, limits and billing as calling the tool once per item; it is not the batch API. Each item is that tool’s own arguments and is checked as a direct call would be; nothing starts if any item is invalid or repeats another. This is a paid action: every item is billed as its own job. Before calling, estimate each distinct configuration with the matching estimate tool, tell the user the item count and the estimated total, and wait for one confirmation of the whole set. Items without projectId each get a new project; to keep the set together, create one project with projects_create and pass its projectId with projectIntent=explicit in every item. It keeps at most the account’s concurrent generation limit in flight and waits out capacity refusals by resending the same keyed request. It returns within about 50 seconds and never waits for the jobs to finish. Each item comes back started (with kind and id), failed (with error) or not_started (the account stayed busy). A request still unanswered at the time limit, cut off by a lost connection, or answered with a server error, comes back failed with error.outcomeUnknown: the job may have started. Pass jobs to jobs_get-many to follow the started ones. When remaining is present (items not started or with an unknown outcome), call again later with remaining as it is: every item keeps its derived keys, so a resend never starts a job twice.

Input Schema

NameRequiredDescriptionDefault
toolYesThe create tool to run once per item. Other tools cannot run this way.
itemsYesUp to 50 items, each exactly the arguments tool takes on its own, such as one dubbing_create input per target language. Items must differ. A new set has 2 or more; a single item is for sending remaining again.
idempotencyKeyYesA fresh UUID for this approved set, saved before the call. Reuse it unchanged, with the same items, when calling again for remaining or uncertain items; each item derives its own keys from it.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.4

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: paid action billed per item, same API/limits as single calls, respects the account concurrency limit with keyed resends, ~50 second ceiling and never waiting for completion, per-item started/failed/not_started states, and error.outcomeUnknown semantics for ambiguous server errors. The idempotencyKey reuse rule resolves the apparent tension with idempotentHint=false by explaining that derivation is per item rather than per tool call.

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 purpose, then eligibility, then cost/confirmation, then control flow, then return values — a logical order with no filler. It is dense and long (one unbroken block of prose), and a few sentences such as the concurrent-limit/resend one could be split for easier scanning, but the complexity of a paid multi-job batch justifies most of the length.

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?

Covers confirmation workflow, cost estimation via the matching estimate tools, projectId/projectIntent handling for keeping a set together, partial-result interpretation and the resume contract. Even though an output schema exists, the description still supplies the decision rules an agent needs (when to resend, when to poll), leaving no obvious gap for a paid, partially-failing batch operation.

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 already 100%, so the baseline is 3, but the description adds real meaning: items are 'that tool's own arguments' validated as a direct call would be, must differ from one another, and a single-item set is reserved for resending 'remaining'. It also explains that a reused idempotencyKey pairs with the same items. The tool enum itself is left to the schema, so not quite maximal.

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 and scale bound: 'Start up to 50 independent Sync jobs at once by running one create tool once per item', then enumerates the seven eligible tools. It explicitly distinguishes itself from the batch API ('it is not the batch API') and from single-call creation, so an agent can place it precisely against siblings like batches_create and lipsync_create.

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?

States the trigger condition plainly ('whenever the user wants 2 or more jobs that do not depend on each other') and gives three concrete worked scenarios (one video to several audios, one video dubbed per language, preview-then-video per variant). It also names the follow-up tool (jobs_get-many) and the resend path with 'remaining', and warns that items must differ and at least two are needed for a new set.

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