ableton-mcp

Overview Schema Source Related Servers Discussions Admin

ungroup_tracks

Destructive

Remove a native Group in Ableton Live and promote its child tracks to the parent or root, removing the group processing stage.

Instructions

Remove one native Group through macOS English Live UI, promoting its children to the enclosing Group or root. Removes its processing/mixer stage, shifts IDs and numbered labels, and can change sound/routing. Saved Set, stopped transport/recording, unarmed/unfrozen descendants and visible Group required. Refuses exposed external dependencies. Group devices require allowContent. Verifies retained descendants and exposed controls. No automatic undo/regrouping. Retain ungroupingId before execution. All profile.

Input Schema

Name	Required	Description
`dryRun`	No	False executes with token and hash.
`planHash`	No	Plan hash.
`allowContent`	No	Allow discarding the Group device chain; does not preserve hidden plug-in state.
`groupTrackId`	Yes	ID from list_tracks.
`confirmationToken`	No	Single-use plan token.
`expectedStateVersion`	Yes	Observed stateVersion.
`expectedSetFingerprint`	Yes	Current Set fingerprint.

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.3/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, and the description adds substantial context beyond them: the processing/mixer stage is discarded, IDs and numbered labels shift, sound/routing can change, retained descendants are verified, and there is 'No automatic undo/regrouping'. That is a complete risk picture for a destructive mutation.

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?

The action and its scope are front-loaded, followed by preconditions and hazards; nearly every clause carries information. It reads as a dense run-on paragraph rather than structured sentences, which costs a point on scanability.

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?

For a destructive, non-idempotent mutation with an output schema, the description covers preconditions, side effects, verification, and the absence of undo. The one dangling item is 'Retain ungroupingId before execution' — ungroupingId is not a parameter and the description never says which sibling (get_track_ungrouping_status) produces it.

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%, so the baseline is 3. The description adds one genuinely new semantic — that allowContent is required when the Group carries devices — but says nothing about how expectedStateVersion, expectedSetFingerprint, planHash, or confirmationToken relate to the dry-run/execute flow.

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 and resource ('Remove one native Group'), names the execution channel ('macOS English Live UI'), and describes the outcome ('promoting its children to the enclosing Group or root'). This clearly separates it from the sibling group_tracks, which does the inverse.

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?

Preconditions are explicit and actionable: 'Saved Set, stopped transport/recording, unarmed/unfrozen descendants and visible Group required', plus 'Refuses exposed external dependencies' and 'Group devices require allowContent'. It falls short of a 5 because it never names the alternatives an agent should consider first (get_track_ungrouping_status to obtain the plan, or group_tracks to reverse the operation).

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

Deploy Server