Skip to main content
Glama
synopsys0

PostFader V12 — FL Studio MCP Server

by synopsys0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

sound_plan_palette

Read-onlyIdempotent

Plan a sound palette by assigning instruments and presets to musical roles from your loaded inventory, returning scored, deterministic assignments you can review before applying.

Instructions

Choose an instrument and preset for each musical role from loaded sounds.

Read-only: reads the live inventory and returns deterministic assignments
with score reasons and a palette_id, without changing FL or history. With
base_palette_id it plans a variation for a later section instead, keeping
the base palette's anchors except replace_roles. Explicit roles and
preferences override genre defaults. Review the plan, then apply it with
sound_apply_palette before writing notes, so parts fit the chosen sounds.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestYesThe brief, roles to fill, creative direction, preferences, exclusions, and history policy.
sectionNoSection the variation is for, such as chorus. Variation only.
replace_rolesNoRoles a variation may replace; other anchors are kept. Variation only.
base_palette_idNoPlan a section variation of this existing palette instead of a new palette.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv11.0.2

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, but the description adds real context: the plan is deterministic, it returns score reasons and a palette_id, and it leaves FL state untouched. One tension is left unresolved — it claims no change to 'history' while the schema's persist_history defaults to true, which an agent should have clarified.

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 purpose, then behavior, then variation mode, then workflow — a sensible order with no filler. It is slightly dense across four sentences, and the closing workflow sentence repeats guidance already implied, but nothing 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?

For a complex planning tool with an output schema, the description covers what matters: it is a read-only planner, it is deterministic, it returns a palette_id and score reasons, and the result must be applied via sound_apply_palette. Nothing an agent needs to invoke it correctly is missing.

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 baseline is 3; the description goes beyond the schema by explaining the variation semantics of base_palette_id (keeps the base palette's anchors except replace_roles) and by tying section/replace_roles to variation-only use. It still says nothing about the large request object's key knobs, but the schema carries those.

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 concrete verb+resource ('Choose an instrument and preset for each musical role') and immediately names the sibling it hands off to (sound_apply_palette). An agent can distinguish it from sound_get_inventory, sound_get_palette, and sound_apply_palette without opening any 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 explicit sequencing ('Review the plan, then apply it with sound_apply_palette before writing notes'), an explicit mode switch ('With base_palette_id it plans a variation for a later section instead'), and a precedence rule ('Explicit roles and preferences override genre defaults'). The when-to-use and the alternative are both spelled out.

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