PostFader V12 — FL Studio MCP Server

Overview Schema Source Related Servers Discussions Admin

playlist_set_track

Destructive

Set a Playlist track's name, color, mute, solo, or selection state in one call; only changed fields are written and verified (write mode required).

Instructions

Rename, recolor, mute, solo, or select one Playlist track in one call.

Set only the fields to change. Requires write mode. Name and color are written first, then mute/solo/selection, each read back on a later tick with its own receipt; verified is true only when both verified. Playlist clips cannot be created or moved through FL's scripting API. Does not save the project.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Absolute track name.
`color`	No	Absolute unsigned FL color word.
`muted`	No	Absolute mute state.
`soloed`	No	Absolute solo state.
`selected`	No	Absolute selection state; FL's toggle is sent at most once.
`track_index`	Yes	One-based Playlist track index.
`expected_before`	No	Optional current values from playlist_list_tracks for the fields this call changes; refuse if any changed.
`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
`track_index`	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?

Discloses non-obvious behavior well beyond the annotations: the two-phase write order (name/color first, then mute/solo/selection), per-field readback on a later tick with its own receipt, that 'verified' is true only when both verify, and that it does not save the project. Annotations (destructive, non-idempotent, open-world) are consistent with and enriched by this detail.

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-loads the verb+resource+scope, then layers prerequisites, sequencing, and the no-save caveat. Every sentence carries distinct information with no filler, though the middle sentence is dense and could be split for readability.

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 mutation tool with a full output schema, the description covers what an agent needs: prerequisites, field-selection semantics, multi-step write sequencing and verification, API limitations, and persistence behavior. Return values are 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 coverage is 100% so the baseline is 3, but the description adds meaning: 'Set only the fields to change' clarifies the nullable-default semantics of the five field params, and the write-ordering statement contextualizes how name/color vs mute/solo/selection are applied. It does not explain expected_before or session_fingerprint, which the schema already covers in detail.

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 specific verbs (rename, recolor, mute, solo, select) and the exact resource (one Playlist track) with the batching scope ('in one call'). An agent can distinguish it from playlist_list_tracks (read) and playlist_get_selection without opening either 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?

Gives clear prerequisites ('Requires write mode', 'Set only the fields to change') and a constraint ('Playlist clips cannot be created or moved through FL's scripting API'), which implicitly scopes what it is for. No explicit named alternative is offered, but no true sibling performs the same mutation, so the guidance is adequate without exclusions.

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

Deploy Server