ableton-mcp

Overview Schema Source Related Servers Discussions Admin

recall_rack_macro_variation

Destructive

Recalls an existing rack macro variation by zero-based index to restore its saved parameter state. Use it to switch sounds reliably while binding the exact rack and confirming observed values after recall.

Instructions

Plan or recall one existing rack macro variation by zero-based index. Binds exact rack and current parameter state; Live exposes observed values after recall, not the saved variation contents beforehand.

Input Schema

Name	Required	Description
`dryRun`	No	False executes with token and hash.
`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.
`variationIndex`	Yes
`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"
+  }
+]

Changed7 schema fields changedv0.3.0Oct 19, 2026

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"
+}

Addedv0.2.0Sep 30, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so safety is covered. The description adds real value beyond that: it explicitly states the tool 'Binds exact rack and current parameter state' (the state-version guard) and warns that 'Live exposes observed values after recall, not the saved variation contents beforehand', which tells the agent there is no preview of what will be restored.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences, with the primary action front-loaded ahead of the behavioral caveat. No filler, though the second sentence is dense and packs both the state-binding and the no-preview caveat into one clause.

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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. The description still supplies the one piece an agent would otherwise miss — that the saved variation contents are not visible before recall — making it complete for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 86%, so the baseline is 3. The description's only semantic addition is 'zero-based index' for variationIndex, which is largely already implied by the schema's 'minimum: 0'. It adds little beyond what the structured fields already convey.

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?

States a specific verb and resource — plan or recall a rack macro variation — with the qualifying scope 'by zero-based index' and 'one existing'. This distinguishes it from store_rack_macro_variation and delete_rack_macro_variation without naming them, but the verb+resource pair is unambiguous.

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 description implies two modes ('Plan or recall') that map to the dryRun parameter but never states the condition for choosing plan vs execute, nor when to prefer this tool over the store/delete siblings. Usage is inferable but not 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