ableton-mcp

Overview Schema Source Related Servers Discussions Admin

plan_scale_bassline

Read-onlyIdempotent

Plan deterministic, scale-aware basslines in Ableton Live from chord progression degrees, placing roots, octave motion, or diatonic fifths on straight or triplet grid steps.

Instructions

Plan a deterministic scale-aware bassline from progression degrees in the current Live key. Places roots, root-octave motion, or roots with each chord's diatonic fifth on explicit straight or triplet grid steps.

Input Schema

Name	Required	Description
`gate`	Yes	Note duration as a fraction of stepBeats.
`degrees`	Yes	Ordered one-based scale degrees.
`maxPitch`	Yes
`minPitch`	Yes
`velocity`	Yes
`stepBeats`	Yes	Grid subdivision in beats; must divide chordBeats exactly.
`chordBeats`	Yes	Duration of each progression degree in beats.
`startBeats`	Yes	Bassline start in beats.
`activeSteps`	Yes	Unique zero-based grid steps played within every chord.
`pitchPattern`	Yes

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: +[
+  {
+    "properties": {
+      "musicalContext": {
+        "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"
+      }
+    },
+    "required": [
+      "stateVersion",
+      "musicalContext",
+      "plan"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "error": {
+        "properties": {
+          "message": {
+            "type": "string"
+          },
+          "outcome": {
+            "enum": [
+              "unknown",
+              "not_executed"
+            ]
+          }
+        },
+        "required": [
+          "message",
+          "outcome"
+        ],
+        "type": "object"
+      }
+    },
+    "required": [
+      "error"
+    ],
+    "type": "object"
+  }
+]

Changed1 schema field changedv0.3.0Oct 19, 2026

changedOutput schema / (root)

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

First observedv0.1.0Sep 23, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context the annotations don't: output is deterministic, degrees are resolved against the *current* Live key (a dependency on external state), and output sits on explicit straight or triplet grid steps rather than being free-floating. It does not state what happens if the current key is unset, which is the one remaining behavioral risk.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the verb and the domain, then a second sentence covering voicing options and grid placement. No filler and nothing repeated from the schema.

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-required-parameter planning tool with a full output schema and complete annotations, the description covers purpose, key derivation, pitch pattern choices and grid semantics. The gaps are the plan→apply relationship with create_scale_bassline_clip and the implicit prerequisite that a Live scale exists.

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 60%, so several parameters (minPitch, maxPitch, velocity) rely on the schema alone. The description does add genuine meaning for pitchPattern by unpacking all three enum values — notably clarifying 'root_fifth' means each chord's *diatonic* fifth — and it ties degrees/stepBeats/activeSteps to the key-relative and grid model. That is solid partial compensation but not full.

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?

Specific verb+resource: 'Plan a deterministic scale-aware bassline' with the source material named ('from progression degrees in the current Live key'). The word 'bassline' implicitly separates it from plan_scale_melody and plan_scale_chord_progression, but it never names those siblings or their boundary conditions explicitly.

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

Usage Guidelines3/5

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

Usage is only implied: the agent must infer this is a planning step that precedes create_scale_bassline_clip, and must infer it requires a scale to already be set. There is no statement of when to pick this over the melody/chord planners, nor any prerequisites or exclusions.

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

Deploy Server