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

ismail: agent DAW (MCP server)

Track Arp

track_arp

Arpeggiate a track's held chords into steps at render, using patterns, step lists, or scale degrees within set bars. Write the arp as plain notes in place of the chords, or turn it off.

Instructions

Arpeggiate a track at render: its held chords (the notes written on it) play as steps, or an exact step list over bars=[a, b]. The same core and settings as live_arp, so a part sounds the same played live and rendered. Any subset of settings changes only those; the first call starts with the defaults for the rest. The track's notes stay as written (notes_read shows the chords); the render plays the arp in their place within its bars. Note source (one of): pattern 'up' (default), 'down', 'updown', 'downup', 'order' (the order the notes start, low first in a chord), 'random', 'chord', or a list of held-note numbers ([1, 3, 2, 4]; 1 = the lowest, 0 = a rest); degrees: scale steps above the lowest held note ([0, 2, 4, 7], needs key and scale); notes: an exact step list 'A3 C4 E4 A4 | F3 A3 C4 F4', one bar per '|' group from bars[0], cycling (needs bars when the track has no notes). rate: beats per step (default 0.25 = 16ths). octaves: 1 to 4 (default 1). key + scale: held notes snap onto the scale; on a step list, key= moves it from the key it was given with, each note kept on its scale degree. transpose: semitones. Per step (a number, or a list cycling on its own length; [] clears): gate (fraction of a step, 0.5), velocity (1-127; default each note's own), accent (0/1: velocity 127), slide (0/1: the step overlaps the next, so a synth with mono and glide glides), octave (-3 to 3), cutoff (Hz: written as the instrument's filter.cutoff on a synth or a sampler with a filter, else the track's first filter effect), pan (-1 to 1, as the track's pan automation over the arp's bars). restart: 'key' (default: each chord starts the pattern again), 'bar', 'off'. swing: 0 to 0.5 of a step. bars=[a, b]: where it plays (default the bars of the track's notes). write=True writes the arp's notes into the track in place of the chords (and the cutoff and pan as automation), and turns the arp off: plain notes to edit (undo brings the chords back). Outside the arp's bars a written lane holds the value the track had at the write (an automation lane is held to the song's ends), so a later track_set pan or filter change does not show there until that lane is changed (automation_set) or cleared; the reply says which. off=True turns it off and keeps the chords.

Input Schema

NameRequiredDescriptionDefault
keyNo
offNo
panNo
barsNo
gateNo
rateNo
notesNo
scaleNo
slideNo
swingNo
trackYes
writeNo
accentNo
cutoffNo
octaveNo
degreesNo
octavesNo
patternNo
projectYes
restartNo
velocityNo
transposeNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.5

TDQS

A4.7/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 burden and does so thoroughly: it explains that settings are incrementally updated with defaults on first call, that write=True replaces chords with plain notes and turns the arp off, that undo restores the chords, and that written automation lanes hold prior values outside the arp bars.

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 content is dense but mostly earns its place given 22 parameters and complex write/automation semantics. It is front-loaded with the core behavior, though the single long block and nested parentheticals make it harder to scan than it could be.

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?

For a complex mutation tool with 22 parameters and no annotations, the description is unusually complete: it covers defaults, render behavior, write semantics, undo, automation persistence, and off behavior. An output schema exists, so the brief note about the reply is sufficient.

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?

Even though schema description coverage is 0% across 22 parameters, the description documents nearly every meaningful parameter: pattern, degrees, notes, rate, octaves, key/scale interaction, transpose, gate, velocity, accent, slide, octave, cutoff, pan, restart, swing, bars, write, and off. It adds formats, defaults, ranges, and interaction rules far beyond the bare schema.

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 opens with a specific verb and resource: arpeggiate a track at render. It distinguishes the tool from live_arp by explaining that this affects rendering while sharing the same core settings, so an agent can tell the two apart without inspecting schemas.

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?

It gives clear context for render-time arpeggiation, including how write=True, off=True, and partial setting updates behave. The live_arp comparison implicitly routes live use elsewhere, but it stops short of an explicit when-to-use/when-not statement naming alternatives.

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