Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Live Played

live_played

Reads the notes a player performed on their MIDI keyboard so you can quote a phrase or record the take into a song track, optionally snapping it to a grid.

Instructions

What the person played on their keys, as notes text: 'bar | +beat | pitch | d= | v=' lines in this engine's bars, the same notes format tracks take (note-offs held while the sustain pedal was down). bars: the last bars bars that had keys, or [a, b] for those bars (ask the player which part; never guess). Per input (source: one input). Read it to answer what they played or to quote a phrase back. Clock: each note is where it sounded against the beat the player heard (the press plus the keys' delay to the speakers, which the header names in ms), because a player by ear lines up what they hear with the kick. To loop a take back, use fit=True rather than rounding the lines to the grid: it groups the hits (keys within 0.15 beat are one), fits a 16th grid with a free offset, says the offset, the rms error in ms, the drift per bar and the rhythm's shape in 16ths (3-3-2), and prints the snapped notes twice as live_queue notes (beats from the clip start, bar 1 = the take's first bar, or from_bar): A as played, B with the first hit on a downbeat. Where the take sits against the kick is a musical choice the data cannot make: play both and let the player pick by ear. When every key has the same velocity (a keyboard that sends one), the reply says so and suggests an accent shape; the lines keep the velocity. Recording into the song: into='' writes the take into that track of the project in this folder (an existing track: track_add first, with the sound to keep), one input at a time. Reach for it when the person wants to record what they played on their MIDI keyboard into a track of the song (keep a take), instead of copying the lines into notes_write. bar: where the take's first bar lands (from_bar picks which of the engine's bars is that first bar; default the first bar with a note). mode='replace' clears the bars the take covers on the track first, 'add' merges. Without fit it writes the take as it sounded: off the grid where it was played, each note's velocity and length, the pedal's holds. With fit=True it writes the snapped notes, placement='A' (as played, the default) or 'B' (the groups from beat 1) as the reply named them; ask the player first. The reply says what was written, how to hear it, and undo() takes it back.

Input Schema

NameRequiredDescriptionDefault
barNo
fitNo
barsNo
intoNo
modeNoreplace
sourceNo
projectYes
from_barNo
placementNoA

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.4.3
    • addedInput schema / properties / bar
      Added value: +{
      +  "default": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / into
      Added value: +{
      +  "default": null,
      +  "type": "string"
      +}
    • addedInput schema / properties / mode
      Added value: +{
      +  "default": "replace",
      +  "type": "string"
      +}
    • addedInput schema / properties / placement
      Added value: +{
      +  "default": "A",
      +  "type": "string"
      +}
  2. Addedv0.4.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations to lean on, the description carries the full behavioral load and does so: it explains latency-compensated timestamps relative to the heard beat, the fit algorithm's tolerance (0.15 beat grouping, 16th grid, offset, rms error in ms, drift), the velocity caveat when a keyboard sends a single velocity, the destructive semantics of mode='replace' (clears covered bars) vs 'add', and that undo() reverses the write.

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?

Nearly every sentence carries real information (format contract, clock semantics, fit behavior, write semantics, undo), but the result is a ~370-word wall of dense multi-clause sentences with no front-loaded summary and no structure markers. The most important routing instruction ('Use into=... when the person wants to keep a take') sits in the middle of the block.

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 less explanation, and the description still covers write behavior, audible verification, and undo. For a 9-parameter mutation tool with zero annotation coverage, the only meaningful gaps are the undocumented `project` parameter and any preconditions about a connected keyboard or live session state.

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% across 9 parameters, so the description must compensate, and it defines nearly all of them: bars (last N bars with keys or [a,b]), source (one input), fit, into (must be an existing track), from_bar, mode replace/add, and placement A/B. The required `project` param is never explained, and `bar` is described as 'default the first bar with a note' while the schema declares default 1, a minor inconsistency that could confuse.

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 description states the resource precisely (the notes a person played on their MIDI keys, in the engine's bar|beat|pitch format) and gives the verb mid-way through: 'Read it to answer what they played or to quote a phrase back.' It also distinguishes the tool from siblings by naming notes_write and live_record contexts, but the purpose is buried behind format detail rather than stated up front.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit alternatives and conditions are everywhere: use fit=True to loop a take rather than rounding lines, use into='<track>' when the player wants to keep the take in a track instead of copying lines into notes_write, ask the player which bars/[a,b] range and never guess, and play both placements A/B so the player can pick by ear. When-not guidance and prerequisites (existing track via track_add) are both present.

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