PostFader V12 — FL Studio MCP Server

Overview Schema Source Related Servers Discussions Admin

plugin_list_parameters

Read-onlyIdempotent

Get a loaded plug-in's real controls, filtering out FL Studio's padded empty slots. Returns indices, names, values, and display text for use with plugin_set_parameter.

Instructions

List a loaded plug-in's real controls with their current values and text.

Read-only. FL reports a padded parameter count for VST plug-ins, often
thousands of empty slots; this walks the range inside FL and returns only
real controls, each with its index, name, normalized value, and display
text (which identifies unnamed controls). Check truncated before treating
the list as complete. Use the indices, names, or display text with
plugin_set_parameter.

Input Schema

TableJSON Schema

Name	Required	Description
`end`	No	Exclusive last index; defaults to FL's reported count.
`start`	No	First parameter index to examine; defaults to 0.
`target`	Yes	Loaded plug-in: {"kind": "mixer_effect", "track_index", "slot_index"} (Master also needs "allow_master": true) or {"kind": "channel_generator", "channel_index"}. Read targets with plugin_list_loaded.
`max_indices`	No	Stop after examining this many indices.
`max_results`	No	Stop after collecting this many real controls.

Output Schema

TableJSON Schema

Name	Required	Default
`plugin`	Yes
`scan_end`	Yes
`warnings`	No
`truncated`	Yes
`parameters`	Yes
`real_count`	Yes
`scan_start`	Yes
`observed_at`	Yes
`truncated_by`	No
`examined_count`	Yes
`schema_version`	No	1.0
`padding_skipped`	Yes
`observation_atomic`	No
`project_dirty_flag`	No
`highest_index_examined`	No
`reported_parameter_count`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv11.0.2Oct 5, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint), so the bar is lower, yet the description adds substantial non-obvious behavior: FL's padded parameter count (~thousands of empty VST slots), that the tool walks the range and filters to real controls only, and the caveat to check 'truncated' before treating results as complete. The note that display text identifies unnamed controls is likewise useful.

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?

Front-loaded purpose sentence, then behavioral explanation, then the downstream-tool pointer. Despite spanning three sentences, each carries distinct, load-bearing information (what it returns, the padding caveat, the truncated caveat, the follow-up tool) with no redundancy.

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?

The tool has an output schema, so return fields (index, name, value, display text, truncated) need not be re-explained. Given that, the description is complete: it covers purpose, the VST padding quirk, the truncation caveat, and how to chain into plugin_set_parameter.

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 explains start/end/max_indices/max_results and the discriminated target union; baseline is 3. The description only loosely gestures at the range-walking behavior ('walks the range inside FL'), which relates to start/end but adds no syntax or format detail beyond the schema.

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?

Starts with a specific verb+resource ('List a loaded plug-in's real controls with their current values and text') and qualifies it with 'real' to signal the padding-filtering behavior. An agent can distinguish it from siblings plugin_list_loaded (plug-ins themselves) and plugin_set_parameter (which it explicitly names as the downstream tool).

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?

It states the workflow context ('Use the indices, names, or display text with plugin_set_parameter'), which tells the agent this is the read step before a write, and the 'loaded plug-in' framing implies plugin_list_loaded precedes it. It does not, however, state explicit when-not-to-use conditions or contrast with other list_* tools beyond set_parameter.

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

Deploy Server