Skip to main content
Glama

set_fx_preferences

Save per-category FX plugin preferences for mixing and mastering. Ensure the engine uses your chosen plugins when supported, falling back to best alternatives otherwise.

Instructions

Save user FX preferences — per-category plugin overrides.

Stored at %APPDATA%/reaper_mcp/fx_prefs.json (Windows) or ~/.reaper_mcp/fx_prefs.json (macOS/Linux). The mix and master pipelines apply a preference for eq, compressor, reverb and limiter when the engine has a parameter map for that plugin (REAPER's own ReaEQ / ReaComp / ReaVerbate / ReaLimit, and FabFilter Pro-Q 3 / Pro-C 2 / Pro-R / Pro-L 2). The response's engine_support says which of your preferences the engine can use; for any it can't, the engine uses the best supported plugin for that category and reports it in the mix result's preferences_ignored.

Args: preferences: JSON object mapping categories to plugin names, e.g. {"eq": "FabFilter Pro-Q 3", "compressor": "Waves SSL G-Master Buss Compressor", "reverb": "Valhalla VintageVerb", "limiter": "FabFilter Pro-L 2"}

Categories: eq, compressor, limiter, reverb, deesser, gate, saturator, multiband, stereo. Plugin names must match what REAPER reports (check fx_list_installed first).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
preferencesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries full responsibility and does a strong job: it discloses storage paths for Windows and macOS/Linux, explains which plugins the engine supports, and describes fallback behavior via `preferences_ignored`. It does not state whether saving merges with or overwrites existing preferences, which is a minor but relevant gap.

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 front-loaded with a one-line summary, then covers storage, engine behavior, and the argument format. Despite its length, every paragraph adds necessary semantics that are absent from the schema and annotations, with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description covers the essential invocation context: persistence location, supported categories, plugin support matrix, and fallback behavior. It is missing merge/overwrite semantics, but an agent can still call the tool correctly with the information provided.

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

Parameters5/5

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

Schema coverage is 0% and the schema only says `preferences` is a string, so the description must fully define the parameter. It does: JSON object mapping categories to plugin names, a concrete example, the full list of allowed categories, and the validation rule to use names as REAPER reports them.

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 specific verb and resource: 'Save user FX preferences — per-category plugin overrides.' It clearly identifies what the tool does and distinguishes itself from FX-application tools by stating it stores preferences for the mix and master pipelines rather than applying effects directly.

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?

The description gives clear context: preferences apply to mix and master pipelines, and it explicitly tells the agent to check `fx_list_installed` first to ensure plugin names match REAPER. It does not explicitly list when-not-to-use it or name alternatives like `setup_fx_chain`, so it stops short of full routing guidance.

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