ableton-mcp

Overview Schema Source Related Servers Discussions Admin

set_device_parameters

Destructive

Plan and apply bounded Ableton device parameter changes on tracks, returns, or master using exact labels or native values. Looper Record/Overdub writes mutate audio.

Instructions

Plan/set bounded device parameters on ordinary/Return/Main tracks. Strings select exact unambiguous quantized labels; numbers retain native clamping. Looper State Record/Overdub writes mutate recorded content: restoring a parameter does not restore captured audio.

Input Schema

Name	Required	Description
`dryRun`	No	False executes with token and hash.
`changes`	Yes	Parameter changes.
`trackId`	Yes	track-N from list_tracks, return-N from get_set_mixer, or master.
`deviceId`	Yes	ID from list_devices.
`planHash`	No	Plan hash.
`confirmationToken`	No	Single-use plan token.
`expectedStateVersion`	Yes	Observed stateVersion.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.1Oct 23, 2026

removedOutput schema / additionalProperties
```
Removed value: -true
```

addedOutput schema / anyOf

Added value: +[
+  {
+    "oneOf": [
+      {
+        "properties": {
+          "confirmation": {
+            "properties": {
+              "expiresAt": {
+                "type": "number"
+              },
+              "planHash": {
+                "pattern": "^[a-f0-9]{64}$",
+                "type": "string"
+              },
+              "token": {
+                "minLength": 1,
+                "type": "string"
+              }
+            },
+            "required": [
+              "token",
+              "planHash",
+              "expiresAt"
+            ],
+            "type": "object"
+          },
+          "dryRun": {
+            "const": true
+          },
+          "plan": {
+            "type": "object"
+          }
+        },
+        "required": [
+          "dryRun",
+          "plan",
+          "confirmation"
+        ],
+        "type": "object"
+      },
+      {
+        "properties": {
+          "dryRun": {
+            "const": false
+          },
+          "operationOutcome": {
+            "properties": {
+              "evidence": {
+                "items": {
+                  "type": "string"
+                },
+                "type": "array"
+              },
+              "reason": {
+                "type": "string"
+              },
+              "schemaVersion": {
+                "const": 1
+              },
+              "status": {
+                "enum": [
+                  "applied",
+                  "outcome_unknown",
+                  "postconditions_failed",
+                  "pending_postconditions",
+                  "pending_user_action"
+                ]
+              }
+            },
+            "required": [
+              "schemaVersion",
+              "status",
+              "reason",
+              "evidence"
+            ],
+            "type": "object"
+          }
+        },
+        "required": [
+          "dryRun",
+          "operationOutcome"
+        ],
+        "type": "object"
+      }
+    ],
+    "properties": {
+      "dryRun": {
+        "type": "boolean"
+      }
+    },
+    "required": [
+      "dryRun"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "error": {
+        "properties": {
+          "message": {
+            "type": "string"
+          },
+          "outcome": {
+            "enum": [
+              "unknown",
+              "not_executed"
+            ]
+          }
+        },
+        "required": [
+          "message",
+          "outcome"
+        ],
+        "type": "object"
+      }
+    },
+    "required": [
+      "error"
+    ],
+    "type": "object"
+  }
+]

Changed8 schema fields changedv0.3.0Oct 19, 2026

changedInput schema / properties / changes / items / properties / id / description

Previous value: -"Stable parameter ID returned by list_device_parameters."New value: +"ID from list_device_parameters."

changedInput schema / properties / confirmationToken / description

Previous value: -"Short-lived, single-use token returned by the matching dry run."New value: +"Single-use plan token."

changedInput schema / properties / deviceId / description

Previous value: -"Stable device ID returned by list_devices."New value: +"ID from list_devices."

changedInput schema / properties / dryRun / description

Previous value: -"Omit or true to return a plan; false requires a valid confirmationToken."New value: +"False executes with token and hash."

changedInput schema / properties / expectedStateVersion / description

Previous value: -"Exact stateVersion observed immediately before planning."New value: +"Observed stateVersion."

changedInput schema / properties / planHash / description

Previous value: -"Hash returned by the matching dry run."New value: +"Plan hash."

changedInput schema / properties / trackId / description

Previous value: -"Stable device-owner ID: track-N from list_tracks, return-N from get_set_mixer, or master."New value: +"track-N from list_tracks, return-N from get_set_mixer, or master."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

Changed3 schema fields changedv0.2.0Sep 30, 2026
- changedInput schema / properties / changes / items / properties / value / description
```
Previous value: -"Requested value; clamped to live bounds."New value: +"Native numeric value or exact observed quantized choice label from list_device_parameters."
```
- addedInput schema / properties / changes / items / properties / value / oneOf
```
Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "string"
+  }
+]
```
- removedInput schema / properties / changes / items / properties / value / type
```
Removed value: -"number"
```
First observedv0.1.0Sep 23, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare destructive=true and non-idempotent, so the safety bar is partly met. The description adds real behavioral value beyond them: strings select exact quantized labels while numbers are natively clamped, and critically that Looper State Record/Overdub writes mutate recorded audio that restoring a parameter will not recover. That irreversible-effect warning is exactly the kind of context annotations cannot convey.

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?

Three dense sentences with no filler, front-loaded with the action and scope before the value-typing rule and the destructive caveat. Every clause carries distinct information.

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?

Output schema and annotations are present, so return values and the safety profile need not be restated here. For a 7-param destructive mutation tool the description covers scope, value typing and the irreversibility caveat well; the main remaining gap is the plan/execute token workflow, which the schema only hints at.

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, but the description adds meaning beyond the schema by explaining the string-vs-number value contract ('exact unambiguous quantized labels' vs 'native clamping') rather than merely repeating the property descriptions. It does not, however, explain the planHash/confirmationToken/expectedStateVersion sequencing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb+resource ('set bounded device parameters') and constrains scope to 'ordinary/Return/Main tracks,' which distinguishes it from session-object and mixer siblings. It stops short of naming the closest alternatives such as set_device_parameter_display or override_parameter_automation, so an agent still has to infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The dual 'Plan/set' phrasing implies a dry-run-then-commit flow, and the string/number clause implies how to supply values, but neither is stated as an explicit when-to-use rule. No sibling is named as an alternative and no precondition (like 'call list_device_parameters first') is spelled out.

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

Deploy Server