ableton-mcp

Overview Schema Source Related Servers Discussions Admin

create_bassline

Destructive

Write a bassline in a key using scale degrees per bar and a pattern, outputting to an Ableton clip slot or a 120 BPM MIDI file when Live is closed.

Instructions

Write a bassline in a key. degrees are scale degrees, one per bar, cycled (default [1]; e.g. [1, 6, 4, 5]). bars defaults to len(degrees). root and scale default to the Set's scale (see set_scale); without Live, give both. octave 1 puts A at MIDI 45. The track needs an instrument (e.g. a bass synth), or the clip plays silent. Destination: track + slot writes a clip into Live and replaces any clip in that slot (one undo_last restores it); file_name instead writes a 120 BPM .mid file to ~/Music/ableton-mcp/midi/ and works with Live closed. Never creates tracks. 4/4 only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_bassline"
  }
}

Input Schema

Name	Required	Default
`bars`	No
`name`	No
`root`	No
`slot`	No
`scale`	No
`track`	No
`octave`	No
`degrees`	No
`pattern`	No	eighths
`file_name`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.0Nov 6, 2026

TDQS

A4.2/5.0

Behavior5/5

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

The description adds substantial behavior beyond the destructiveHint=true annotation: it names exactly what is destroyed ("replaces any clip in that slot") and the recovery path ("one undo_last restores it"). It also discloses a silent-failure mode (no instrument means the clip plays silent) and the 4/4-only, 120 BPM, fixed output-location constraints.

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?

Dense and front-loaded: purpose first, then core parameter semantics, then destination choice. Telegraphic phrasing ("degrees are scale degrees") and a slightly cryptic MIDI-45 anchor cost a little clarity, but there is no filler.

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, no-output-schema tool this covers the pitfalls an agent would actually hit: missing instrument, Live-closed operation, slot overwrite, track creation, and meter. The unexplained pattern enum and name parameter keep it short of complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description does the heavy lifting: degrees is defined semantically (scale degrees, one per bar, cycled) with a worked example, bars defaults to len(degrees), root/scale default to the Set's scale, and octave is anchored concretely ("octave 1 puts A at MIDI 45"). Only pattern (five enum values) and name go unexplained, which is a real gap at this parameter count.

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?

"Write a bassline in a key" gives a specific verb (write) and resource (bassline), clearly distinguishable in substance from siblings like create_drum_pattern or create_chord_progression. It does not name those siblings explicitly, so differentiation is inferred from the resource rather than stated.

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?

It routes between two mutually exclusive destinations: track + slot for writing into Live, file_name for a .mid file that "works with Live closed." It also states a prerequisite ("without Live, give both" root and scale) and a hard constraint ("Never creates tracks"). What's missing is explicit guidance on choosing this over write_notes or create_chord_progression.

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