Skip to main content
Glama
romanstark

Ableton Maestro

als_write

Modify saved Ableton Live project files on disk—wire sidechain routing, configure plugin parameters, set file attributes, or restore backups—with confirmation required before changes apply.

Instructions

Edit a saved .als project file on disk. Requires confirm=True.

Supported operations: 'sidechain', 'configure', 'attribute', 'restore'.
Target project file must not be currently open in Live unless confirmed.

Args:
    path: Path to target .als project file.
    operation: Modification operation ('sidechain', 'configure', 'attribute', 'restore').
    confirm: Confirmation flag required to execute modifications.
    target_track: Name of track containing target device.
    source_track: Name of track providing trigger source (sidechain operation).
    device: Device index within target track.
    tap: Sidechain tap point ('pre' or 'post').
    expression: ElementTree path expression (attribute operation).
    value: New attribute value or configure assignment string ('<index>=<name>; ...').
    attribute: Attribute name to modify (attribute operation, defaults to 'Value').
    index: Target element match index when expression matches multiple elements.
    create: When True, creates attribute if missing.
    backup: Backup filepath required for restore operation.
    allow_live_running: Allow write when Live runs (auto-enabled if holding another set).

Returns:
    Dictionary reporting write status, changes made, and verification report.

Note:
    ``sidechain`` is here for the set Live is not holding, someone else's project
    wired on disk. Measured in a corpus of 174 projects: 74 of 82 in the
    house/trance BPM window use sidechain compression, median 6 wirings each. For
    the set on screen use ``lom_set`` and keep the read-back.

    ``configure`` fills a plugin's parameter strip, which no LOM call can do
    whatever the strip currently holds. Measured 2026-09-01 against Live 12.4.5: two
    parameters written into an instance whose strip held nothing came back on reopen
    with their real values, writable through ``lom_set`` with ``read_back: applied``.
    Live allocates 128 slots per instance and leaves them all in the file, so
    nothing is inserted; three fields of an existing element are filled.

    ``attribute`` sets one attribute anywhere in the file, addressed by an
    ElementTree expression. An expression matching more than one element is refused
    unless ``index`` picks one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tapNopost
pathYes
indexNo
valueNo
backupNo
createNo
deviceNo
confirmNo
attributeNoValue
operationYes
expressionNo
source_trackNo
target_trackNo
allow_live_runningNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so well. It discloses the confirmation requirement, the open-file restriction, measured behavior for sidechain and configure operations, that configure fills plugin parameter strips which LOM calls cannot, that 128 slots are allocated with no insertion, and that attribute refuses ambiguous ElementTree matches unless index is provided.

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?

The description is front-loaded with the core purpose, requirement, and operations before the Args block. The Note section adds valuable behavioral detail but is somewhat cluttered with corpus statistics and a measured-date aside that are less directly actionable for tool invocation.

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 complex 14-parameter tool with no annotations and no schema descriptions, the description covers most needed guidance: parameters, safety confirmations, file-open conditions, and behavioral notes. Gaps remain for the 'restore' operation, the exact meaning of 'backup', and how allow_live_running relates to the confirmed/unconfirmed open-file rule. The presence of an output schema offsets some need to describe return values.

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?

Schema description coverage is 0%, and the description compensates by documenting all 14 parameters with purpose beyond field names. Most are clear, such as tap ('pre' or 'post'), expression as an ElementTree path, and value as a configure assignment string. However, 'backup' is only described as 'Backup filepath?' which is incomplete, and 'allow_live_running' is vague ('Whether Live may be running') given the earlier open-file condition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Edit a saved .als project file on disk.' It also lists the four supported operations ('sidechain', 'configure', 'attribute', 'restore'), so an agent can immediately see what the tool does and how it differs from live-set tools like lom_set.

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?

The description gives clear conditions: requires confirm=True, the target file must not be open in Live unless confirmed, and it explicitly directs on-screen set edits to lom_set instead. It does not fully explain when to choose among the four operations, nor does it compare against als_read for reading files, which leaves some selection guidance implicit.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/romanstark/ableton-maestro'

If you have feedback or need assistance with the MCP directory API, please join our Discord server