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

ismail: agent DAW (MCP server)

Live Midi Timecode In

live_midi_timecode_in

Sync an ismail set to another app's MIDI Time Code so playback follows a video player, DAW, or tape machine's play, stop, locate, and speed while keeping the set's own tempo.

Instructions

The set chases another app's MIDI Time Code (MTC) in: a video player, a DAW or a tape machine leads the position, its play, stop and locate. Reach for it when the set should sync to video timecode, chase or follow their timecode or SMPTE time, play when the video plays and stop when it stops (a tempo and beat to follow: live_midi_clock_in; the set leading: live_midi_timecode). source: an input's name or a unique part of it (midi_sources). MTC carries no tempo, so the set keeps its own (live_tempo works) and lays its bar lines on their time: offset ('hh:mm:ss:ff' or seconds, default 0) is their bar 1, and their bars run from there at the set's tempo. When their time runs (eight quarter frames in order, two frames after they start) the set goes silent and comes in on the first of their bar lines it can reach (one to two bars; the news says "their 01:00:04:00 = ismail bar 33"), then keeps its beats on theirs and follows their speed (a varispeed or a tape 1% fast) with tempo changes as live_midi_clock_in makes them (phase_tol_ms 4, tempo_tol_bpm 0.25, max_bend_pct 3, step_beats a bar, bandwidth_hz 0.5). No quarter frame for dropout_ms (250; under it the set plays through the gap): their transport stopped, and the set is silent until their time runs again. A full-frame message (a locate), a jump in their time, or a new rate relocks the same way; running backwards silences it. rate: 24, 25, 29.97 (drop-frame) or 30 to take only that rate (another is not followed, and the news says so); 'any' (the default) takes what they send. An offset their rate has no label for (00:01:00:00 at drop-frame, frame 24 at 24 fps) is not followed: the news and live_status name the label that exists (pin rate= to have it checked when given). A grid live_tempo moved holds through their stops, locates and relocks; a new offset or rate starts it again from offset. A sender that holds quarter frames and lets them out at once plays through: their numbering runs on, so it is no jump. offset_ms: positive lands ismail later, for an app whose sound is late. With MIDI clock in on too, the clock leads (it carries the tempo) and timecode only reads their time. Call again to change a setting; on=False lets go. With no source: the inputs and the chase; live_status shows their time, the lock and the phase. Not yet: placing the set at their exact time (a live set cannot jump), their tempo map, 29.97 non-drop.

Input Schema

NameRequiredDescriptionDefault
onNo
rateNo
offsetNo
sourceNo
projectYes
offset_msNo
dropout_msNo
step_beatsNo
bandwidth_hzNo
max_bend_pctNo
phase_tol_msNo
tempo_tol_bpmNo

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 extensively: it explains silence/relock, dropout handling, rate filtering, invalid offsets, tempo retention, offset_ms, interaction with MIDI clock in, and the effect of on=False. It also discloses current limitations. This is unusually thorough for a control tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the remainder is a dense, run-on wall of text with cryptic references ('the news', 'ismail') and nested parentheticals. Much content is relevant for a complex tool, yet the structure and wording make it hard to parse and more verbose than necessary.

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 12-parameter, annotation-free sync tool with an output schema, the description covers behavior, edge cases, interactions, and limitations thoroughly. The main omission is the required project parameter, but overall it is complete enough for an agent to invoke the tool correctly.

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 define the 12 parameters. It explains source, rate, offset, offset_ms, dropout_ms and the timing/tolerance parameters with units and defaults, but never explains the required project parameter, and some mappings are buried in prose. That substantial coverage justifies a 4 rather than a lower score.

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 opening sentence names a specific operation: the set chases another app's MIDI Time Code (MTC) input. It explicitly distinguishes the sibling live_midi_clock_in (tempo/beat) and live_midi_timecode (the set leading), so an agent can identify the tool without opening the schema.

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?

It gives explicit triggers ('when the set should sync to video timecode, chase or follow their timecode or SMPTE time') and names alternatives for tempo/beat following and for the set leading. It also covers the no-source and on=False cases, leaving little ambiguity about when to call it.

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