Skip to main content
Glama

create a batch of generations

batches_create

Submit many independent lipsync generations as one queued batch for large runs, such as localizing one video into many languages or syncing many videos to their own audio.

Instructions

Submit many independent lipsync generations at once as one Sync batch, such as localizing one campaign video into many languages or syncing many videos to their own audio. Each item is one /v2/generate body; Sync queues them, so they skip the per-generation concurrency limit, and results can take up to a day. Batch is a separate queued pipeline, built for large runs (20 to 500) on Scale plans and above that can wait hours; below Scale every row still takes a concurrent generation slot. For 2 or more independent jobs that should start now, on any plan, use jobs_create-many when available; when one result feeds the next, call lipsync_create or dubbing_create per video. Call with dryRun: true first to have the API check every item without creating anything. This is a paid action: every item is billed as its own generation. Before creating, estimate a representative item with generations_estimate-cost, tell the user the item count and the estimated total, and wait for their confirmation. Not idempotent: each call creates a new batch, so after an uncertain response check batches_list before creating again. Leave payload.projectId out for new work; a payload with projectId needs projectIntent=explicit, which only an explicit user selection or a project just created for this request allows. Batch may not be on every plan: a 402 names requiredPlan and billingUrl. Returns the batch id and each item's requestId; then call batches_get with wait: true.

Input Schema

NameRequiredDescriptionDefault
itemsYesThe generations, in order; at least 20. Plans allow up to 500 per batch by default, and the whole batch must fit in 5 MB as JSONL.
dryRunNoValidate every item with the API without creating the batch or spending anything; answers status VALIDATED.
webhookUrlNoURL Sync POSTs the batch to when it finishes, signed with the organization webhook secret.
projectIntentNoRequired when any payload sets projectId. Set only when the user explicitly chose that project, or it is the project just created for this request; never infer it from a matching name or an open editor.
organizationIdNoRun only this call in another of the user’s Sync organizations, by id from organizations_list, when the user asks for it (for example “generate this in the Acme org”). The session keeps its organization; reads of the ids this call returns stay in this organization. Omit to use the session’s organization.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare the mutating, non-idempotent, open-world profile, and the description adds material context beyond them: queueing that bypasses the per-generation concurrency limit, results taking up to a day, plan-gated availability with a 402 carrying requiredPlan and billingUrl, and per-item billing as a paid action. The slack below Scale (each row still consumes a concurrent slot) and the 'up to a day' latency are exactly the operational traits an agent needs before invoking.

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 and scale limits are front-loaded, then alternatives, then safety steps, then return/next-step. Every sentence carries information, though the paragraph is dense and could be split into short scannable clauses; nothing is filler, but the single block makes the dryRun and projectIntent rules easy to miss.

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?

Despite the tool's complexity — nested array items, billing, plan gating, non-idempotency, and a downstream polling step — the description covers prerequisites, cost confirmation, recovery after an ambiguous response, and the handoff to batches_get with wait: true. An output schema exists, yet the one-line note about returned batch id and per-item requestId still usefully names the handle needed for the next call.

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 schema already documents items, dryRun, webhookUrl, projectIntent, and organizationId, and a baseline of 3 would apply to no added meaning. The description does add cross-parameter workflow meaning: the payload.projectId / projectIntent=explicit coupling, the rule that projectId must come from explicit user selection and never inference, and the dryRun-validates-without-spending semantics that ties to the cost-confirmation guidance.

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 and resource: 'Submit many independent lipsync generations at once as one Sync batch', and immediately names the sibling patterns it supersedes (jobs_create-many, lipsync_create, dubbing_create). An agent can distinguish this from every other generation tool in the sibling list without opening any 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 when-to-use with concrete scenarios (localizing one campaign video into many languages, syncing many videos to their own audio), volume and plan thresholds (20-500, Scale and above), and named alternatives for the 2+ immediate-jobs case and for chained/sequential work. It also prescribes a dryRun-first step, a cost-estimate-and-confirm step, and a recovery path via batches_list if the response is uncertain.

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