ableton-mcp

Overview Schema Source Related Servers Discussions Admin

record_session_arrangement

Destructive

Record Session clip and scene choices into an empty Arrangement tail after existing clips, then start and verify Arrangement record/playback.

Instructions

Record Session clip/scene choices into an empty Arrangement tail after all existing clips. Requires stopped playback, playhead already at a native bar start aligned with the global launch grid, all explicit/implicit arms off, loop/punch/automation arm/Session recording off and supported count-in. Sets and verifies the insert marker at startBeats, then starts global Arrangement record/playback; leaves that marker at the start. Native display ticks request both stopped at endBeats or 300 seconds while scope remains owned, even after client disconnect. Tempo/meter and Session choices may change; track/arm/insert-marker/recording control changes relinquish cleanup. Retains partial clips and endpoint overhang; no exact timing, rendered audio, input or gesture-automation proof. Updated bridge; all profile.

Input Schema

Name	Required	Description
`dryRun`	No	False executes with token and hash.
`endBeats`	Yes	Requested stop beat; increasing span at most 512 beats and 300 seconds at current tempo.
`planHash`	No	Plan hash.
`startBeats`	Yes	Prepared playhead in quarter-note song beats, at or after every existing Arrangement clip end.
`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?

Beyond annotations, it discloses major behavioral traits: setting and verifying an insert marker, starting global Arrangement record/playback, leaving the marker at the start, the 300-second/stopped-at-endBeats cleanup condition, ownership surviving client disconnect, tempo/meter and Session changes, cleanup relinquishment on certain control changes, retained partial clips/overhang, and explicit lack of exact timing/audio/input proof. This is unusually rich side-effect and failure-mode disclosure for a destructive recording operation.

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?

The purpose is front-loaded, and much of the length is justified by the operation's complexity. However, the prose is dense and hard to parse, with opaque clauses such as 'Native display ticks request both stopped at endBeats or 300 seconds while scope remains owned' and a trailing fragment, 'Updated bridge; all profile,' that does not earn 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?

Given a destructive six-parameter tool with annotations and an output schema, the description covers the critical preconditions, side effects, cleanup ownership, and limitations. It is nearly complete, though it would be stronger if it routed the agent to sibling polling/finish tools and clarified the dryRun/planHash/confirmationToken workflow.

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 all six parameters are already documented in the schema. The description mentions startBeats, endBeats, and the marker semantics, but adds little beyond the schema for expectedStateVersion, dryRun, planHash, or confirmationToken. 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?

The first sentence states a specific verb and resource: recording Session clip/scene choices into an empty Arrangement tail after existing clips. It is clear what the tool does, but it does not distinguish itself from adjacent siblings such as record_arrangement_take, capture_session_scene, or place_session_clip_in_arrangement.

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?

The description gives extensive preconditions for use: stopped playback, playhead at a native bar start aligned to the global launch grid, arms off, loop/punch/automation arm/Session recording off, and supported count-in. It does not name alternatives or explain when to use get_session_arrangement_recording or finish_session_arrangement_recording instead, so it stops short of full routing guidance.

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

Deploy Server