FilmLab

Set the Sound Mix

lab_mix

Idempotent

Set the sound mix of a sequence: per track volume_db, pan, mute, solo and effects. Every field you send is rendered — the backend rejects what it cannot render (422 with the reason), so a saved mix is the mix you hear. Tracks are the stems dialog, music, sfx, atmo, plus master (effects only: eq, compressor, limiter). Only the fields you send change; effects replaces that track's whole effect list. Effects: gate, eq, deesser, compressor, reverb, limiter — fixed order, one of each per track; give a preset (with its written reasoning), a one-knob knopf (0–1) or explicit values. Ducking is an effect too: {type:'ducking', quelle:'dialog', amount_db, attack_ms, release_ms} lowers this track while quelle is active. naht_ms (0–500) fades every seam between the clips of a stem with an equal-power fade — against clicks and room jumps at the cuts of a stem built from pieces; 0 = hard edges. The sfx stem of lab_ton_durchlauf comes with 30. Volume automation replaces the track's breakpoints {t_s, db}, in seconds from the sequence start, interpolated linearly in dB; [] clears it, and master does not support it. Call with katalog: true (and no tracks) to get every effect, its ranges and the presets with their reasoning. Any change discards the rendered mixdown. Changes state, costs nothing. Next: lab_mix_render, then lab_mix_messen.

Input Schema

TableJSON Schema

Name	Required	Description
`seq_id`	Yes	Sequence id — positive integer as string
`tracks`	No	Tracks to change — only the given fields are written
`katalog`	No	Return the effect catalogue instead of changing anything

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 16, 2026

addedInput schema / properties / tracks / items / properties / automation

Added value: +{
+  "description": "Volume breakpoints over time, seconds from sequence start, interpolated linearly in dB. Replaces the track's whole automation; [] clears it. Not on master.",
+  "items": {
+    "properties": {
+      "db": {
+        "maximum": 12,
+        "minimum": -60,
+        "type": "number"
+      },
+      "t_s": {
+        "minimum": 0,
+        "type": "number"
+      }
+    },
+    "required": [
+      "t_s",
+      "db"
+    ],
+    "type": "object"
+  },
+  "maxItems": 500,
+  "type": "array"
+}

Changed1 schema field changedOct 15, 2026

addedInput schema / properties / tracks / items / properties / naht_ms

Added value: +{
+  "description": "Fade at every seam between this stem's clips, 0–500 ms (0 = hard edges)",
+  "type": "number"
+}

Changed1 schema field changedOct 11, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
AddedOct 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only supply readOnly/idempotent/destructive hints; the description adds substantial behavior: 422 rejection of unrenderable fields, 'only the fields you send change', effects replacing the whole list, and 'Any change discards the rendered mixdown'. These are exactly the side-effect and validation facts an agent needs before writing.

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?

It is a dense single paragraph, but the core purpose and write semantics are front-loaded before the finer effect/automation details. Given the genuine complexity of the tool, nearly every clause earns its place, with only mild density/redundancy cost.

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?

There is no output schema, and the description compensates by explaining the katalog mode, the 422 error behavior, and the downstream render/measure tools. For a stateful multi-field mix tool with 100% schema coverage, nothing an agent needs to call it correctly is missing.

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 carries the field-level documentation (baseline 3). The description nonetheless adds real meaning beyond it: the ducking object shape, the fixed effect ordering and one-of-each rule, preset-vs-knopf-vs-explicit semantics, and that '[] clears it' for automation while master does not support it.

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?

The description opens with a precise verb+resource: 'Set the sound mix of a sequence'. It enumerates the five per-track fields and explicitly distinguishes itself from the sibling chain by naming 'Next: lab_mix_render, then lab_mix_messen', so an agent can place it in the workflow without opening the schema.

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?

It gives clear context for when to use it (setting a mix, and the 'katalog: true (and no tracks)' catalogue mode) and names the follow-on tools lab_mix_render and lab_mix_messen. It stops short of stating explicit when-not-to-use conditions, but the sequencing makes the role clear.

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?