Skip to main content
Glama
ismail: agent DAW (MCP server)

ismail: agent DAW (MCP server)

Live Queue

live_queue

Queues music clips on tracks with precise timing, loops, and section control, replacing or stopping playback and scheduling batch updates in a text-driven DAW.

Instructions

Queue clips (a batch; all or nothing). Each clip: {track, notes and/or lanes, bars, loop, at}. notes: ' <dur_beats> [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. section: a name for the set section (chapter) these clips and stops belong to; a clip's own 'section' key wins. cancel_section: cut over mid-chapter. Takes back what that section still has to do from cancel_at (a live_queue at value; default where this batch's first clip lands, or the next bar when clips is empty): its clips that start then or later are removed, the ones still playing are cut there (last notes ring out), its stops after it and its effect moves sent with section= are dropped (a glide in progress holds where it is). The batch's own clips are kept even when they reuse the name. Clips queued without a section are never touched.

Input Schema

NameRequiredDescriptionDefault
clipsNo
projectYes
sectionNo
cancel_atNo
cancel_sectionNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.4.0
    • addedInput schema / properties / cancel_at
      Added value: +{
      +  "default": null,
      +  "type": "string"
      +}
    • addedInput schema / properties / cancel_section
      Added value: +{
      +  "default": null,
      +  "type": "string"
      +}
    • addedInput schema / properties / clips / default
      Added value: +null
    • addedInput schema / properties / section
      Added value: +{
      +  "default": null,
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "project",
      -  "clips"
      -]New value: +[
      +  "project"
      +]
  2. First observedv0.3.0

TDQS

A4/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it explains all-or-nothing queuing, track replacement and cutting semantics, last-notes ring out, stop clips, section cancellation details, and return contents (clip id, landing bar, runway). This is unusually complete side-effect disclosure.

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 long but dense and front-loaded: the first sentence states the action and atomicity, then structured parameter docs follow. Given the domain complexity and empty schema descriptions, most lines earn their place, though the cancel_section explanation is somewhat sprawling.

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?

An output schema exists, so return values need not be explained, yet the description still covers the reply shape (id, bar, runway). Combined with deep mutation and cancellation semantics it is nearly complete for a complex live queueing tool, with the unexplained 'project' parameter the main omission.

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%, so the description must compensate. It extensively documents the clips payload (track, notes, lanes, bars, loop, expr, at), plus section, cancel_at, and cancel_section, but never explains the required 'project' parameter, which is a real gap.

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?

States a specific verb and resource ('Queue clips') plus atomic batch scope ('all or nothing'). It references notes_write/pattern_write formats but does not distinguish this tool from the many live_* siblings such as live_start, live_stop, or live_cancel, so it falls short of a 5.

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?

It includes scheduling guidance through the 'at' options and practical advice about runway before long jobs. However, it never states when to choose live_queue rather than sibling tools like live_start, live_cancel, or live_transition, leaving usage implied rather than explicitly routed.

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

Deploy Server

Other Tools