Skip to main content
Ensure Ableton Live is open with the Vibrai M4L device loaded, then retry. The CLI talks to the bridge at http://localhost:3333 (override with --url or the VIBRAI_URL environment variable).Check the three most common causes:
  1. Is Live open?
  2. Is vibrai.amxd loaded on a track in the current Live set?
  3. Is the device’s Active toggle on (the power button in the device header)?
You can verify the bridge directly:
A healthy response looks like {"is_playing":false,"tempo":120.0,...}. A connection refused means the device is not loaded or Live’s Max console has an error.
Confirm the command path in your config file is an absolute path to an executable binary, then restart Claude Desktop fully (the MCP server is launched at app start, not on demand).On macOS, check ~/Library/Logs/Claude/mcp*.log for startup errors.Smoke-test the binary directly in a terminal:
You should see a tools/list response listing the Vibrai tools.
A fast, healthy get_version (or vibrai version) alongside a hanging tool call means the bridges are fine — the call was lost between the MCP client and the Vibrai server (a known Claude Desktop transport issue). It is not a wedged bridge, so restarting Live or re-toggling the Control Surface will not help.
  1. Retry the call — the drop is usually transient (a single lost request, not a stuck pipe).
  2. If it keeps happening, run the same operation with the vibrai CLI — it bypasses the MCP client entirely.
  3. To confirm, check ~/Library/Logs/Claude/mcp-server-vibrai.log (macOS): the hung call never appears there, while every request that was logged has a response.
Since v1.3.5 a healthy probe says this outright: both version surfaces always report bridge_status and python_bridge_status ("ok" plus probe timings on success), and when both bridges are healthy the payload includes a note naming the client transport as the fault. A genuinely wedged bridge behaves differently — the tool call itself fails with a reload runbook, and get_version reports bridge_status: "timed_out".
vibrai generate is non-destructive by default. Add --force once you have reviewed the dry-run output:
The equivalent MCP parameter is force: true on the generate tool.
Session-view automation reads and writes route through the Vibrai Python remote script (localhost:3334), not the M4L bridge. If it is not running:
  1. Call install_vibrai_remote_script (MCP) or vibrai install remote-script (CLI).
  2. Restart Ableton Live.
  3. Open Preferences → Link/Tempo/MIDI and set one Control Surface dropdown to Vibrai.
  4. Call get_version to confirm the python_bridge field is populated.
This is expected when Live is not open or the device is not loaded. The CLI version still printed, confirming the install is working. Commands that only read project files will work offline. Commands that talk to Live will return a clear bridge unreachable error (exit code 2).
Positional track IDs (id in list_tracks) are 1-based and can shift when you reorder, add, or delete tracks. Re-run vibrai track list (or call list_tracks via MCP) after any reorder to get current IDs. Note that audio tracks, return tracks, and the master all count toward the numbering, so track 1 may not be a MIDI track.For multi-step workflows that operate on the same track over time, use liveset_id (returned by list_tracks). It is stable within one Live session — it survives reorders, renames, and inserts. Pass it with --liveset-id on track rename and track delete, or as liveset_id on the MCP equivalents.
load_device --part-type bd resolves to an empty Drum Rack. To get a kit with samples, browse for a kit preset file first:
From MCP: call browse_devices("Drums") to see available kits, then load_device with the .adg path. Tonal part types (bass, pad, lead) load synthesizers that make sound immediately without this extra step.
By default vibrai generate writes MIDI to empty tracks — nothing plays until each track has an instrument. Generate with instruments in one step, or load defaults onto an existing arrangement:
From MCP, the guided generate flow loads instruments for you; to load defaults onto a set that already has clips, call load_default_instruments. If a drum rack loads but stays silent, see the kit note above.
Saving a .vibrai file — by hand, via vibrai project save, or by applying a genre preset — only writes to disk. Nothing reaches Live until you render:
From MCP, call generate. This split is deliberate: the file is the source of truth, and rendering is the step that overwrites what is in your set.
The Max for Live device sometimes needs a moment to initialize fully, especially right after opening a set. In Live, click the device’s title bar and choose Reload Device, then try again.If it still does nothing, confirm the device is on the current set’s track and its Active toggle (the power button in the device header) is on.
vibrai scale set takes a pitch class from 0 to 11 — 0=C, 1=C#, 2=D, 3=D#, 4=E, 5=F, 6=F#, 7=G, 8=G#, 9=A, 10=A#, 11=B. Anything higher exits immediately with an argument-validation error (exit code 255).Valid scale names: Major, Ionian, Dorian, Phrygian, Lydian, Mixolydian, Minor, Aeolian, Locrian.
Say which track you mean, by name rather than by position:
Better still, give it a map first: List the tracks in this set, then add a hi-hat pattern to the drum track. See MCP Overview for more prompting guidance.
Check your license or trial state:
If the trial has expired, activate the key from your purchase email (activation is CLI-only):
If you were offline and now see an offline-grace banner, force a re-validation once you are back online:
From MCP you can read status with get_license_status and clear an offline-grace banner with recheck_license — both are read-only. Activation and deactivation stay on the CLI by design.
Roll back to the binary you had before the last update:
To check for an update without applying it, use vibrai update --check; to apply non-interactively, use vibrai update --yes. Updates cover the CLI, the M4L device, and the Python remote script — restart Live afterward so the device and script changes load. The MCP server binary updates through Claude Desktop’s extension manager, not vibrai update. From MCP, the update tool reports availability by default and applies when called with apply=true (it also supports rollback).

​
Log locations

For deeper CLI tracing, add --log-level Debug --log-file /tmp/vibrai.log to any command. For the MCP server, set VIBRAI_LOG_LEVEL=Debug and VIBRAI_LOG_FILE=/tmp/vibrai-mcp.log in the server config.