ableton-mcp

by cavi-ai

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

hold_session_clip

Destructive

Holds an existing Gate/Repeat Session clip for 0.25-8 seconds, then requests native release without this client.

Instructions

Hold one existing Gate/Repeat Session clip for 0.25–8 wall-clock seconds, then request native release without this client. Requires global playback, recording off, an unarmed/unfrozen target and no pending launches or other playing Session clip on its track. Honors quantization; may override target Arrangement. Gate may stop on release; Repeat may continue. Concurrent controller input cannot be distinguished. Command receipts are not button-state or audible proof. 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.
`trackId`	Yes	ID from list_tracks.
`planHash`	No	Plan hash.
`allowPlaying`	No	Explicitly allow the exact target to be already playing; defaults to false.
`durationSeconds`	Yes	Wall-clock hold duration checked on Live display ticks; not beat scheduling.
`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

A4.1/5.0

Behavior5/5

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

Annotations mark it destructive and non-idempotent; the description goes well beyond by disclosing quantization honoring, possible Arrangement override, Gate-stops vs Repeat-continues semantics, inability to distinguish concurrent controller input, and that receipts are not audible proof. This is rich operational context rare in a description.

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-loads the purpose and duration, then packs preconditions and caveats into tight sentences. No filler, though a few fragments ('All profile', 'Command receipts are not button-state') are terse to the point of opacity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description covers preconditions, side effects, and the Gate/Repeat divergence thoroughly. For a destructive, conditioned hold operation the agent has what it needs.

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 the required and optional parameters (dryRun, planHash, allowPlaying, confirmationToken, expectedStateVersion) are already documented. The description adds little per-parameter meaning beyond the duration range, which is already in the schema (0.25–8 wall-clock).

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 (hold) and resource (existing Gate/Repeat Session clip) with a bounded duration, so the operation is unambiguous. It does not name its obvious siblings get_session_clip_hold / finish_session_clip_hold, so it stops short of full sibling differentiation.

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 use: global playback on, recording off, unarmed/unfrozen target, no pending launches or competing clip on the track. That effectively tells the agent when the call is valid, but offers no explicit alternative tools or when-not-to-use guidance.

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

Deploy Server