PostFader V12 — FL Studio MCP Server

Overview Schema Source Related Servers Discussions Admin

project_step_history

Destructive

Undo or redo exactly one step in FL Studio's project history, then verify the new position from the receipt before continuing.

Instructions

Undo or redo one step of FL Studio's project history and verify the move.

Requires write mode (session_set_write_mode). Moves exactly one step and
reads FL's history position back on a later tick; the receipt reports the
position before and after. FL's history covers every project change, not
only PostFader's, so read project_get_history first and guard with
expected_before. Does not save the project.

Input Schema

TableJSON Schema

Name	Required	Description
`direction`	Yes	undo moves one step back in FL's history; redo moves one step forward.
`expected_before`	No	Optional history position, count, and/or dirty flag from project_get_history; refuse if changed.
`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
`after`	Yes
`before`	Yes
`verified`	Yes
`warnings`	No
`direction`	Yes
`applied_at`	Yes
`project_saved`	No
`bridge_command`	Yes
`schema_version`	No	1.0
`requested_position`	Yes
`undo_point_created`	No
`verification_basis`	No	readback_on_a_later_fl_idle_tick
`session_fingerprint`	No
`verification_summary`	Yes
`expected_before_applied`	No
`session_precondition_applied`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv11.0.2Oct 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag destructive=true and readOnly=false, but the description adds substantial context beyond them: the write-mode prerequisite, that it moves exactly one step, that the position is read back on a later tick with a before/after receipt, that FL's history spans all project changes (not just PostFader's), and that it does not save the project. This is rich behavioral disclosure that the structured fields cannot carry.

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 action, then prerequisites and caveats in tight sentences. Slightly dense at four sentences, but each conveys a distinct operational fact (write mode, single-step, receipt timing, global history scope, no save) and none is 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?

With an output schema present, return values need not be explained, and the annotations carry the safety profile. The description still supplies the missing operational context an agent needs (write mode, ordering, guard, non-saving behavior), so nothing material is absent.

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; the description adds framing value by explaining why expected_before exists ('guard with expected_before') and that history is broader than PostFader's, which motivates the guard. It does not add syntax beyond the schema, so it stays below a 5.

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 pair (undo/redo) plus the resource (FL Studio's project history) and the exact scope ('one step'), with an added 'verify the move' clause. It clearly distinguishes itself from project_get_history, which it names as a prerequisite rather than a duplicate.

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 when-to-use context: requires write mode via session_set_write_mode, tells the agent to read project_get_history first, and instructs it to guard with expected_before. The preconditions and sequencing are spelled out rather than implied.

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

Deploy Server