Ableton Live MCP

An MCP server for Ableton Live 12, built on the official Ableton Extensions SDK. The MCP server runs inside Live as an extension — no bridge process, no MIDI remote scripts. Any MCP client (Claude Code, Claude Desktop, Cursor, ...) connects over streamable HTTP and gets full programmatic control of the Live Set: tracks, clips, MIDI notes, devices, parameters, mixer, scenes, warping, rendering, and more.

MCP client (Claude, ...) ──streamable HTTP──▶ http://127.0.0.1:8722/mcp
                                                      │
                                     Live Extension Host (Node.js)
                                                      │
                                              Ableton Live 12

Requirements

• Ableton Live 12.4.5 or newer (Extensions support)

• Node.js >= 24.14 (build only)

Related MCP server: ableton-mind

Install

npm install
npm run package        # builds and produces Ableton-Live-MCP-<version>.ablx

Then drag the .ablx file onto Settings → Extensions in Live. The MCP endpoint starts with Live at http://127.0.0.1:8722/mcp (GET /health for a quick check).

Development mode

Enable Settings → Extensions → Developer Mode in Live, then:

npm start              # builds and runs the extension against the running Live

.env must point at your Live installation, e.g. EXTENSION_HOST_PATH=/Applications/Ableton Live 12 Beta.app.

Connect a client

Claude Code:

claude mcp add --transport http ableton-live http://127.0.0.1:8722/mcp

Claude Desktop (or any stdio-only client) via mcp-remote:

{
  "mcpServers": {
    "ableton-live": {
      "command": "npx",
      "args": ["mcp-remote", "http://127.0.0.1:8722/mcp"]
    }
  }
}

Configuration

The port is stored in config.json inside the extension's storage directory (created on first run; the path is reported by song_get under environment.storage_directory). Default:

{ "port": 8722 }

How it works

• Every Live object (track, clip, device, parameter, ...) is addressed by a stable object id discovered through listing tools (song_get, track_get, device_get, ...).

• Ids stay valid until the object is deleted or moved, or another Live Set is loaded. Stale ids return an error telling the client to re-list.

• All times/positions are in beats; colors are #RRGGBB; MIDI pitches are 0–127.

• Multi-value writes (parameter_set) are grouped into a single undo step in Live.

Tools

Song

Tracks

Scenes & cue points

Clips

Devices & racks

Parameters & mixing

Files & rendering

UI & commands

Skills

skills/ableton-live/SKILL.md is an installable agent skill that teaches an MCP client how to use these tools well (id discovery flow, beats vs. seconds, note-editing patterns, device workflows). Install it for Claude Code with:

mkdir -p ~/.claude/skills && cp -r skills/ableton-live ~/.claude/skills/

Typical things you can ask a connected assistant to do:

• "Create a 4-bar house drum pattern on a new MIDI track with a Drum Rack"

• "Warp all clips on the Drums track in Complex Pro mode"

• "Turn down every track that isn't the vocal bus by 3 dB"

• "Build a song skeleton: intro, verse, chorus scenes with locators"

• "Replace the sample in Simpler with /path/to/kick.wav and map it to C1"

Limitations

• The extension (and thus the MCP endpoint) only runs while Live is open.

• Only built-in Live devices can be inserted; third-party plug-ins can't be loaded by the SDK.

• No transport control (play/stop/record) or clip launching — the Extensions API v1.0.0 does not expose them. Same for browser access and parameter automation curves.

• show_dialog blocks until the user closes the dialog in Live.

Tests

npm test                  # E2E against a mock Extension Host: MCP client ↔ HTTP ↔ all tools
node test/live-smoke.mjs  # against a real running Live with the extension loaded

The live smoke test creates its own tracks/clips/devices, verifies every tool family (MIDI notes, warping, drum racks, rendering, ...), and deletes everything it created.

Extension Host quirks (worth knowing)

Two behaviors of the beta Extension Host that this project works around:

1. Bare VM context. Extensions are evaluated in a V8 context without global or web globals (Request, Response, ReadableStream, fetch, EventTarget, ...), which the MCP SDK needs at load time. build.ts injects a banner that pulls them in from the main Node context (core-module functions are shared, so their Function constructor evaluates there). See build.ts for details.

2. bigint numerics. The host returns bigint for some values the SDK types as number (clip colors, note pitches, ...). src/serialize.ts normalizes with num() before arithmetic/JSON.

3. Asynchronous writes. SDK property setters (notes, names, values) return before Live has applied the change; a read within a few tens of ms can return the previous state. Agents rarely notice, but read-after-write tests must retry briefly (see eventually() in test/live-smoke.mjs).

Also: if the dev Extension Host crashes, Live may refuse the next control-channel handshake ("bring-up timed out") — restart Live and run npm start again.

Troubleshooting

• Endpoint not responding: check curl http://127.0.0.1:8722/health. Right-click any track in Live — the "Ableton Live MCP: Status" context-menu action shows the endpoint the extension actually bound.

• Port already in use: if another process holds the configured port, the server logs the failure to ExtensionHost.txt and does not start. Change port in the extension's config.json (path shown by song_get under environment.storage_directory) — the file is read once at startup, so restart Live afterwards.

• Changed config.json but nothing happened: config is only read when the extension starts. Restart Live (or the dev Extension Host).

License

MIT for the code in this repository. The vendor/ tarballs (Ableton Extensions SDK & CLI) are Ableton's and covered by their own license (see sdk/LICENSE.md in the SDK distribution).