AbletonMCP

Overview Schema Source Related Servers Discussions Admin

set_master_device_parameter

Idempotent

Change any enabled parameter on a device in the master track's chain. Accepts native numbers (clamped), exact enum labels, or unit display strings like '250 Hz'; invalid mappings fail before writing.

Instructions

Set one enabled parameter on a device in the Master track's chain.

Call get_master_device_parameters first and use its parameter name/index and native min/max; numeric out-of-range values are clamped. Display strings with supported units or exact enum labels also work; unsupported mappings fail before writing. This affects the full mix. Read back the resulting display. Use set_device_parameter for a regular track or set_return_device_parameter for a return track.

Input Schema

TableJSON Schema

Name	Required	Description
`value`	Yes	Native number (clamped/quantized), exact enum label, or display text with Hz/kHz/ms/s/dB/% units, e.g. '250 Hz'. Unsupported mappings fail before writing.
`parameter`	Yes	Parameter name or zero-based parameter index returned by the matching get_*_device_parameters tool.
`device_index`	Yes	Zero-based device position in the target track's device chain.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.8.0Sep 6, 2026

addedInput schema / properties / value / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "string"
+  }
+]

changedInput schema / properties / value / description

Previous value: -"Value in the parameter's native range; the server clamps it to the min/max reported by the matching get_*_device_parameters tool."New value: +"Native number (clamped/quantized), exact enum label, or display text with Hz/kHz/ms/s/dB/% units, e.g. '250 Hz'. Unsupported mappings fail before writing."

removedInput schema / properties / value / type
```
Removed value: -"number"
```

Changed4 schema fields changedv1.7.3Jul 14, 2026

addedInput schema / properties / device_index / description

Added value: +"Zero-based device position in the target track's device chain."

addedInput schema / properties / device_index / minimum
```
Added value: +0
```

addedInput schema / properties / parameter / description

Added value: +"Parameter name or zero-based parameter index returned by the matching get_*_device_parameters tool."

addedInput schema / properties / value / description

Added value: +"Value in the parameter's native range; the server clamps it to the min/max reported by the matching get_*_device_parameters tool."

First observedv1.0.0Jul 11, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations (idempotentHint=true, destructiveHint=false) cover safety, and the description layers meaningful behavioral detail on top: out-of-range numerics are clamped, unsupported mappings fail atomically before any write, and 'This affects the full mix' warns of global scope. It even suggests a verification workflow ('Read back the resulting display'). No contradiction with annotations.

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?

Four sentences, every one earning its place: scope, prerequisite + numeric behavior, string/enum behavior + failure atomicity + mix impact, and sibling routing. The most decision-relevant constraint (Master track chain) is front-loaded, and there is zero tautology or filler.

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?

Complexity is moderate (3 required params, dual number/string value handling, no enums), and an output schema exists so return values need not be explained. The description covers the prerequisite call, accepted value forms, clamping, failure mode, scope impact, and verification step. Nothing an agent needs to invoke this 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 coverage is 100%, so the baseline is 3, and the schema already documents value formats and clamping. The description adds workflow semantics beyond the schema: it ties the parameter and device_index values to the output of get_master_device_parameters and instructs the agent to use native min/max from that call. That supplemental guidance merits a 4 rather than the baseline.

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 specific verb-resource pair: 'Set one enabled parameter on a device in the Master track's chain.' The scope qualifier 'in the Master track's chain' and 'one enabled parameter' precisely delimit the operation. The final sentence also names the two siblings it is not (set_device_parameter, set_return_device_parameter), so an agent can disambiguate immediately.

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 an explicit precondition ('Call get_master_device_parameters first') and tells the agent what to harvest from it (parameter name/index and native min/max). It also states concrete exclusions: 'Use set_device_parameter for a regular track or set_return_device_parameter for a return track.' No inference is required.

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

Deploy Server