Retrieve a specific FX plugin parameter value from a track, returning the current value along with its minimum and maximum range for use in REAPER DAW mixing and automation.
Get a specific parameter value of an FX plugin.
Returns: Object with value, min, max for the parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| fx_index | Yes | ||
| param_index | Yes | ||
| track_index | Yes |
Changes observed during successful MCP inspections.
v1.7.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does add genuinely useful behavior not available elsewhere by stating the return shape (value, min, max), which compensates for the missing output schema, but it omits index validity/error behavior and any confirmation that this is a pure read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and followed by the return shape; nothing is wasted. It is arguably under-specified rather than padded, but as written it is tight and well ordered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter read tool with no output schema, the description supplies the one thing structured fields don't - the return object shape. However it leaves unresolved the track-vs-take FX distinction, index semantics, and the typical call sequence (get count, get name, then get param), so it is only minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and all three required parameters (track_index, fx_index, param_index) are bare integers with no descriptions. The description only implies that 'param_index' selects 'a specific parameter' and says nothing about index bases, zero- vs one-based indexing, or the meaning of track_index/fx_index, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource ('Get a specific parameter value of an FX plugin') and the tool name confirms scope. It is clear what it does, but it never distinguishes itself from the near-identical sibling take_fx_get_param (take vs track FX) or from track_fx_get_param_name/num_params, so an agent must infer the routing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of prerequisites (e.g. a valid track/fx must exist), and no pointer to alternatives such as track_fx_get_num_params to iterate, track_fx_get_param_name to identify a parameter, or take_fx_get_param for take-level FX. The agent gets no help choosing among ~150 siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.