ableton-mcp

Overview Schema Source Related Servers Discussions Admin

plan_midi_probability_pattern

Read-onlyIdempotent

Assign explicit 0-1 playback probabilities to ordered MIDI note onsets in an Ableton clip, controlling which repeated notes trigger.

Instructions

Plan explicit repeating playback probabilities across complete ordered MIDI onsets.

Input Schema

Name	Required	Description
`clipId`	Yes	list_clips Session ID or supported list_arrangement_clips ID.
`noteIds`	Yes	Unique stable note IDs at complete selected onsets.
`trackId`	Yes	ID from list_tracks.
`probabilities`	Yes	Explicit repeating probabilities from 0 to 1.

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: +[
+  {
+    "properties": {
+      "clipId": {
+        "type": "string"
+      },
+      "context": {
+        "type": "object"
+      },
+      "plan": {
+        "properties": {
+          "changes": {
+            "items": {
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "newNotes": {
+            "items": {
+              "properties": {
+                "duration": {
+                  "type": "number"
+                },
+                "pitch": {
+                  "maximum": 127,
+                  "minimum": 0,
+                  "type": "integer"
+                },
+                "start": {
+                  "type": "number"
+                },
+                "velocity": {
+                  "maximum": 127,
+                  "minimum": 0,
+                  "type": "integer"
+                }
+              },
+              "required": [
+                "pitch",
+                "start",
+                "duration",
+                "velocity"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "noteIds": {
+            "items": {
+              "type": "integer"
+            },
+            "type": "array"
+          },
+          "notes": {
+            "items": {
+              "properties": {
+                "duration": {
+                  "type": "number"
+                },
+                "pitch": {
+                  "maximum": 127,
+                  "minimum": 0,
+                  "type": "integer"
+                },
+                "start": {
+                  "type": "number"
+                },
+                "velocity": {
+                  "maximum": 127,
+                  "minimum": 0,
+                  "type": "integer"
+                }
+              },
+              "required": [
+                "pitch",
+                "start",
+                "duration",
+                "velocity"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "preservedNotes": {
+            "items": {
+              "type": "object"
+            },
+            "type": "array"
+          }
+        },
+        "required": [],
+        "type": "object"
+      },
+      "stateVersion": {
+        "minimum": 1,
+        "type": "integer"
+      },
+      "trackId": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "stateVersion",
+      "trackId",
+      "clipId",
+      "context",
+      "plan"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "error": {
+        "properties": {
+          "message": {
+            "type": "string"
+          },
+          "outcome": {
+            "enum": [
+              "unknown",
+              "not_executed"
+            ]
+          }
+        },
+        "required": [
+          "message",
+          "outcome"
+        ],
+        "type": "object"
+      }
+    },
+    "required": [
+      "error"
+    ],
+    "type": "object"
+  }
+]

Changed3 schema fields changedv0.3.0Oct 19, 2026

changedInput schema / properties / clipId / description

Previous value: -"Stable clip ID: track-N:clip-M from list_clips, or track-N:arrangement-clip-M from list_arrangement_clips for tools that support Arrangement clips."New value: +"Session ID from list_clips; Arrangement ID from list_arrangement_clips where supported."

changedInput schema / properties / trackId / description

Previous value: -"Stable track ID returned by list_tracks."New value: +"ID from list_tracks."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

First observedv0.1.0Sep 23, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare the operation as read-only, idempotent, non-destructive, and closed-world. The description adds domain context about repeating probabilities and ordered onsets, but does not clarify what a 'plan' produces or how it differs behaviorally from applying a pattern, so it adds only moderate value beyond the annotations.

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?

It is a single front-loaded sentence with no wasted wording. The phrase 'complete ordered MIDI onsets' is slightly dense, but the definition remains compact and focused.

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?

With a complete input schema, output schema, and rich annotations, the description does not need to explain return values or safety. However, it omits the important distinction between planning a probability pattern and applying one, leaving a meaningful contextual gap for an agent choosing among sibling tools.

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 four parameters are already documented, including the ordered mapping between noteIds and probabilities. The description reinforces the 'ordered onset' idea but adds no syntax, constraints, or pairing details beyond the schema.

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 description states a specific verb and resource: planning MIDI probability patterns across note onsets. It is clear enough to distinguish a probability-pattern tool from velocity, gate, or ratchet planners, although it does not explicitly contrast itself with the closely related apply_midi_probability_pattern sibling.

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?

It gives no guidance on when to use this planning tool instead of apply_midi_probability_pattern or other MIDI pattern planners. There are no prerequisites or exclusions, so the agent must infer usage from the name alone.

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

Deploy Server