PostFader V12 — FL Studio MCP Server

Overview Schema Source Related Servers Discussions Admin

project_apply_edits

Destructive

Apply pre-decided edits across multiple FL Studio targets in one call — mixer, channel, pattern, Playlist, plug-in parameters, or tempo — each with its own receipt.

Instructions

Apply edits you have already decided, across several targets, in one call.

Each item sets an absolute value on a mixer track, channel, pattern,
Playlist track, plug-in parameter, or the tempo, in order, after one
session check; mixer_plan_gain_staging returns items in this form. For
several fields of one target, its setter (mixer_set_track, channel_set) is
simpler. It does not apply plans: processing_apply, sound_apply_palette,
and review_apply_revision apply their own planner's result, and
run_execute runs multi-step work. Requires write mode. Every attempted item
gets its own later-tick receipt. The batch is non-atomic: earlier changes
remain if a later item fails, and an unknown outcome stops it. Inspect each
receipt and never replay an ambiguous batch. No rollback or project save is
performed.

Input Schema

TableJSON Schema

Name	Required	Description
`operations`	Yes	Ordered absolute writes. Each needs a unique operation_id and an operation that selects its fields (mixer_volume_db, channel_mix, plugin_parameter, pattern_length, tempo, and others); no two items may write the same field. Mixer index 0 needs allow_master=true.
`stop_on_unverified`	No	Skip the remaining writes after the first write whose readback did not verify. An unknown outcome always stops the sequence.
`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.

Output Schema

TableJSON Schema

Name	Required	Default
`results`	Yes
`verified`	Yes
`warnings`	No
`completed`	Yes
`applied_at`	Yes
`project_saved`	No
`skipped_count`	Yes
`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

Behavior4/5

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

Goes well beyond annotations: requires write mode, one session check, per-item later-tick receipts, non-atomic behavior (earlier changes persist on later failure), stop-on-unknown-outcome, and no rollback or project save. This is rich disclosure aligned with destructiveHint=true and idempotentHint=false; only the exact receipt content/shape is left unspecified.

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 purpose, then grouped into item shape, alternatives, preconditions, and failure semantics. Dense but every sentence carries information; only marginal tightening (e.g. merging the write-mode and alternatives notes) would improve it.

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 32-item non-atomic batch mutator, the description covers ordering, preconditions, failure semantics, and non-idempotency, while the schema and output schema (receipts) carry parameter and return detail. An agent has everything needed to invoke and to reason about recovery.

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, but the description adds conceptual framing — ordered absolute writes, one receipt per operation_id, uniqueness of fields, and the allow_master caveat for mixer index 0 — that helps an agent construct the operations array. It does not document every variant's fields, which the schema already does.

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 first sentence states a precise verb + scope: 'Apply edits you have already decided, across several targets, in one call.' It then enumerates the write domains (mixer track, channel, pattern, Playlist track, plug-in parameter, tempo), so an agent can immediately tell this apart from single-target setters and plan-apply tools.

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?

Explicit routing: use mixer_plan_gain_staging output as input, prefer mixer_set_track/channel_set for several fields of one target, and avoid this tool for planner results (processing_apply, sound_apply_palette, review_apply_revision) or multi-step work (run_execute). When-to-use, when-not, and alternatives are all named.

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

Deploy Server