PostFader V12 — FL Studio MCP Server

Overview Schema Source Related Servers Discussions Admin

run_execute

Destructive

Execute multi-step FL Studio production plans as one task: validate the plan, enable write mode, run operations in order with receipts, and stop at blockers for safe resumption.

Instructions

Run a multi-step production plan, such as writing a chorus, as one task.

The main path for work that spans several kinds of operation, such as
composing, writing notes, arranging, choosing sounds, and processing: it
validates the whole plan, checks readiness, enables write mode once for
the run, executes operations in order with per-operation receipts, and
releases write mode when finished. For edits already decided, use the
setters or project_apply_edits; to apply one result of processing_plan,
sound_plan_palette, or review_plan_revision, use that area's apply tool.
It stops at a blocker or an unknown outcome and reports the blocked
operation and a next step; resume with run_continue. Mutating plans need
authorized_to_modify=true. The run is saved locally and survives MCP
restarts. Never saves the project.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`plan`	Yes	{plan_id, operations}: ordered operations, each with a unique operation_id; get each operation's fields from run_describe_operations.
`request`	Yes	The task: brief, scope, preservation rules, allowed change categories, completion target, and authorized_to_modify=true when the user asked for project changes.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`run_id`	Yes
`status`	Yes
`summary`	Yes
`blockers`	No
`receipts`	No
`warnings`	No
`phase_plan`	No
`run_context`	No
`project_saved`	No
`timing_report`	No
`attempted_count`	Yes
`completed_count`	Yes
`creation_outcome`	No
`readiness_report`	No
`total_operations`	Yes
`generated_outputs`	No
`write_mode_active`	No
`rollback_attempted`	No
`session_fingerprint`	No
`project_state_digest`	No
`write_mode_enable_count`	No
`write_mode_disable_count`	No
`write_mode_shutdown_verified`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv12.0.3Oct 5, 2026
- changedOutput schema / $defs / ProcessingPlan / properties / missing_capabilities / maxItems
```
Previous value: -128New value: +256
```
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?

Annotations already flag destructive/non-idempotent/open-world, but the description adds substantial behavioral detail: it validates the whole plan, checks readiness, enables write mode once, executes in order with per-operation receipts, releases write mode, halts on blockers/unknown outcomes and reports the blocked operation plus a next step, persists the run across MCP restarts, and never saves the project. This goes well beyond the annotation surface.

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 layered with routing, prerequisites, and lifecycle behavior. Dense but each sentence carries distinct information; no filler. Slightly long for a single description, but no sentence is wasted.

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-value explanation is unnecessary, and the description instead covers the full behavioral envelope: preconditions, write-mode lifecycle, failure handling, resumption, and persistence. Nothing an agent needs to invoke it correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the request and plan structures in depth. The description restates the authorized_to_modify requirement (already in the schema) and adds the resume/run_continue notion, but contributes little parameter-specific meaning beyond what the schema provides.

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 specific verb ("Run") and resource ("multi-step production plan") with an illustrative example. It explicitly distinguishes itself from sibling paths (setters, project_apply_edits, per-area apply tools), so an agent can tell it apart without opening schemas.

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?

It states it is "the main path for work that spans several kinds of operation" and then gives explicit alternatives and their triggers: setters/project_apply_edits for already-decided edits, and each area's apply tool (processing_plan, sound_plan_palette, review_plan_revision) for single results. Resume routing to run_continue is also named.

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

Deploy Server