Skip to main content
Glama

capture_session_to_arrangement

Capture a Session scene into the Arrangement for audio export. Automates arming Arrangement Record and printing the scene, so you can export your song.

Instructions

Record a Session scene into the Arrangement so the song can be exported.

Live's Export Audio/Video only renders the Arrangement, so a Session-view
loop must first be printed there. This automates the whole capture — no
manual Arrangement-record arming:

  1. stop, rewind to 1.1.1, force Session Record off, and (if tighten_launch)
     set clip-launch quantization to None for a tight start at bar 1,
  2. arm Arrangement Record (the ● button),
  3. fire scene `scene_index` — its clips begin printing into the Arrangement,
  4. wait one full pass (`length_beats` + `tail_beats`), polling the playhead,
  5. stop, disarm record, restore quantization, rewind, return to Arrangement.

length_beats = bars * time_signature_numerator (e.g. 128 bars of 4/4 = 512).
`tail_beats` lets the final notes ring before stopping. Re-recording the same
span overwrites the previously captured Arrangement region for the scene's
tracks, so re-exports stay clean.

wait=True (default) blocks until the pass finishes and returns the result.
wait=False arms + fires and returns immediately (then call stop_playback and
set_arrangement_record(False) yourself once the playhead reaches length_beats).
max_wait_seconds caps the blocking wait (0 = auto: one pass + 15 s headroom).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
waitNo
tail_beatsNo
scene_indexYes
length_beatsYes
tighten_launchNo
max_wait_secondsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations, the description fully discloses side effects: it stops, rewinds, forces Session Record off, arms Arrangement Record, fires a scene, waits, then stops, disarms, restores quantization, and rewinds. It also notes that re-recording overwrites the previous region and explains waiting/max_wait_seconds behavior, offering complete behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with a brief intro, numbered steps, and separate parameter explanations. While long, every sentence carries essential operational detail for a complex multi-step tool, and the structure aids scannability. It avoids fluff and front-loads the core purpose.

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 (6 params, multi-step side effects, no annotations), the description is exceptionally complete: it addresses why, how, when, parameter details, side effects, and wait behavior. An output schema exists, so omitting explicit return-value details is acceptable. No significant gaps remain.

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

Parameters5/5

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

Schema description coverage is 0%, but the description explains every parameter meaningfully: length_beats formula ('bars * time_signature_numerator, e.g. 128 bars of 4/4 = 512'), tail_beats purpose, wait=True/False semantics, max_wait_seconds auto behavior, and tighten_launch effect in step 1. It fully compensates for the schema's lack of descriptions.

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's purpose: 'Record a Session scene into the Arrangement so the song can be exported.' It specifies the verb (Record/capture), resource (Session scene into Arrangement), and the why (export needs Arrangement), distinguishing it from lower-level siblings like fire_scene or set_arrangement_record.

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?

It explicitly explains when to use: 'Live's Export Audio/Video only renders the Arrangement, so a Session-view loop must first be printed there.' It also provides manual alternatives for wait=False ('then call stop_playback and set_arrangement_record(False) yourself'), and warns about overwriting prior captures, giving clear usage context and exclusions.

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

Install Server

Other Tools

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/verove-jordan/ableton12-mcp'

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