ableton-mcp

Overview Schema Source Related Servers Discussions Admin

capture_session_scene

Destructive

Capture the currently playing Session combination as a named scene directly below the selected anchor and launch it immediately, preserving the live performance state.

Instructions

Natively capture AND immediately launch the currently playing Session combination as a named scene below the selected anchor. Binds sources/layouts and rechecks at undo entry. Requires playing transport, all explicit/implicit arms off, recording/count-in off and settled launches. Live can adjust copied start markers; verifies other exposed material and reports exact marker differences and playback separately. Full-row launch can affect Arrangement overrides and empty tracks. Partial work remains without rollback/replay. No rendered audio or mixer recall. Updated bridge; all profile.

Input Schema

Name	Required	Description
`name`	Yes	Explicit new scene name without controls.
`dryRun`	No	False executes with token and hash.
`planHash`	No	Plan hash.
`afterSceneId`	Yes	Exact selected scene ID from selection/scenes. Native action inserts below it and immediately launches the captured row.
`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"
+  }
+]

Addedv0.3.0Oct 19, 2026

TDQS

A4/5.0

Behavior5/5

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

Goes well beyond the destructiveHint=true/no-idempotency annotations by disclosing that partial work remains with no rollback or replay, that there is no rendered audio or mixer recall, that Live may adjust copied start markers, and that full-row launch can affect Arrangement overrides and empty tracks. These are exactly the side-effect details an agent needs before an irreversible write.

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

Conciseness3/5

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

Purpose is front-loaded, but the body is dense and contains cryptic fragments such as 'Updated bridge; all profile.' and 'Binds sources/layouts and rechecks at undo entry' that consume space without conveying actionable meaning. Sentence count is reasonable but not every clause earns its place.

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?

With an output schema present (so return values need no explanation) and annotations covering the safety profile, the description still supplies prerequisites and side effects. It is nearly complete; only the meaningless trailing fragments keep it from being fully adequate.

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 100%, so each of the six parameters is already documented in the schema and the baseline is 3. The description reinforces anchor placement ('below the selected anchor') and naming, but adds no semantics for dryRun, planHash or confirmationToken beyond what the schema states.

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 compound verb+resource: 'capture AND immediately launch the currently playing Session combination as a named scene below the selected anchor.' This clearly separates it from plain create_scene and launch_scene siblings. The phrasing is jargon-heavy but the action is still identifiable.

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 for when this is valid: 'Requires playing transport, all explicit/implicit arms off, recording/count-in off and settled launches.' That is real when-to-use guidance. It stops short of naming alternative tools (e.g. create_scene or launch_scene) for the cases those preconditions fail.

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

Deploy Server