Skip to main content
Glama

Sound Pass per Shot

lab_ton_durchlauf

Generate SOUND EFFECTS for a whole sequence, shot by shot — Simon Meyer's pass: every shot is muted, padded with black frames up to the model's minimum length, re-rendered by Seedance 2.5 in editing mode at its low resolution with sound on, and only the generated sound is kept, stretched back to the original timing (the black padding is the sync marker) and laid at the shot's position. The result is ONE sfx track in sequence length, bound to the sequence's sfx stem; the other stems stay as they are. Each piece and its offset are listed in the audio row's metadata (stuecke). Shots come from the sequence itself, in export order and export length — no cut detection. Costs credits, priced per shot over the seconds actually sent (the padding counts); call with get_cost first. ASYNCHRONOUS: returns a job_id; poll the job until done. A shot that fails is refunded on its own and named in fehlende_einstellungen; if the whole run fails, all of it is refunded. The model is told: keep the picture, diegetic sound only, no music, no dialogue, no voices — hinweis adds a setting line for every shot.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
seq_idYesSequence id (from lab_create_sequence/lab_list_sequences) — positive integer as string
hinweisNoOne line about the setting that applies to every shot, e.g. 'kitchen, wooden floor, rain on the window'. Helps the model pick the right room sound. Leave it out if the shots differ too much.
get_costNoReturn the price in credits WITHOUT starting anything — per shot over the seconds actually sent, at the rate lab_list_models lists for the model. Do this first; long sequences add up.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only give readOnlyHint=false / destructiveHint=false; the description carries far more: async job_id semantics, credit cost basis (padding counts), per-shot vs whole-run refund behavior, fehlende_einstellungen reporting, exactly what gets created and what stays untouched, and the metadata (stuecke) written to the audio row. No contradiction with the annotations.

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 action, and nearly every clause carries real operational weight (sync marker, refunds, cost, async). The prose is dense with stacked parentheticals, which slightly impairs readability, but there is little filler.

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?

No output schema exists, yet the description still explains the return shape (job_id, stuecke metadata, fehlende_einstellungen) and the full lifecycle (async polling, per-shot refunds). An agent has everything needed to invoke it correctly.

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% and all three parameters are documented in the schema itself. The description reinforces get_cost ('Do this first') and describes hinweis as adding 'a setting line for every shot', adding only marginal meaning beyond the schema's own wording.

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?

States a specific verb and resource — 'Generate SOUND EFFECTS for a whole sequence, shot by shot' — and clearly scopes the output to 'ONE sfx track in sequence length, bound to the sequence's sfx stem'. This is readily distinguishable from sibling sfx/dub/music tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Strong operational guidance: 'call with get_cost first', 'poll the job until done', and the clarifying constraint 'Shots come from the sequence itself, in export order and export length — no cut detection.' It does not, however, explicitly name sibling alternatives (e.g. lab_sfx or lab_dub) or state when a per-shot pass beats a single-clip approach.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources