Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Analyze Tuning

analyze_tuning

Checks rendered stems or mixes against the song's 12-TET tuning grid and key, flags notes beyond tolerance, and reports per-part retuning or pitch-drift fixes.

Instructions

Check every part of a render against the song's tuning grid (12-TET) and key, and flag notes more than tol_cents off (ledger:M231). A pitched part off the grid goes unnoticed until someone hears it: drums measured from records keep the records' tuning (a tumba a quarter tone sharp). Run it after the first render of a song with pitched percussion or a voice playing in a new register, and before any exam. Reads: source='render' (default) every track stem of the last render(stems=True); 'ref' the reference's stems; 'track:', 'ref:', 'sound:' or a file path one part; 'render:mix' / 'ref:mix' a whole mix as one part. stems=[names] keeps some parts; bars=[a, b] (inclusive) cuts the range. Per note: the steady pitch from skip_ms (100) after its onset (plucks start sharp for ~90 ms, a drum's strike is noise), read from spectral lines, so a chord reads one pitch per note and a drum its sustained mode; gliding notes and noise are counted, not read. skip_ms is the longest skip: a note shorter than skip_ms / 0.3 (a fast run: a 16th at 104 bpm is ~144 ms) is read from 0.3 of its length, so a picado scale is read, not skipped. The attack is read too (30-80 ms after the onset, less on a short note); a note too short for a steady part is read from its attack on and marked 'attack only' (it still counts against the grid), and one too short to resolve its pitch (under 4 periods of it) is counted, not read. Grid: A4 = 440 Hz moved by tuning_cents; by default 0 for renders, and for a reference ref_retune has not moved, its own measured tuning. key ('A minor', 'D dorian'; default the project's or the sketch's) lists out-of-key pitches as information (they can be intended). Returns a table per part (pitched notes, median cents off the grid, spread = middle half, count beyond tol_cents, attack = median cents of the attack over the steady pitch), up to worst worst notes per part (seconds in the file, bar and beat, note, cents, Hz), and one verdict per part: in tune; the whole part off (retune its voice by N c); a few pitches off (retune that voice or split it onto its own track); or drifting note to note (per-note or per-string detune). When most attacks sit more than 5 c off their steady pitch, the verdict adds "attacks start N c sharp: shorten the voice's pitch glide" (in fast runs that attack is what is heard). A part with no steady pitch (hats, noise, a sliding vocal) says so and is skipped, never flagged. Errors: nothing rendered or no stems -> render(stems=True) first; no reference stems -> separate(source='ref'); an unknown part in stems= -> the reply lists the parts.

Input Schema

NameRequiredDescriptionDefault
keyNo
barsNo
stemsNo
worstNo
sourceNorender
projectYes
skip_msNo
tol_centsNo
tuning_centsNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

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 the pitch-reading method, skip_ms fallback behavior, attack-only handling, what is skipped and never flagged, grid and key defaults, verdict categories, and error recovery steps. This is far beyond what the schema and annotations provide.

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 the detailed sections are structured by concern: reads, per-note method, grid, returns, verdicts, errors. It is dense and long, with some illustrative details that border on excessive, but most sentences contribute useful operational context for a complex analysis 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?

The tool has 9 parameters, no annotations, a complex DSP-based behavior, and an output schema. The description covers prerequisites, error paths, skipped-part handling, return structure, and interpretation guidance, leaving no significant gap for correct invocation.

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 compensate, and it largely does: it enumerates source modes ('render', 'ref', 'track:<name>', 'ref:<stem>', 'sound:<name>', 'render:mix', 'ref:mix'), explains stems and bars filtering, defines skip_ms behavior, describes tuning_cents and key defaults, and explains tol_cents and worst. Only 'project' is left implicit, which is minor.

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 opens with a specific verb and resource: 'Check every part of a render against the song's tuning grid (12-TET) and key, and flag notes more than tol_cents off.' That is enough to distinguish it from neighboring analysis tools like analyze_key or analyze_pitches.

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 a clear trigger: 'Run it after the first render of a song with pitched percussion or a voice playing in a new register, and before any exam.' It does not name an explicit alternative tool to use instead, but the usage context is concrete enough to guide selection.

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

Deploy Server

Other Tools