Skip to main content
Glama
synopsys0

PostFader V10 — FL Studio MCP Server

by synopsys0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

fl_set_plugin_param_option

Destructive

Set a word-based plugin parameter (Key, Scale, Input Type) by matching its option label; sweeps the control to enumerate choices and restores prior value if no match.

Instructions

Set a parameter that shows words rather than numbers: Key, Scale, Input Type.

Use this where `fl_set_plugin_param_display` refuses. That tool searches on
a number, and an enumeration has none.

**This moves the control while it looks.** FL cannot report a control's
options, so the only way to find them is to walk the parameter across its
range and read what it displays. The requested label must exactly match an
option, ignoring case. If it does not exist, the original value is restored
before the error, and the error lists every option that was found.

The result carries `options` -- the whole enumeration, in order -- so one
call is also how you discover what a control accepts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
optionYesThe exact option text to land on, e.g. 'A', 'Major', 'Low Male'.
targetNoExplicit mixer_effect or global channel_generator target. Mutually exclusive with legacy track_index/slot_index.
parameterYesParameter index, or text matched against names and displays.
slot_indexNoLegacy zero-based effect slot 0 through 9. Supply it with track_index, or use target, never both.
sweep_stepsNoSweep resolution. Raise it only if an option is being missed.
track_indexNoLegacy zero-based mixer index. Supply it with slot_index, or use target, never both.
allow_masterNoRequired to target mixer track 0.
expected_beforeNoOptional expected normalized value and/or exact display text; refuse if any supplied field changed.
session_fingerprintNoOptional bridge/project-session fingerprint from a recent read. The write refuses after bridge reload or a reported project load. This is a concurrency guard, not authentication or a durable project identity.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv10.0.0

TDQS

A4.9/5.0
Behavior5/5

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

The description discloses a major side effect beyond the annotations: the tool moves the control while it looks, because FL cannot report options. It also explains exact-match case-insensitive matching, restoration of the original value on failure, and that errors list all found options.

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?

The description is compact, front-loads the purpose, and uses bold to call out the key side effect. Every sentence contributes either selection guidance, behavioral disclosure, or discovery semantics with no 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?

For a complex mutation tool, the description covers the mechanism, failure mode, restoration guarantee, and options-discovery behavior. The rich schema and output schema handle the remaining parameter and return details.

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 schema carries most parameter meaning; the baseline is 3. The description adds value by clarifying that the option must exactly match a label ignoring case and that one call doubles as a discovery mechanism returning the whole options list.

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 description opens with a precise action and resource: setting a parameter that displays words rather than numbers, with concrete examples (Key, Scale, Input Type). It also distinguishes the tool from fl_set_plugin_param_display by naming the sibling and stating the exact condition that selects this tool.

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 explicitly instructs to use this tool where fl_set_plugin_param_display refuses, and explains why: that tool searches on a number while an enumeration has none. This gives an agent both a positive and a negative selection rule.

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

Deploy Server

Other Tools