Skip to main content
Glama
synopsys0

PostFader V12 — FL Studio MCP Server

mixer_set_track

Destructive

Change one FL Studio mixer track's name, color, volume, pan, stereo separation, mute, solo, record arm, EQ bands, sends, or active selection in one write-mode call.

Instructions

Change any combination of one mixer track's settings in one call.

Set only the fields to change: name, color, volume (normalized or dB), pan,
stereo separation, mute, solo, record arm, built-in EQ bands, sends, and
whether it is the active track. Requires write mode
(session_set_write_mode). Writes run in that order, each read back on a
later FL tick with its own receipt; verified is true only when every write
verified. Non-atomic: earlier writes remain if a later one fails, and an
unknown outcome stops the rest. Use plugin_set_parameter for effect
parameters and project_apply_edits for several tracks. Does not save.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
eqNoBuilt-in three-band EQ changes, one entry per band.
panNoPan from -1 hard left through 0 centre to 1 hard right.
nameNoTrack name; "" restores FL's default name.
armedNoAbsolute recording-arm state.
colorNoFL color word, unsigned 0xAABBGGRR; FL may change the high byte.
mutedNoAbsolute mute state.
sendsNoSends to other tracks: create or remove a route with enabled, set its amount with level_normalized.
selectNoAlso make this the active (selected) mixer track, after the other changes.
soloedNoAbsolute solo state.
volume_dbNoFader target in dB; found by searching FL's fader curve, which moves the fader while it searches.
track_indexYesZero-based mixer index. Index 0 is Master and needs allow_master=true.
allow_masterNoDeliberately target Master at index 0.
tolerance_dbNoMaximum dB readback error; defaults to 0.1. Only with volume_db.
expected_beforeNoOptional current values from mixer_get_track for the fields this call changes; refuse if any changed. Guards for unchanged fields are refused.
stereo_separationNoFL stereo separation from -1 to 1.
volume_normalizedNoFader position 0..1; 0.8 is 0 dB. Use volume_db for decibels.
stop_on_unverifiedNoSkip the remaining writes after the first write whose readback did not verify. An unknown outcome always stops the sequence.
session_fingerprintNoOptional session_fingerprint from a recent read. The call refuses after a bridge reload or a reported project load. This is a concurrency guard, not authentication or a durable project identity.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultsYes
verifiedYes
warningsNo
completedYes
applied_atYes
track_indexYes
project_savedNo
skipped_countYes
skipped_stepsNo
schema_versionNo1.0
stopped_reasonNo
attempted_countYes
requested_countYes
rollback_attemptedNo
stop_on_unverifiedYes
session_fingerprintYes
automatic_replay_attemptedNo
one_session_preflight_completedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv11.0.2

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover the safety profile (destructive/non-idempotent/openWorld), and the description adds substantial context beyond them: writes execute in a stated order, each is read back on a later FL tick with its own receipt, verified is true only if all writes verify, the operation is non-atomic (earlier writes persist if a later one fails), and an unknown outcome halts the rest. This is exactly the behavioral detail an agent needs before invoking a destructive multi-write.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and field list, then adds verification/ordering semantics and sibling routing in descending priority. Dense but every sentence carries operational information; no 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?

An output schema exists, so return-shape explanation is unnecessary, yet the description still clarifies the receipt/verified model. For an 18-parameter destructive mutation with nested send/EQ guards, the description plus schema plus annotations give an agent everything needed to call 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 description coverage is 100% and the nested $defs document ranges, units, and guards thoroughly (volume_normalized '0.8 is 0 dB', color word layout, expected_before semantics). The description only re-enumerates the changeable fields and notes 'normalized or dB', adding little beyond the schema, so the baseline 3 is correct.

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+resource ('Change ... one mixer track's settings in one call') and enumerates the mutable field set, so an agent can distinguish it from mixer_get_track, plugin_set_parameter, and project_apply_edits without opening a 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?

Names two explicit alternatives and the conditions that select them ('Use plugin_set_parameter for effect parameters and project_apply_edits for several tracks'), plus the prerequisite 'Requires write mode (session_set_write_mode)' and the note that it 'Does not save.' Nothing is left to inference.

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

Deploy Server

Other Tools