ismail: agent DAW (MCP server)

Overview Schema Source Related Servers Discussions Admin

Master Cue

master_cue

Standardize finished audio cues for platform delivery. This tool applies professional loudness normalization (LUFS) and utilizes fixed peak limiting and true-peak catching to ensure delivery compliance.

Instructions

Master a finished cue (a teaser, a stinger, a song for posting) for delivery: cut source to start_s..end_s (seconds; end_s=None keeps the rest), fade the ends (cos^2; 0.4 s out by default), resample to sr, then ONE fixed gain to lufs integrated (BS.1770). Only if that gain puts the true peak (4x oversampled) over the ceiling does a lookahead peak limiter take the excess, and its gain reduction is reported; then a true-peak catch (4x oversampled, +-1.5 ms lookahead, 25 ms release, no re-gain after it) takes whatever the limiter left, so the wav ends at or under tp. With the catch the limiter gets up to 6 rounds, each aiming lower by what the last re-gain put over. mp3=True also writes a 320k mp3 beside the wav, made from a copy caught again at tp - mp3_catch_db (a 320k encode lands up to 1.25 dB over its wav, so 1.2 keeps it under tp); only the mp3 gets that catch, the wav keeps its loudness, and the decoded mp3's true peak is reported. mp3_margin_db lowers the wav's own ceiling to tp - mp3_margin_db (0 by default). tp_catch=False is the master from before (3 plain rounds, no catch). Never a dynamic loudness ride (ffmpeg loudnorm falls back to one on some files). Writes 24-bit wav to out= (default _master.wav beside it, the mp3 as .mp3); a file already there is moved to old/ beside it first, never overwritten. -16 LUFS / -1 dBTP suits most platforms; -14 / -1 for a louder stream. Read the report before anyone listens: it is the measurement line for the round.

Input Schema

Name	Required	Description	Default
`sr`	No
`tp`	No
`mp3`	No
`out`	No
`lufs`	No
`end_s`	No
`source`	Yes
`start_s`	No
`tp_catch`	No
`fade_in_s`	No
`fade_out_s`	No
`mp3_catch_db`	No
`mp3_margin_db`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.0Oct 26, 2026

TDQS

A4.4/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 burden and does so thoroughly: it describes cutting, fades, resampling, fixed loudness gain, limiter behavior, true-peak catch behavior, mp3 handling, and file-overwrite safety. It even discloses that files are moved to old/ rather than overwritten and that it is 'Never a dynamic loudness ride.'

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 purpose is front-loaded, but the description is a single very dense paragraph packed with algorithmic minutiae such as limiter rounds, release times, and mp3 overshoot rationale. The details are informative, but the structure makes it harder to scan than a concise definition should be.

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 a complex 13-parameter audio-processing tool with no annotations and an output schema, the description is complete enough to call correctly. It covers processing behavior, defaults, file handling, mp3 side effects, and tells the agent to read the report; return-value details can be left to 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?

Schema description coverage is 0%, so the description must explain all 13 parameters, and it does: start_s/end_s semantics, fade behavior and default, sr, lufs, tp, tp_catch legacy behavior, mp3, mp3_catch_db, mp3_margin_db, out, and source usage. It adds meaning well beyond the bare schema names and defaults.

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 verb and resource: 'Master a finished cue (a teaser, a stinger, a song for posting) for delivery.' The detailed processing chain makes the operation unmistakable, but it does not explicitly name or contrast with nearby siblings such as render or song_compress.

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 context: finished cues for delivery, with examples like teasers, stingers, and songs for posting, plus platform loudness advice ('-16 LUFS / -1 dBTP suits most platforms'). It does not state when not to use it or name alternative tools.

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

Deploy Server