FilmLab

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

Name	Required	Description
`seq_id`	Yes	Sequence id (from lab_create_sequence/lab_list_sequences) — positive integer as string
`hinweis`	No	One 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_cost`	No	Return 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.
`nur_eigene_daten`	No	Only for a model that sends inputs to China or a US recipient without a documented basis, when the step carries images, clips, voices or faces. Means: this material shows or contains no real person other than the human using this account. Set it ONLY after the human has said exactly that for THIS step; never assume it, never reuse it for the next step. Not needed when the human has declared this material in the FilmLab app: the backend reads that declaration, also for material derived from it; only the app can store one. An LK reference, a licensed likeness or another person's agreement does not replace it. Without it the backend refuses with drittland_dritte_gesperrt before any charge; then use a non-gated model or text only.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

changedInput schema / properties / nur_eigene_daten / description

Previous value: -"Only for a model that sends inputs to China or a US recipient without a documented basis, when the step carries images, clips, voices or faces. Means: this material shows or contains no real person other than the human using this account. Set it ONLY after the human has said exactly that for THIS step; never assume it, never reuse it for the next step. An LK reference, a licensed likeness or another person's agreement does not replace it. Without it the backend refuses with drittland_dritte_gesperrt before any charge; then use a non-gated model or text only."New value: +"Only for a model that sends inputs to China or a US recipient without a documented basis, when the step carries images, clips, voices or faces. Means: this material shows or contains no real person other than the human using this account. Set it ONLY after the human has said exactly that for THIS step; never assume it, never reuse it for the next step. Not needed when the human has declared this material in the FilmLab app: the backend reads that declaration, also for material derived from it; only the app can store one. An LK reference, a licensed likeness or another person's agreement does not replace it. Without it the backend refuses with drittland_dritte_gesperrt before any charge; then use a non-gated model or text only."

Changed1 schema field changedNov 6, 2026

addedInput schema / properties / nur_eigene_daten

Added value: +{
+  "description": "Only for a model that sends inputs to China or a US recipient without a documented basis, when the step carries images, clips, voices or faces. Means: this material shows or contains no real person other than the human using this account. Set it ONLY after the human has said exactly that for THIS step; never assume it, never reuse it for the next step. An LK reference, a licensed likeness or another person's agreement does not replace it. Without it the backend refuses with drittland_dritte_gesperrt before any charge; then use a non-gated model or text only.",
+  "type": "boolean"
+}

Changed1 schema field changedOct 11, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedOct 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations only say readOnly=false, destructive=false; the description adds substantial context beyond that — muting and black-padding shots, only generated sound retained, the result being ONE sfx track bound to the sequence's sfx stem while other stems stay untouched, metadata key 'stuecke', credit pricing that includes padding, and refund behavior for failed shots and whole runs. It stops short of saying whether the existing sfx stem content is overwritten or appended, which is the one mutation detail an agent would still want.

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 every sentence carries operational substance (padding as sync marker, stuecke metadata, refunds, async polling). It is a single dense block that occasionally repeats schema text, e.g. the per-shot credit pricing restated alongside get_cost, but nothing is 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?

For an asynchronous, credit-consuming, sequence-mutating tool with no output schema, the description covers the return contract (job_id + polling), cost model, partial-failure and refund semantics, the prompt constraints sent to the model, and where results land. An agent has enough to call it correctly and to explain the outcome without further inspection.

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; the description earns an extra point by adding ordering semantics ('call with get_cost first') and by restating hinweis as 'adds a setting line for every shot', tying the parameter to the prompt construction described earlier. It does not add syntax beyond the schema, but it does clarify how the parameters interact with the run.

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 immediately distinguishes itself from single-shot sound tools by describing the whole pipeline: mute, pad, re-render with sound, keep only audio, stretch to original timing. A reader knows this is a sequence-level SFX pass, not a one-shot generate or a music/dub tool among the siblings.

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?

Gives explicit preconditions and routing: 'call with get_cost first', 'ASYNCHRONOUS: returns a job_id; poll the job', 'no cut detection' (shots come from the sequence in export order), and a concrete fallback when the data-residency gate refuses ('use a non-gated model or text only'). It also names the gated-model condition under which nur_eigene_daten is required.

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

All FilmLab tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?