Skip to main content
Glama
xDarkzx

ReaperMCP

by xDarkzx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

fx_set_preset

Load a preset by exact name onto a track's FX and retrieve the resulting preset. Specify track index, FX index, and preset name, with optional parameter output.

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, or -1 for the master track. 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.

  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

A4.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses naming pitfalls (padded names), the error behavior (raises if preset doesn't change), and the default behavior of include_params being off due to large output. It doesn't explicitly state whether loading is reversible or if it alters other state, but the critical behaviors are covered. This is above average for transparency.

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 well-structured and front-loaded with the key distinction (returns preset, not parameters). It then explains critical pitfalls and provides an Args section. Every sentence adds value—no fluff or 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?

For a preset-loading tool with potential naming issues and optional parameter output, the description covers all essential points: how to obtain the correct name, error conditions, and parameter inclusion trade-offs. It also references sibling tools for alternative use cases. No critical information is missing for correct invocation.

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 description coverage is 0%, so the description must fully explain parameters. It does: track_index (0-based, -1 for master), fx_index (0-based), preset_name (exact plugin spelling), and include_params (off by default, use fx_get_params instead). This adds substantial meaning beyond the schema's types and defaults.

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 clearly states the verb 'Load' and the resource 'preset by name,' and immediately distinguishes it by noting it returns the resulting preset, not the parameters. This separates it from sibling tools like fx_get_preset and fx_navigate_preset, which is a clear purpose statement.

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 provides explicit usage guidance: tells the agent to take the name from fx_get_preset or fx_navigate_preset rather than from REAPER's ini file, and advises using fx_get_params when parameters are desired instead of include_params. This clearly routes the agent to the correct alternative tools for different needs.

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