ismail: agent DAW (MCP server)

Overview Schema Source Related Servers Discussions Admin

Live Midi Out

live_midi_out

Sends a live track's notes as MIDI to a hardware synth or DAW port, syncing them to the set so your own instrument plays the part.

Instructions

Send a live track's notes out as MIDI to a port: a hardware synth, or a loopMIDI port (Windows) or the IAC bus (Mac) into Ableton, FL Studio or any DAW, whose instrument then plays the part. Reach for it when the person wants a set's part played by their own synth or plugin, or ismail's notes in their DAW while the set plays. track: a live track, or a deck's part ('A.bass'); port: an output's name or a unique part of it (midi_ports lists them); channel: 1 to 16 (default: 10 for a kit or drum, else the lowest free one on that port). Every note its clips play from at (default 'now': the first beat the mixer has not mixed) goes out with its velocity and length, transposed with its deck, at the moment its audio would reach the speakers, so the synth lines up with the set. audio=False takes the track off the speakers and the render workers (the synth is its sound); True brings it back (from its next renders, a few seconds). offset_ms: moves every message on that port later, or earlier when negative, to meet a synth's or a DAW's own delay (-500 to 2000; set it by ear against the kick). Call again to change channel, audio or offset; another port moves it. remove=True stops it: each held note gets its note-off, then All Notes Off (CC 123) on its channel. A stop or the set's end does the same. With no track: the outputs, the routes and the clock. Clock out: live_midi_clock.

Input Schema

Name	Required	Default
`at`	No	now
`port`	No
`audio`	No
`track`	No
`remove`	No
`channel`	No
`project`	Yes
`offset_ms`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.0Oct 26, 2026

TDQS

A4.9/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 richly: notes start from `at`, carry velocity/length/transposition, align to speaker timing, audio=False removes the track from speakers and render workers, offset_ms shifts messages, and remove=True sends note-offs followed by CC 123. These are exactly the mutation and lifecycle details an agent needs.

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 nearly every clause adds useful operational detail, but the definition is one very dense paragraph with semicolon-chained asides. It earns most of its length but could be structured more clearly for such a complex 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 an 8-parameter, annotation-free tool with an output schema, the description covers timing, routing, defaults, lifecycle, cleanup behavior, and clock alternatives. Nothing essential is missing; return-value details can safely live in the output schema.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage across 8 parameters, the description explains almost every one: `track` accepts a live track or deck part like 'A.bass', `port` accepts a name or unique fragment with midi_ports as the source, `channel` is 1-16 with a kit/drum default, `at` defaults to 'now', and `offset_ms` has a stated range and sign convention. The only unexplained parameter is the obvious required `project`, so the compensation is excellent.

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?

States a specific verb and resource: sending a live track's notes as MIDI to a named port, with concrete destinations (hardware synth, loopMIDI, IAC bus, DAW). It also distinguishes itself from the clock-out sibling at the end, so an agent can tell what it does and what it does not.

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?

Explicitly says when to reach for it: when the person wants a set's part played by their own synth or plugin, or its notes in a DAW. It also routes clock use to live_midi_clock and explains how to change routing later, which is strong alternative/edge-case guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server