ableton-mcp

Overview Schema Source Related Servers Discussions Admin

create_arrangement_audio_clip

Import a local audio file into an empty Ableton Live Arrangement as a named clip on a chosen track at a specified start beat; native import sets duration and warping.

Instructions

Import a local audio file directly onto an ordinary audio track with an empty Arrangement, at an explicit start and name. Binds native ownership and file metadata, rechecks at undo entry and verifies actual reference/settings/span. Native import determines duration/warping; populated timelines refuse. Partial work remains without rollback or replay. Does not bind file bytes or decoded cache, start playback or use Session staging. Updated bridge; all profile.

Input Schema

Name	Required	Description
`name`	Yes	Explicit new clip label without controls.
`dryRun`	No	False executes with token and hash.
`trackId`	Yes	ID from list_tracks.
`planHash`	No	Plan hash.
`sourcePath`	Yes	Absolute local audio-file path; Live validates format.
`startBeats`	Yes	Absolute quarter-note song start, within 0 to 1576800.
`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

A3.8/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing transactional semantics: partial work persists with no rollback or replay, verification at undo entry checks reference/settings/span, and native import decides duration/warping. It also scopes non-goals (does not bind file bytes or decoded cache). Some phrasings ('Updated bridge; all profile') are opaque rather than informative.

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?

Front-loaded with the core action, but the body is compressed jargon ('Binds native ownership and file metadata', 'all profile') that costs parsing effort. The trailing fragment 'Updated bridge; all profile' consumes space without conveying actionable meaning.

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 mutation tool with annotations and an output schema, the description covers preconditions, partial-failure behavior, verification, and explicit non-goals. Only the dry-run/confirmation-token flow and relationship to specific sibling creation tools remain unaddressed.

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 all eight parameters are already documented, including dryRun, planHash and confirmationToken. The description adds only broad notions of 'explicit start and name' and a verification/undo-entry step, without explaining the plan-token or dry-run workflow beyond what the schema says. 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 (import a local audio file) and precise resource/target (ordinary audio track with an empty Arrangement, explicit start and name). It implicitly separates itself from Session-based and MIDI creation tools via 'empty Arrangement' and 'does not use Session staging', though it never names the sibling alternatives directly.

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 real preconditions and failure modes: 'populated timelines refuse', Arrangement must be empty, and it explicitly excludes playback and Session staging. It does not name a specific alternative tool to call when the timeline is populated, which keeps it below a 5.

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

Deploy Server