PostFader V12 — FL Studio MCP Server

Overview Schema Source Related Servers Discussions Admin

channel_set_steps

Destructive

Set step-sequencer cells on or off for one channel in the current pattern; edits refuse if the grid no longer matches the expected digest, so nothing is overwritten blindly.

Instructions

Turn step-sequencer cells on or off for one channel in the current pattern.

Requires write mode and a fresh channel_get_steps read: the edit refuses if
the grid no longer matches expected_digest, so nothing is overwritten
blindly. Each changed cell is read back on a later tick and reported. Use
piano_roll_write_notes for pitched notes and lengths. Does not save.

Input Schema

TableJSON Schema

Name	Required	Description
`updates`	Yes	Absolute cell states, at most one per step index.
`channel_index`	Yes	Global Channel Rack index from channel_list.
`pattern_number`	Yes	FL's current pattern; the same value given to channel_get_steps.
`expected_digest`	Yes	Required digest from the latest channel_get_steps read of this grid.
`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
`applied_at`	Yes
`index_scope`	No	global
`channel_index`	Yes
`project_saved`	No
`bridge_command`	No	sequencer.set
`cells_verified`	Yes
`pattern_number`	Yes
`schema_version`	No	1.0
`expected_digest`	Yes
`requested_updates`	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.9/5.0

Behavior5/5

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

Annotations already declare destructive/no-idempotent, but the description adds the mechanism behind them: an expected_digest optimistic-concurrency guard that refuses the edit if the grid changed, readback of changed cells on a later tick, and that nothing is persisted. This is substantive behavior beyond the structured hints.

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?

Four tight sentences: purpose first, then prerequisites, then the guard's rationale, then the sibling pointer and the no-save caveat. No sentence is redundant.

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 values need not be spelled out; the description still notes changed cells are reported back. With a 5-param destructive tool, the prerequisites, guard, and no-save behavior are all present.

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 baseline is 3, but the description explains why expected_digest exists ('refuses if the grid no longer matches expected_digest') and ties the fresh-read requirement to it, adding meaning the schema field text does not convey.

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 ('turn ... on or off') and resource ('step-sequencer cells for one channel in the current pattern'), and explicitly differentiates from piano_roll_write_notes for pitched notes. An agent can place it precisely 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the preconditions (write mode plus a fresh channel_get_steps read), names the alternative tool and the condition selecting it ('for pitched notes and lengths'), and notes it does not save so the caller knows a save step follows.

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

Deploy Server