ismail: agent DAW (MCP server)

Overview Schema Source Related Servers Discussions Admin

Live Fx

live_fx

Change effect parameters in a live chain, gliding them over a beat ramp or scheduling multiple parameter moves at once. Clear scheduled moves to hold current values before reusing a track.

Instructions

Change params of one effect in a live chain. target: a track, or 'bus:'; index: 0-based position in its chain (live_status lists chains), or the effect's type ('filter'; 'filter:2' = the second filter), which survives edits to the chain. Automatable params (fx_help lists them: cutoff, mix, gain_db, depth ...) glide from their current value to the new one over ramp_beats, starting at at ('now' or a live_queue value): one call = a filter sweep over 8 bars, a fade, a build. Frequencies glide in log space. Other params rebuild that chain at at (the old tail rings out). A chain scheduled with live_track(fx=..., at=...) can be swept before it plays: an at at or after its swap targets the new chain, and a swap drops the sweeps written for the old one. clear=True cancels the scheduled moves on the target from at on (one effect with index, or every effect and the volume without it): each param holds where it is. Use it before a section reuses a track whose old choreography is still scheduled. moves: a list of these calls as dicts, [{target, index, params, ramp_beats, at}, ...], scheduled in one call (a whole cycle of throws, sweeps and gaps; ismail.live.djkit builds them). section: a set section's name on the glides (or 'section' in each move): live_queue(cancel_section=) then takes them back with that section's clips.

Input Schema

Name	Required	Default
`at`	No	now
`clear`	No
`index`	No
`moves`	No
`params`	No
`target`	No
`project`	Yes
`section`	No
`ramp_beats`	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 / section
```
Added value: +{
+  "default": null,
+  "type": "string"
+}
```
First observedv0.3.0Oct 3, 2026

TDQS

A4.7/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 thoroughly: it explains glide behavior, log-space frequency interpolation, chain rebuild effects with ringing tails, scheduled-chain swap semantics, and what clear=True cancels. This is unusually rich behavioral disclosure.

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 core action and then elaborates on scheduled behavior, clear, moves, and sections. It is dense and somewhat run-on, but for a 9-parameter scheduling tool most sentences carry necessary semantics rather than filler.

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?

Given the complex live-chain scheduling behavior, no annotations, 0% schema coverage, and a rich output schema, the description is complete enough for correct invocation. It explains interactions with live_track, live_queue, scheduled swaps, clear cancellation, and multi-move batches.

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?

Schema description coverage is 0%, so the description must explain all 9 parameters. It covers target forms, index semantics including type-based indexing, automatable params, ramp_beats, at values, clear behavior, moves list structure, and section tagging. Only project is implied, but that is the required context parameter.

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 description states a specific verb and resource: 'Change params of one effect in a live chain.' It also clarifies scope: single effect by index/type, multi-move scheduling, and bus/track targeting. An agent can distinguish it from general effect editing tools like fx_set.

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?

It gives clear usage conditions, including sweeping a scheduled chain before it plays and using clear=True before a section reuses a track. It references live_status, fx_help, live_queue, and djkit as supporting tools, though it does not explicitly contrast live_fx with siblings like fx_set or automation_set.

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

Deploy Server