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

ismail: agent DAW (MCP server)

Live Midi Fx

live_midi_fx

Apply Ableton-style MIDI effect chains to live keyboard, loopMIDI, or screen-key input so each key plays chords, scales, pitch shifts, velocity, note length, and random variations.

Instructions

MIDI effects on a patched input's keys (live_midi: a keyboard, a loopMIDI port or 'screen keys'): each key plays what a chain of Ableton-style effects makes of it, Chord, Scale, Pitch, Velocity, Note Length and Random. The same core and chain as the studio's track_midi_fx: the same key on the same beat makes the same notes live and rendered, dice included. A recorded take (live_played) keeps the notes the chain made, dice as rolled live, so written into a song it plays what was heard (raw=True there gives the keys). chain: a list of effects applied in order; a new chain replaces the old one. Effects (as track_midi_fx takes them): {'type': 'chord', 'intervals': [0, 4, 7], 'velocity': 0.8}; {'type': 'scale', 'key': 'A', 'scale': 'minor', 'mode': 'nearest' | 'up' | 'down' | 'drop'}; {'type': 'pitch', 'transpose': 12, 'lowest': 'C3', 'highest': 'C6', 'fold': False}; {'type': 'velocity', 'out': [40, 110], 'curve': 0.5, 'random': 10} or {'fixed': 100}; {'type': 'length', 'beats': 0.5} (every note the key starts ends that many beats after it sounded, on the set's clock, whatever the key does) or {'scale': 2} (that multiple of how long the key was held; below 1 a note ends at its key's release live, since the length is known only then); {'type': 'random', 'chance': 0.5, 'choices': 2, 'interval': 12, 'sign': 'up' | 'down' | 'both', 'seed': 0} (key + scale makes the moves scale steps). A key's release ends exactly the notes it started, even when the chain changed while it was held. With live_arp on the same input the chain runs first: the arp steps the notes it makes. at: when it starts, changes or stops ('next_bar' default, 'now', 'next_4', 'bar:17'): keys pressed from that beat use it. off=True takes it off. source alone: that input's chain; nothing: every chain on. live_status shows them. Tell the person what their keys will do before it lands.

Input Schema

NameRequiredDescriptionDefault
atNonext_bar
offNo
chainNo
sourceNo
projectYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.5

TDQS

A4.5/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 discloses that a new chain replaces the old one, how key releases bind to the notes they started even after chain changes, how timing via at applies, and how recorded takes preserve live-generated notes. It also covers dice consistency and interaction with live_arp.

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 content is information-dense and mostly relevant, but it is delivered as a single sprawling block with inline examples, semicolons, and parentheticals rather than structured sections. It is harder to scan than necessary for a five-parameter tool.

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 live MIDI effect-chain tool with no annotations and 0% schema coverage, the description supplies the missing effect syntax, timing, replacement, and live interaction rules. An output schema covers returns, and only the project parameter is left implicit.

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 explain parameters, and it gives detailed semantics for chain effects, at timing values, off, and source/no-source behavior. The required project parameter is not explained, which is a small but real gap.

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: applying MIDI effects to a patched input's keys. It explicitly distinguishes the live chain from track_midi_fx and explains its ordering relative to live_arp, so an agent can identify the tool's role immediately.

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 explains operational context well: chain replacement, off=True, source-only versus no-source behavior, and how live_arp composes with the chain. However, it does not provide a clean explicit decision rule for when to choose this over alternatives beyond the sibling comparisons.

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