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

ismail: agent DAW (MCP server)

Live Arp

live_arp

Turns a patched MIDI input into a beat-synced arpeggiator, letting held keys drive timed steps with pattern, rate, gate, and per-step controls; also starts, updates, stops, or reports active arps.

Instructions

An arpeggiator on a patched input (live_midi: a keyboard, a loopMIDI port or 'screen keys'): its keys stop sounding as they are pressed and drive steps on the set's beat instead, landing on the beat the person hears. The same core as the studio's track_arp: same settings, same notes. Any subset of settings changes only those; the first call starts it with the defaults for the rest. with no source: says which arps are on. Note source (one of): pattern 'up' (default), 'down', 'updown', 'downup', 'order' (as pressed), 'random', 'chord', or a list of held-key numbers ([1, 3, 2, 4]; 1 = the lowest held key, past the last goes up an octave, 0 = a rest); degrees: scale steps above the lowest held key ([0, 2, 4, 7], None = a rest; needs key and scale); notes: an exact step list 'A3 C4 E4 A4 | F3 A3 C4 F4', one bar per '|' group, switching on bar lines, each group cycling inside its bar ('.' a rest, 'C4,E4' two at once); it plays with no keys held. rate: beats per step (default 0.25 = 16ths, 1/3 = 8th triplets; 1/64 to 4). octaves: 1 to 4 (default 1). key ('A', 'F#') + scale ('minor', 'major', 'dorian' ... or semitones [0, 2, 3, ...]): held keys 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 the key's own), accent (0/1: velocity 127), slide (0/1: the step ties into the next; live it re-attacks, the studio's mono synths glide), octave (-3 to 3), cutoff (Hz: a low-pass on that step's note), pan (-1 to 1). restart: 'key' (default: a key pressed starts the pattern again at the next step), 'bar', 'off'. swing: 0 to 0.5 of a step, every second step. latch=True: keys keep playing after release until a new chord is pressed. at: when it starts or changes ('next_bar' default, 'now', 'next_4', 'bar:17'). off=True stops it (at= a bar line too). live_status shows its state. live_played still logs the keys pressed, not the steps. Not yet: the input's bend, pressure and mod wheel (live_midi lanes) do not move the steps.

Input Schema

NameRequiredDescriptionDefault
atNonext_bar
keyNo
offNo
panNo
gateNo
rateNo
latchNo
notesNo
scaleNo
slideNo
swingNo
accentNo
cutoffNo
octaveNo
sourceNo
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.3/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 unusually well: it discloses first-call defaulting, scheduling via 'at' ('next_bar' default, 'now', 'next_4', 'bar:17'), latch semantics ('keys keep playing after release until a new chord is pressed'), restart modes, and off behavior. It also flags side effects on siblings ('live_status shows its state. live_played still logs the keys pressed, not the steps') and an explicit limitation ('Not yet: the input's bend, pressure and mod wheel ... do not move the steps').

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?

Content is dense and every clause carries real information, and the purpose is front-loaded. However, the prose is a wall of run-on sentences with awkward line breaks that split mid-clause, and there is no grouping or ordering that maps to the 22 parameters, making it hard to scan during a live call.

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 a 22-parameter live mutation tool with no annotations and an existing output schema, the description covers behavior, parameter semantics, defaults, and known limitations thoroughly. The remaining gap is the required 'project' parameter, which is never mentioned, and no error or failure conditions are described.

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% across 22 parameters, so the description must compensate, and it does: it enumerates pattern values ('up' default, 'down', 'updown', 'downup', 'order', 'random', 'chord', or held-key numbers), note-list syntax with '.' rests and '|' bar groups, rate ranges (1/64 to 4, default 0.25), octaves 1-4, gate 0.5 default, velocity 1-127, accent 0/1, slide, octave -3 to 3, cutoff in Hz, pan -1 to 1, swing 0-0.5, and the list-cycling/`[]` clears rule. Only the required 'project' parameter is left unexplained.

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 opening sentence names a specific resource and mechanism: 'An arpeggiator on a patched input (live_midi: a keyboard, a loopMIDI port or "screen keys")', and the description explicitly relates it to the sibling 'track_arp' by saying it is 'the same core as the studio's track_arp'. The purpose is clear, though it takes a long, tangled first sentence to get there and the reader must parse past the key definition.

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 concrete operative rules: 'Any subset of settings changes only those; the first call starts it with the defaults for the rest', 'off=True stops it', and 'with no source: says which arps are on' as a query mode. The reference to track_arp as the studio counterpart implies when to pick this one, but there is no explicit 'use X instead when Y' routing statement.

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