ableton-mcp

Overview Schema Source Related Servers Discussions Admin

copy_device_ab_slot

Destructive

Copies current Ableton device state to the other A/B slot when overwriteOtherSlot is true, discarding the target slot without backup or rollback.

Instructions

Request native copying of current device state over the other A/B slot. Requires explicit overwriteOtherSlot true; previous other-slot contents are not backed up. Binds native identity/current controls and refuses recording, frozen owner or active/unknown automation. Copy request is not hidden-state verification. No automatic rollback.

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.
`confirmationToken`	No	Single-use plan token.
`overwriteOtherSlot`	Yes	Explicit authority to discard the other native A/B slot; must be true.
`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"
+  }
+]

Addedv0.3.0Oct 19, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Goes well beyond the destructive/non-idempotent annotations: previous other-slot contents are not backed up, there is no automatic rollback, and the operation binds native identity/current controls. The refusal conditions (recording, frozen owner, active/unknown automation) are exactly the kind of behavioral 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.

Conciseness4/5

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

Front-loads the action and the destructive consequence, then packs preconditions and caveats into short declarative sentences. Four sentences with no filler, though the telegraphic phrasing ('Binds native identity/current controls') costs some clarity.

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?

Given a destructive mutation with an output schema and fully documented params, the description covers what matters: irreversibility, no backup, refusal states, and the verification caveat. It stops short of describing the dryRun/token workflow, but the schema carries that.

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 coverage is 100% and the schema already states overwriteOtherSlot 'must be true'; the description merely reinforces that requirement. It adds no detail on dryRun, planHash, confirmationToken, or expectedStateVersion beyond what the schema documents, so baseline 3 applies.

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: 'native copying of current device state over the other A/B slot.' It is clearly distinct from the sibling read/select tools (get_device_ab_context, select_device_ab_slot), but doesn't name them explicitly, so an agent must infer the relationship.

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

Usage Guidelines4/5

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

Gives concrete preconditions: overwriteOtherSlot must be explicitly true, and the call is refused during recording, frozen owner, or active/unknown automation. It also clarifies that the copy request 'is not hidden-state verification,' implying a separate verification step, though it doesn't direct the agent to the specific context tool to call first.

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

Deploy Server