Skip to main content
Glama

fx_set_preset

Set a plugin to a named preset on a given track's FX chain using the exact preset name. Raises an error if no change occurs; optionally returns parameters.

Instructions

Load preset by name. Returns the resulting preset, not the parameters.

The name must match the plugin's own spelling. Some plugins report names padded to a fixed width (e.g. KORG TRINITY pads to 16 chars), and the padded form is what has to be passed. Take the name from fx_get_preset or fx_navigate_preset rather than from REAPER's presets/*.ini, which stores it trimmed.

If the preset does not actually change, this raises instead of reporting success.

Args: track_index: 0-based track index. fx_index: 0-based FX chain index. preset_name: Preset name, exactly as the plugin reports it. include_params: Also return the plugin's full parameter list. Off by default — on large instruments that runs to tens of thousands of characters. Use fx_get_params when the parameters are what you actually want.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fx_indexYes
preset_nameYes
track_indexYes
include_paramsNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv0.6.7
    • addedInput schema / properties / include_params
      Added value: +{
      +  "default": false,
      +  "title": "Include Params",
      +  "type": "boolean"
      +}
  2. First observedv0.3.0

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries full burden. It discloses the return type (resulting preset), the raising behavior when no change, and the padding pitfall. It also warns about the large parameter list when include_params is enabled, providing comprehensive behavioral context.

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?

Description is concise despite length—every sentence adds value, from the core purpose to edge cases. Structured with an Args section that is front-loaded, and the most critical warning (padding) appears early. No fluff.

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 tool with no output schema and no annotations, the description provides everything needed to call it correctly: return semantics, error behavior, parameter details, and source for the name. It even covers the rare case of no change. Fully complete.

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 has 0% coverage, so description must explain all parameters. It does: track_index, fx_index, preset_name with exact spelling requirement, and include_params with default off and rationale. Each parameter's meaning and caveats are fully explained.

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?

Description clearly states it loads a preset by name and returns the resulting preset, contrasting with siblings like fx_get_preset. Differentiates itself explicitly by noting it returns the preset, not parameters, which distinguishes it from fx_get_params.

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?

Provides specific guidance: take the name from fx_get_preset or fx_navigate_preset rather than presets/*.ini, and use fx_get_params when parameters are desired. Also explains when include_params is appropriate, giving explicit alternatives and conditions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/xDarkzx/Reaper-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server