Skip to main content
Glama

live_arranger

Manage arranger sections in a running Studio One session: list, jump to, create from markers, rename, resize, move, copy, or delete sections and set jump sync timing.

Instructions

Arranger sections in the running Studio One. sections: list them (numbered in song order). goto: a section by number or name; while playing it jumps at the arranger's sync point, while stopped it moves the playhead to the section's start. next / previous: step while playing. syncMode: when jumps happen (off = immediately, 1bar, 2bars, 4bars, end of section); changing it is an undo step. createFromMarkers: make sections between markers. Editing (each one live_undo): add {start, end, name}, rename {section, name}, resize {section, end}, move {section, start}, remove {section}; these change only the section, not the events under it. With its content, on every track: copy {section, to} inserts a copy at a position (what follows moves later); delete {section} removes it and everything in it, closing the gap; move {section, to, content: true} does both (two undo steps). Positions are seconds or bars like "9.1.1.0". The loop range is kept.

Input Schema

NameRequiredDescriptionDefault
toNoFor copy, and move with content: where it goes (best a section boundary)
endNoFor add and resize
nameNoFor add and rename
syncNoFor syncMode
startNoFor add and move
actionYes
contentNoFor move: take the events under the section along
sectionNoSection number or name (goto jumps while playing only to 1-16)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.5/5.0
Behavior5/5

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

With zero annotations the description carries the full burden and does so well: it discloses playback-dependent jump behavior, the sync-point concept, undo cost (one undo step per edit, two for move-with-content), that delete is destructive and closes the gap, and that the loop range is preserved.

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?

Dense but each clause carries information — action semantics, undo cost, position format. It is a single long run-on paragraph rather than a structured list per action, which costs some scannability for a 13-action tool.

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 an 8-parameter, 13-action mutation tool with no annotations and no output schema, the description covers action semantics, destructive effects, undo accounting, and position formats. It does not describe what 'sections' returns or how syncMode setting interacts afterward, leaving a small residual gap.

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 coverage is already 88%, so the baseline is 3; the description adds real meaning beyond it by tying params to actions (to/end/name/start/content/sync), specifying position syntax ('seconds or bars like "9.1.1.0"'), advising 'to' be a section boundary, and warning goto-while-playing only reaches sections 1-16.

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?

Opens with a specific verb+resource (arranger sections in the running Studio One) and then enumerates all 13 actions in plain terms, so an agent knows exactly what domain this covers. Naming 'createFromMarkers' implicitly separates it from the sibling marker tools.

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?

Guidance is given per action: 'next / previous: step while playing', 'goto ... while playing it jumps at the arranger's sync point, while stopped it moves the playhead', and 'Editing (each one live_undo)' cross-references the undo sibling. There is no explicit statement of when to prefer live_markers/live_markers-family tools over this one, so not a 5.

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