ismail: agent DAW (MCP server)

Overview Schema Source Related Servers Discussions Admin

Live Start

live_start

Starts a project's live audio engine at a specified BPM, playing from bar 1 and looping queued clips across calls; configure audio device, render workers, and output levels.

Instructions

Start the live engine for project (any folder; a project.json there lends its sound bank, song voices and 'track:' instruments). It plays from bar 1 immediately, silent until you queue clips, and keeps playing between your calls: clips loop until replaced. bpm is the starting tempo: live_tempo changes it while it plays. device: 'default' (speakers), a device name/index, or 'none' (no audio out; for testing and listen-only analysis). workers: render processes (default: cores - 4, from 2 to 4; more for many mimic voices). Output always passes the safety chain: trim, loudness cap, limiter, ceiling -1 dBFS. trim_db (-30 to +12) and cap_db (sustained RMS dBFS, -40 to -8) set this set's level; left out, they come from the live.trim_db / live.cap_db settings (config_set), else -6 and -16 (quiet, about -22 LUFS). A set for listeners: trim_db=4, cap_db=-12 (about -16 LUFS). priority: the engine process's own priority, 'above_normal' (default), 'high' or 'normal'; its render workers stay normal ('high' can starve them). The reply names any other live engine still running on this machine (two on one device can freeze both). Next: live_track, then live_queue.

Input Schema

Name	Required	Default
`bpm`	Yes
`cap_db`	No
`device`	No	default
`project`	Yes
`trim_db`	No
`workers`	No
`priority`	No	above_normal
`beats_per_bar`	No
`follow_device`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.4.0Oct 26, 2026

addedInput schema / properties / cap_db

Added value: +{
+  "default": null,
+  "type": "number"
+}

addedInput schema / properties / priority

Added value: +{
+  "default": "above_normal",
+  "type": "string"
+}

addedInput schema / properties / trim_db

Added value: +{
+  "default": null,
+  "type": "number"
+}

First observedv0.3.0Oct 3, 2026

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 well: it explains immediate playback from bar 1, silence until clips are queued, looping that persists between calls, tempo behavior during playback, device output options, worker defaults/ranges, the safety chain, default levels, and priority tradeoffs. It also warns that another running live engine can freeze the device.

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 description is front-loaded with the main action and playback behavior, and most sentences add meaningful operational detail for a complex, annotation-free tool. It is dense and semicolon-heavy in a single block, so structure could be improved, but there is little outright waste.

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 9-parameter tool with no annotations and no schema parameter descriptions, the description is substantially complete and explains return-related behavior at a high level without needing to restate the output schema. The main gap is that beats_per_bar and follow_device are left completely unexplained.

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 does for most parameters, including project semantics, bpm, device options, worker defaults and ranges, trim_db/cap_db ranges and defaults, and priority values. However, beats_per_bar and follow_device are never mentioned, leaving two of nine parameters undocumented anywhere.

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 precise verb and resource: start the live engine for a project. It also distinguishes related workflow steps by naming live_track, live_queue, live_tempo, and config_set, so the agent can place the tool in the live-performance workflow.

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?

The description makes clear this is the entry point for live playback and gives the next workflow steps (live_track, then live_queue). It also explains the 'none' device case for testing/listen-only analysis, but does not explicitly compare with live_stop, live_control, or other *start tools.

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

Deploy Server