ismail: agent DAW (MCP server)

Overview Schema Source Related Servers Discussions Admin

Live Track

live_track

Create or modify a live track in a text-driven DAW, setting instrument, effect chain, volume, pan, sends, routing, deck, or removal so agents can arrange and mix projects without audio feedback.

Instructions

Create or change a live track. instrument: a dict (instrument_help), 'preset:' (presets_list), {'type': 'code', 'voice': ''} (voices_list) or 'track:' (copy from the folder's project.json). fx: the track's whole effect chain, a list of effect dicts (fx_help), 'stack:' for a saved effect stack (fx_stack_list; the reply says what it costs on this machine), or 'track:' to copy a project track's chain; [] removes all. Sidechain/duck/vocoder sources must be live tracks. sends: {bus: dB} replaces the track's sends (post-fader; live_bus creates buses). output: a bus the new track plays into instead of straight into the master (or its deck); the bus still reaches the master. A stream of that bus (live_stream(name='bus:')) then carries only the tracks routed to it, which a send cannot do (the dry track stays on the master). It is set when the track is created; to move a track, remove it and create it again. A new instrument or chain on a playing track takes over at at (live_queue values, or 'now'); a replaced chain's tail rings out. New instruments warm up off the air first (live_status shows WARMING). volume_db <= +6. remove=True silences and deletes the track now. To move one effect param (a sweep, a fade), use live_fx instead of resending the chain. deck='B' puts a new track on deck B (created if needed): it then plays through that deck's strip and cue.

Input Schema

Name	Required	Default
`at`	No	next_bar
`fx`	No
`pan`	No
`deck`	No
`sends`	No
`track`	Yes
`output`	No
`remove`	No
`project`	Yes
`volume_db`	No
`instrument`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.4.0Oct 26, 2026
- addedInput schema / properties / output
```
Added value: +{
+  "default": null,
+  "type": "string"
+}
```
First observedv0.3.0Oct 3, 2026

TDQS

A4.1/5.0

Behavior5/5

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

With no annotations at all, the description carries the full disclosure burden and does so unusually well: a replaced chain's tail rings out, new instruments warm up off-air (visible as WARMING in live_status), scheduling obeys `at`/live_queue or 'now', volume_db is capped at +6, and remove=True silences and deletes immediately. It also flags the irreversible gotcha that bus output is fixed at creation and can only be changed by remove-and-recreate.

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?

The core purpose and the most-used alternatives are front-loaded, but the body is a dense run-on that interleaves instrument formats, effect-chain semantics, bus routing, deck behavior, scheduling, and deletion in one undifferentiated block. Every sentence carries information, yet it would be far more scannable as separate lines per parameter.

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 an 11-parameter, unannotated, nested-object live-performance tool, the definition is substantively complete: it explains creation vs. mutation, scheduling, warm-up, volume limits, and destruction. The remaining holes are `pan` and an explicit statement of what the `track` name means when the track does not yet exist; return values are covered by the output schema, so those need not be described.

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% with 11 parameters, so the description must compensate, and it mostly does: it spells out the accepted forms for instrument ('preset:<name>', {'type':'code','voice':...}, 'track:<name>'), fx (effect dict lists, 'stack:<name>', 'track:<name>', [] to clear), and sends ({bus: dB}, post-fader, replacing existing sends). `pan` is never mentioned, and `project`/`track` are only obliquely implied by 'the folder's project.json', leaving real gaps.

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?

Opens with a specific verb and resource ('Create or change a live track') and immediately enumerates the domains it governs: instrument, fx, sends, output routing, volume, deck, removal. It differentiates from live_fx and live_bus by name. It does not, however, distinguish itself from track_add/track_set, so an agent facing 200+ siblings has to infer that 'live' means the performance rig rather than the studio project.

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?

Gives at least two concrete routing rules: use live_fx for a single param sweep/fade rather than resending the chain, and live_bus to create buses referenced by sends/live_stream. It also constrains when output routing can be set (only at creation; to move a track, remove and recreate). No explicit exclusion against track_add/track_remove, so guidance is strong but not complete.

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

Deploy Server