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

ismail: agent DAW (MCP server)

Live Link

live_link

Joins an Ableton Link session so a DAW project follows the session's tempo and beat, syncing with Ableton Live or other Link apps on the same network for shared timing and network jams.

Instructions

The set joins an Ableton Link session: Ableton Live, Bitwig, a phone or tablet app, or any other Link app on the same network or computer, all at one tempo and on one beat. Reach for it when the set should sync with Link, play in time with Ableton Live over the network, jam with a Link app, or share its tempo with other apps (MIDI cables and ports instead: live_midi_clock_in, live_midi_clock). live_link(project) joins and follows: the session's tempo and beat phase lead the set. Their bar lines are where Link's phase is 0 (quantum beats apart, the set's beats per bar by default). Joining waits 1 s for peers. Alone, the session takes the set's beat and nothing is heard to change; with peers the set stays as it is when it already plays on their beat and bar lines, else it goes silent and comes in on the session's next bar line it can reach (one to two bars), then keeps its beats on theirs 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; offset_ms: positive lands ismail later). A peer's tempo change is heard about 1.5 s later (the set's notes render again from it); their beat jumping, or the set more than a beat off, relocks the same way. While it only follows, live_tempo is refused. lead=True: live_tempo works and each change reaches the session when its bar is heard. follow=False, lead=True: ismail is the session's clock: its tempo and bar lines go to the session at once (the peers jump to them), a peer's tempo change is set back; a second leader that keeps putting its own back is not fought (the news names live_link(follow=True) and live_link(lead=True)). start_stop=True: Link's start/stop sync; following, the session's stop silences the set and its start brings it in on the next bar line; leading, joining starts the session and leaving stops it. Call again to change a setting: it relocks only when it moves their bar lines off the set's (the news says which); on=False leaves. live_status shows the peers, the session's tempo and beat, the lock and the phase. Refused while MIDI clock in or timecode in is on (one leader). Needs the aalink add-on (pip install "ismail[link]", or under uvx the line the error names; GPLv3+, while ismail stays MIT): without it the call says what to install and installs nothing. Not yet: bridging clock in or timecode in into a Link session.

Input Schema

NameRequiredDescriptionDefault
onNo
leadNo
followNo
projectYes
quantumNo
offset_msNo
start_stopNo
step_beatsNo
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.1/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 discloses join waiting time, alone-versus-peer behavior, relocking, silence and re-entry on bar lines, live_tempo refusal while following, leader/follower semantics, start_stop behavior, reconfiguration effects, off behavior, dependency requirements, and current limitations.

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 description is information-dense but poorly structured, with long run-on sentences, unclear referents, and awkward phrasing such as 'positive lands ismail later' and 'the news says which.' The front-loaded first sentence is useful, but overall readability and concision suffer significantly.

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 complex synchronization tool with 11 parameters and no annotation coverage, the description is largely complete: it covers prerequisites, refusal cases, dependency installation, leader/follower behavior, and unsupported bridging. The output schema exists, so return-value details are not required here, though parameter semantics could still be clearer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 the 11 parameters. It mentions all of them at least minimally, including lead, follow, start_stop, on, quantum, offset_ms, phase_tol_ms, tempo_tol_bpm, max_bend_pct, and step_beats, but several are only given as default values and the offset_ms explanation is garbled by an apparent typo, leaving some semantics thin.

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 a specific action: joining an Ableton Link session so the set syncs tempo and beat with peers. It distinguishes the tool from nearby alternatives such as live_midi_clock_in, live_midi_clock, live_tempo, and live_status, though the dense prose makes the core purpose less immediately clear than it could be.

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 explicitly says when to reach for it: syncing with Link, playing in time with Ableton Live over the network, jamming with a Link app, or sharing tempo. It also names alternatives for MIDI clock use and states refusal conditions when MIDI clock in or timecode in is active.

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