ableton-connect

I was learning production, and there was a gap between what I wanted to do and what I knew how to execute. I found an MCP server for Ableton on GitHub, forked it and connected it to Claude.

One of the first tests was asking it for a bass melody. It wrote it straight into an Ableton clip.

The interesting part wasn't that an AI could tell me what to do. It was that it could do it, inside the tool where I already work.

The server could create, read and change things inside Live, but it didn't know what had happened after doing so. It could move a fader; it couldn't tell whether the result was better.

In April 2026 I started my own server.

The first version had just over 90 tools. The next ones didn't come from a feature list: they appeared while working on real sessions, from automating a section or understanding the existing harmony to listening before deciding and measuring whether a change had worked.

Today there are 438.

Claude Code writes the code. I define what each tool must do, what it can touch, how it's checked and what done means.

Then I test it inside Ableton, find where it fails and step in again.

When writing code stops being the bottleneck, the work shifts: defining behaviour well, building the right checks and deciding what deserves to exist matter more than executing each implementation.

Claude connects to the server over MCP. The server controls Ableton through a Remote Script, uses a Max for Live bridge to reach parameters the API doesn't expose, and analyses the audio locally. The audio never leaves the computer.

I use it two ways. Sometimes I work by hand and call Claude when I need to analyse or change something. Other times I start by talking and direct the session while Claude acts inside Ableton.

Giving it access to Ableton also means assuming the AI will make mistakes.

So every tool has a risk level. Of the current 438, 162 only read, 246 can write safely, 26 perform destructive actions and 4 control third-party plugins. The last two categories are off by default.

Before a device is changed, its state is saved. Every plan defines what it expects to achieve before the change runs. Afterwards everything is measured again and compared with that expectation. In the A/B comparison, if the measurement gets worse, the change is undone automatically; it can be set to only report it and let me decide.

On 5 October I tested it on 16 bars of a trance track of mine. The goal wasn't to finish the mix. It was to check whether the system could propose a change, define how to evaluate it and then show whether it had worked.

Before touching anything it found a clear problem: 95% of the master's energy sat below 250 Hz, and the arpeggio and pads were 13 to 14 LU below the kick.

It proposed five fader changes and nine criteria to evaluate them. I approved the values. Only then did it save the state, check the faders weren't automated, apply the five changes and measure again.

Eight of the nine criteria were met. The mids one failed by 0.8 dB, and I didn't add an extra correction to force the result. I listened and decided to keep the change.

The first evaluation wasn't even valid. The two renders came from different sections, because Live records from the insert marker, not from the bar it's asked for. I threw that comparison out and repeated the test with aligned windows.

Some limits come from Ableton itself. Its API can't create arrangement automation directly, so the server writes it by playing and recording the parameter's movement in real time. Snapshots don't include the mixer faders either, so those values are stored separately.

Others I found by testing. Rendering an unsaved set could crash Live; now the server refuses to do it. I also dropped MuQ and MuLan after testing them on real audio, because MERT and CLAP worked better for what I needed.

Music generation is still the weakest part of the system. It works as scaffolding for me. The value lies far more in analysing, executing and checking than in composing for me.