Skip to main content
Glama

Live Queue

live_queue

Queue a batch of clips or track stops at musical boundaries, returning clip IDs, landing bars, and runway so you can pre-program arrangements before long jobs.

Instructions

Queue clips (a batch; all or nothing). Each clip: {track, notes and/or lanes, bars, loop, at}. notes: ' [vel]; ...' with beats from the clip start (same as notes_write). lanes: {pitch: 'x...x...'} step strings (same as pattern_write), step = beats per char (0.25). bars (or beats, for odd lengths): clip length; default = whole bars covering the notes. It repeats every length. loop: repeats before it ends (default 'forever': it plays until something replaces it). expr: {lane: [[beat, value], ...]} expression for a performer voice (bend in semitones, vib in cents ...), beats from the clip start; the voice's INFO lists its lanes. at: next_bar (default) | next_beat | next_2 | next_4 | next_8 | next_16 (phrase boundaries counted from bar 1) | asap | bar: | after: (when that clip ends; chain clips to pre-program an arc) | after:# (when item k of this same batch ends: a whole arc in one call, no ids needed). A clip on a track replaces whatever that track would play from its start (a playing clip is cut there; its last notes ring out). {track, stop: true, at} silences a track. The reply gives each clip's id and the exact bar it lands on (moved later when its first notes cannot render in time) and the runway: how long until the queue stops changing. Before a long job (sound design, fitting), queue enough that the runway covers it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
clipsYes
projectYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description must carry the full burden. It discloses several behavioral traits: all-or-nothing batch, replacement semantics (a clip replaces whatever the track would play from its start), stop silencing, reply format (ids and exact bar), and the runway concept. This is substantial, though it doesn't mention permissions or error handling.

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

Conciseness3/5

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

The description is lengthy and dense, packing multiple concepts into nested lists without clear front-loading. While information-rich, it could be better structured with headings or bullets for readability. Some redundancy exists, but most sentences earn their place.

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?

Despite having an output schema, the description explains key return values (clip ids, landing bar, runway) because these are critical for coordinating subsequent actions. It covers all necessary aspects for an agent to construct complex scheduling calls, including chaining via after:<clip id> and after:#<k>.

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%, so the description must compensate. It thoroughly explains the clips array structure and each field: track, notes, lanes, bars, loop, expr, at, and stop, with detailed syntax for note strings, lane step strings, and scheduling options. It also clarifies the project parameter implicitly. This fully compensates for the missing schema descriptions.

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

Purpose4/5

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

The description states a specific verb+resource: queue clips, batch all-or-nothing, contrasted with notes_write and pattern_write. It clearly describes scheduling clips with rich parameters, though it doesn't explicitly differentiate from live_start or live_record beyond the queueing aspect.

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

Usage Guidelines3/5

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

Implied usage for scheduling performance clips, with a note about pre-queueing before long jobs. No explicit when-to-use vs live_start, live_record, or live_cancel alternatives, and no clear exclusions.

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