Live Maestro

Overview Schema Source Related Servers Discussions Admin

lom_batch

Combine multiple Ableton Live get, set, and call operations into a single round trip to reduce latency. Run up to 1000 operations in order, with optional stop-on-error behavior.

Instructions

Execute multiple raw LOM operations (get, set, call) in a single round trip.

Returns:
    Dictionary containing ordered results for each operation.

Note:
    A batch runs inside one handler call, synchronously on Live's main thread, and is
    capped at 1000 operations (max_ops=1000): a larger one is rejected upfront and never
    truncated. Measured 2026-09-16 against Live 12.4.5 (macOS 26.6.2, four-track set):
    one request costs about 400 ms whatever its size, with 200 ops at 500 ms, 1600 mixed
    reads at 1506 ms and 3200 song.tempo gets at 1718 ms, error_count 0 throughout; past
    the 200-op point the marginal cost is about 0.72 ms per mixed real read and 0.44 ms
    per song.tempo get. Write and call ops were not measured and cost more.

    Nothing Live recomputes between operations is visible to a later operation in the
    same batch: a read after a transport jump still reports the position from before the
    move, and four jumps interleaved with four reads returned four identical pre-jump
    values and no error. That is the failure shape to expect here. It does not raise. It
    returns a clean set of numbers that look like a measurement of a parameter which
    never changes, and the conclusion drawn from them is wrong. Sample a moving
    transport with one call per position, never inside a batch.

    An end_marker write on an Arrangement clip is refused here rather than sent.
    Observed once, 2026-09-10 against Live 12.4.5: the write was accepted without an
    error and end_time did not move; what it read back was never recorded, and
    docs/limits.md section 5 carries the probe that would settle it. ``atomic`` stops at
    the first error but undoes nothing, so read the state back after a partial failure.
    Prefer a dedicated tool where one exists: get_session, get_track, get_devices and
    set_mix batch their own reads and verify, which this does not.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ops`	Yes	The operations to run, in order (at most 1000 operations). Each one declares its own op, path and payload; the item schema carries the field meanings.
`atomic`	No	True stops at the first error, leaving the operations before it applied and the ones after it untried. False runs every operation and reports each result. Neither rolls anything back.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 24, 2026

changedInput schema / properties / ops / description

Previous value: -"The operations to run, in order. Each one declares its own op, path and payload; the item schema carries the field meanings."New value: +"The operations to run, in order (at most 1000 operations). Each one declares its own op, path and payload; the item schema carries the field meanings."

Changed2 schema fields changedv0.1.1Sep 7, 2026

addedInput schema / properties / atomic / description

Added value: +"True stops at the first error, leaving the operations before it applied and the ones after it untried. False runs every operation and reports each result. Neither rolls anything back."

addedInput schema / properties / ops / description

Added value: +"The operations to run, in order. Each one declares its own op, path and payload; the item schema carries the field meanings."

First observedv0.1.0Sep 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With all annotations set to false, the description carries the full burden of behavioral disclosure. It discloses that the batch runs synchronously on Live's main thread, is capped at 1000 operations, and is rejected upfront if larger. Critically, it explains that operations within a batch do not see recomputed state (e.g., a read after a transport jump returns the pre-jump value), and it describes the failure shape as returning clean but wrong numbers. It also notes atomic stops at the first error but undoes nothing, and that an end_marker write is refused. This is exceptionally transparent and goes far beyond the annotations.

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 purpose and return type, then provides a detailed note. While it is quite long, the length is justified by the critical behavioral caveats (consistency, failure shape, atomic rollback). However, the performance measurements are extraneous for an AI agent's decision-making and could be trimmed without losing essential information. The structure is logical and the key points are early, so it earns a 4 rather than a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the description is remarkably complete. It covers purpose, usage, behavioral caveats, and even includes failure shapes and advice on when not to use it. Since an output schema is present (as indicated by context), the description does not need to explain return values in detail. It provides everything an agent needs to correctly select and invoke this tool.

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

Parameters3/5

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

The input schema has 100% description coverage for all parameters, including ops (with its nested properties) and atomic. The description does not add extra meaning beyond the schema; it repeats the 1000-op cap (already in the schema) and the atomic behavior (also in the schema). Therefore, the baseline of 3 is appropriate—the schema does the heavy lifting, and the description adds no additional parameter-level context.

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 clearly states the tool executes multiple raw LOM operations (get, set, call) in a single round trip, using a specific verb and resource. It explicitly differentiates from dedicated siblings by naming get_session, get_track, get_devices, and set_mix and noting they batch their own reads and verify, which this tool does not. This leaves no ambiguity about what the tool does and how it differs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance on when to use this tool vs alternatives: 'Prefer a dedicated tool where one exists' and names the alternatives. It also provides specific usage warnings, such as not sampling a moving transport inside a batch and noting that atomic stops at the first error but does not roll back. This is clear, actionable, and covers exclusions.

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