ableton-mcp

Overview Schema Source Related Servers Discussions Admin

finish_beat_repeat_fill

Destructive

Release a completed Beat Repeat fill handle in Ableton Live or cancel an active fill early, preserving manual Repeat edits while reporting cleanup failures explicitly.

Instructions

Release a terminal fill handle; cancel true attempts owned Repeat Off early. Preserves manual Repeat edits and other controls. Cleanup failure stays explicit; releasing a terminal handle does not repair its device. Updated bridge; all profile.

Input Schema

Name	Required	Description
`cancel`	No	Explicitly end an active fill early; default false.
`dryRun`	No	False executes with token and hash.
`fillId`	Yes	Exact retained fill ID.
`planHash`	No	Plan hash.
`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

C2.8/5.0

Behavior3/5

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

The description adds some behavior beyond the annotations by saying manual Repeat edits and other controls are preserved, cleanup failure remains explicit, and releasing a terminal handle does not repair its device. However, it does not clearly explain what is destroyed or what the destructive release actually changes, and 'Updated bridge; all profile' adds no usable behavioral context.

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 opening clause is front-loaded, but the description contains cryptic phrasing and the trailing sentence 'Updated bridge; all profile' is unclear and does not earn its place. It is short overall but not efficiently structured.

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

Completeness3/5

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

The tool has annotations, full schema coverage, and an output schema, so the description need not explain parameters or return values. Still, for a destructive lifecycle operation with several sibling beat-repeat tools, it should more clearly establish when this terminal action applies and what it affects.

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 schema already documents all six parameters. The description adds only a loose semantic hint about cancel=true ending an active fill early and does not meaningfully clarify planHash, confirmationToken, expectedStateVersion, or dryRun beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The phrase 'Release a terminal fill handle' gestures at the lifecycle-ending action, but 'terminal fill handle' is vague jargon and the description never plainly states that this finishes or closes a Beat Repeat fill. It also does not distinguish the operation from siblings such as perform_beat_repeat_fill or get_beat_repeat_fill.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is a hint that cancel=true ends an active fill early, but the description gives no explicit guidance on when to use this tool versus perform_beat_repeat_fill, get_beat_repeat_fill, or other beat-repeat controls. No preconditions or exclusions are stated.

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

Deploy Server