Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Live Midi

live_midi

Routes MIDI inputs such as keyboards, pads, or loopMIDI ports through a live set so players hear their notes from the same speakers; reports connected sources and patches tracks or instruments.

Instructions

Play a MIDI input (a keyboard, a pad, a loopMIDI port) through the live set: the person plays along from the same speakers. source: the input's name or a unique part of it (midi_sources), or 'screen keys' (the on-screen keys page, live_keys_page); with no source, says what is plugged in and what is patched. What it plays: track='' (that track's sound, its baked effects included) or instrument=... (as live_track takes it: 'preset:', a dict, a code voice). Call again with another track or instrument to swap: the old sound plays until the new notes land. The notes render once on the render workers (C2 to C7, or a kit's pads; a few seconds to a minute); a key then sounds one output buffer after the press (live_status says how long). Played keys skip the track's effects and the safety limiter (a soft clip guards them). volume_db: the keys' level, at most +6 (default: the track's fader, or -6 dB for an instrument). transpose: semitones; channel: 1 to 16 (0 = every channel, the default). Every key is logged with the beat it sounded against to /live/midi/.jsonl (live_played reads it back as notes). remove=True unpatches. Tell the person before their keys first sound.

Input Schema

NameRequiredDescriptionDefault
trackNo
removeNo
sourceNo
channelNo
projectYes
transposeNo
volume_dbNo
instrumentNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the behavioral burden well. It discloses render timing, real-time latency, effect/limiter skipping, soft-clip protection, logging path, volume cap, default levels, swap behavior, and that remove=True unpatches.

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 purpose is front-loaded and most sentences add useful detail. The paragraph is dense and could be structured more clearly, but it avoids obvious filler.

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?

Given the complex real-time behavior and eight parameters, the description covers what the agent needs to call it correctly, including side effects and timing. Output schema handles return values, so no return explanation is required.

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 meaningfully explains source, track, instrument, volume_db, transpose, channel, and remove, but does not describe the required project parameter.

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 starts with a specific verb and resource: 'Play a MIDI input ... through the live set.' It clearly distinguishes this from related tools like midi_sources, live_keys_page, live_played, and live_status by naming them in context.

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 using the tool: a person playing along live, with source choices and swap behavior. It references alternatives for subtasks (midi_sources for names, live_keys_page for screen keys, live_played for logged notes), though it does not explicitly contrast with midi_play or live_midi_out.

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