PostFader V12 — FL Studio MCP Server

Overview Schema Source Related Servers Discussions Admin

transport_set

Destructive

Change FL Studio transport settings like playback, recording, tempo, and loop mode by setting absolute states in a defined order with verification.

Instructions

Change playback, recording, tempo, loop mode, and other transport settings.

Set only the fields to change; each is an absolute state, never a toggle.
Requires write mode. Writes run in a fixed order so one call can stop,
adjust, and restart: stop/pause and recording-off first; then tempo, time
signature, loop mode, metronome, precount, and position; then recording-on;
then playback last. Each write gets its own later-tick receipt, and
verified is true only when all of them verified. Non-atomic: earlier writes
remain if a later one fails. Read the current state with
project_get_summary. Does not save the project.

Input Schema

TableJSON Schema

Name	Required	Description
`stop`	No	Stop playback and rewind to the start, like FL's Stop button. Not combined with playing or position_normalized.
`playing`	No	Absolute playback state: true plays, false pauses in place.
`precount`	No	Absolute count-in-before-recording state.
`loop_mode`	No	Pattern or Song mode.
`metronome`	No	Absolute metronome state.
`recording`	No	Absolute transport record-arm state.
`tempo_bpm`	No	Project tempo in BPM. FL needs playback stopped and recording off.
`expected_before`	No	Optional current values from project_get_summary for the settings this call changes; refuse if any changed. Guards for unchanged settings are refused.
`position_tolerance`	No	Maximum position readback error; defaults to 0.0001. Only with position_normalized.
`stop_on_unverified`	No	Skip the remaining writes after the first write whose readback did not verify. An unknown outcome always stops the sequence.
`position_normalized`	No	Playhead position, 0 start to 1 end. FL needs playback stopped.
`session_fingerprint`	No	Optional 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.
`time_signature_numerator`	No	Beats per bar. FL exposes no denominator.

Output Schema

TableJSON Schema

Name	Required	Default
`results`	Yes
`verified`	Yes
`warnings`	No
`completed`	Yes
`applied_at`	Yes
`project_saved`	No
`skipped_count`	Yes
`skipped_steps`	No
`schema_version`	No	1.0
`stopped_reason`	No
`attempted_count`	Yes
`requested_count`	Yes
`rollback_attempted`	No
`stop_on_unverified`	Yes
`session_fingerprint`	Yes
`automatic_replay_attempted`	No
`one_session_preflight_completed`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv11.0.2Oct 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=false), the description discloses the exact write ordering, that writes are non-atomic with earlier writes persisting on later failure, per-write receipt behavior, the meaning of 'verified', and that the project is not saved. This is precisely the behavioral context annotations cannot express.

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?

The opening sentence front-loads purpose and the remaining sentences each carry distinct operational facts (write ordering, receipts, non-atomicity, read path). It is dense but not padded. Slightly long, but every clause earns its place.

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 a 13-parameter mutation tool with an output schema, the description covers the mutation semantics, ordering, failure modes, prerequisite write mode, and the read alternative. Nothing material an agent needs to call it correctly is missing, and return-value detail is appropriately left to the output schema.

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 description coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it stresses that each field is an absolute state rather than a toggle, that stop is exclusive with playing/position, and that tempo and position require playback stopped. These cross-parameter constraints are real added value.

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 states a specific verb and resource ('Change playback, recording, tempo, loop mode, and other transport settings') and enumerates the exact field groups it mutates. It is clearly distinguishable from read-oriented siblings like project_get_summary, which it explicitly names as the way to read state. An agent can identify this as the transport-mutation tool 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 concrete usage conditions: 'Set only the fields to change; each is an absolute state, never a toggle' and 'Requires write mode'. It also routes reading to project_get_summary. It stops short of explicit when-not-to-use exclusions, but the guidance is strong enough that an agent knows the correct invocation pattern.

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

Deploy Server