ableton-mcp

by cavi-ai

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

set_drum_pad_state

Destructive

Plan or mute/solo a specific populated Drum Rack pad by MIDI note using a guarded snapshot; does not assign sounds.

Instructions

Plan or mute/solo an exact populated Drum Rack pad by MIDI note with a guarded rack snapshot. Does not assign sounds to pads.

Input Schema

Name	Required	Description
`mute`	No	Mute pad.
`note`	Yes
`solo`	No	Solo pad.
`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.
`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"
+}

First observedv0.1.0Sep 23, 2026

TDQS

B3.4/5.0

Behavior3/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 the mutation risk is covered. The description adds that the change is made against a 'guarded rack snapshot' and offers a plan mode, but never explains the plan/token/hash confirmation workflow or what state the guard protects, which is the operationally important part.

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 sentences, front-loaded with the action and target, with the negative scope constraint second. Dense but no filler; 'Plan or mute/solo ... by MIDI note' packs three modes and an addressing scheme economically.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 explained, and the 4 required params are schema-documented. However, for a destructive, non-idempotent, concurrency-guarded (expectedStateVersion) mutation with a single-use token flow, the description leaves the safe-call sequence unstated.

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 89%, so the schema already documents mute, solo, dryRun, trackId, deviceId, planHash, confirmationToken and expectedStateVersion. The description contributes only the MIDI-note addressing concept, which is straightforward; baseline 3 is appropriate.

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 (plan / mute / solo) and resource (a populated Drum Rack pad addressed by MIDI note), plus an explicit scope exclusion ('Does not assign sounds to pads'). No sibling is named, but the drum-pad target makes it distinguishable from pattern-level tools like apply_drum_variation.

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 supplies a when-not ('Does not assign sounds to pads'), which helps rule out sample-assignment use, but never states when to use it versus the drum-pattern/variation siblings, nor that planning must precede execution. Usage is implied rather than directed.

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

Deploy Server