ableton-mcp

Overview Schema Source Related Servers Discussions Admin

create_clip_mixer_envelope

Create exact clip automation envelopes for Session volume, stereo pan, or return sends with 1–128 ordered steps. Use raw values or native dB targets to define clip mixer changes.

Instructions

Create an absent Session volume, Stereo pan or exact Return-send envelope with 1–128 ordered steps. Exact raw values; volume/send also accept finite native dB targets. Pan refuses Split Stereo or unknown modes. No clamping. Requires stopped playback, recording off and inactive target automation. Binds clip, mixer and Return identity; verifies sampled interiors. Existing lanes are preserved. All profile.

Input Schema

Name	Required	Description
`clipId`	Yes	list_clips Session ID or supported list_arrangement_clips ID.
`dryRun`	No	False executes with token and hash.
`points`	Yes
`sendId`	No	Required for send; exact ID from get_track_mixer. Omit for volume or pan.
`trackId`	Yes	ID from list_tracks.
`planHash`	No	Plan hash.
`mixerControl`	Yes	Track fader, Stereo pan or exact track-to-Return send. Pan refuses Split Stereo or unknown modes.
`returnTrackId`	No	Required for send; matching Return ID from get_track_mixer. Omit for volume or pan.
`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.

Changed3 schema fields changedv0.3.1Oct 23, 2026

changedInput schema / properties / clipId / description

Previous value: -"Session ID from list_clips; Arrangement ID from list_arrangement_clips where supported."New value: +"list_clips Session ID or supported list_arrangement_clips ID."

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

Behavior4/5

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

Annotations only declare the mutation safety profile; the description adds real behavior: no clamping, exact raw native values vs finite dB targets, pan refusing Split Stereo/unknown modes, identity binding of clip/mixer/Return, and verification of sampled interiors. It omits the dryRun→planHash→confirmationToken two-phase execution model, which is the most consequential behavior for a non-idempotent write.

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?

Front-loaded and dense with no filler sentences; each clause carries a constraint. Two fragments are opaque to an outsider — "verifies sampled interiors" and "All profile" — which cost some clarity without adding discernible information.

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 10-parameter mutation with nested oneOf points and an output schema, the description covers preconditions, value semantics, and preservation guarantees adequately. The remaining gap is the confirmation-token/planHash workflow and expectedStateVersion conflict behavior, which the schema names but does not explain.

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 90%, and the nested points variants are thoroughly documented in the schema itself (time/value/duration vs targetDisplay). The description restates the 1–128 step limit and that volume/send accept dB targets while pan requires a raw value, but that largely duplicates the schema rather than adding new meaning.

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 and resource: create an absent Session envelope for a mixer control (volume, Stereo pan, or Return send) with 1–128 ordered steps. The mixer-control scope implicitly separates it from create_clip_parameter_envelope and set_clip_parameter_envelope, though it never names those siblings explicitly to confirm the boundary.

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?

"Create an absent ... envelope" plus the preconditions (stopped playback, recording off, inactive target automation) give clear when-to-use context, and "Existing lanes are preserved" signals that this is not the tool for editing an existing lane. It stops short of naming the alternative tool to use when a lane already exists.

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

Deploy Server