Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Melody Consensus

melody_consensus

Extracts consensus melody notes from repeated phrase bars, removes sustained backing, resolves octave, rest, and legato choices, and optionally writes notes to a track.

Instructions

The lead line of a phrase that repeats, when its stem also carries a backing part (a pad, a chord, a second voice): analyze_melody warns of a second part within 6 dB, notes_from_audio_loop doubles the lead at the octave. reps = the bar where each repetition of the phrase starts ([17, 25, 49, 57]); phrase_bars = its length. Every candidate pitch in [low, high] scores its first five harmonics on a constant-Q spectrum (an octave below the lead scores less than the lead), the scores are averaged over the repetitions, and each step takes the best pitch. Before scoring, what sounds through nearly all of the phrase comes off: each bin loses its held_pct percentile over the phrase's steps, so a held pad or chord stops winning (a lead holding one pitch through more than 100 - held_pct percent of the phrase would go with it: pass held_pct=None). A new note starts where the pitch changes or where the start of a step is onset_db louder than the step before. Steps rest_db or more under the loudest are rests; one-step notes quieter than short_db drop (None keeps them); gaps of up to legato_steps close up (0 keeps them). Returns notes_write rows with beats from the phrase's first bar, then a summary: notes per bar, confidence (how many repetitions picked the same pitch on their own, and the margin over the runner-up) and the notes where the octave choice was close. track= writes the phrase into that track at every bar of write_at (default: reps) with notes_write(mode=mode). Repetitions that differ (variants, fills) pull the average apart: pass only the bars where the phrase really repeats.

Input Schema

NameRequiredDescriptionDefault
lowNoC3
highNoC7
modeNoreplace
repsYes
trackNo
sourceYes
projectYes
rest_dbNo
held_pctNo
onset_dbNo
short_dbNo
write_atNo
phrase_barsYes
legato_stepsNo
steps_per_beatNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A3.8/5.0
Behavior4/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 substantial work: held_pct subtraction of sustained content, onset/rest thresholds, and that track= writes notes into a track at write_at via notes_write(mode=mode). It doesn't explicitly state that the write can overwrite existing notes or what happens on failure, so side-effect disclosure is only implied through the mode parameter.

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 content largely earns its place, but it is delivered as dense run-on prose with parenthetical asides and no paragraph or bullet structure, making it hard to scan. It is not front-loaded on the primary action; sibling context and algorithm internals precede a clean statement of what the tool returns.

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 complex 15-parameter, no-annotation tool, the description covers the algorithm, key thresholds and the write path thoroughly, and it explains the returned summary even though an output schema exists. Remaining gaps (steps_per_beat, mode options, project/source semantics) are minor relative to the overall coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage and 15 parameters, the description must compensate, and it gives real meaning to reps, phrase_bars, low/high, held_pct, onset_db, rest_db, short_db, legato_steps, write_at and track. However steps_per_beat, project, source, and the accepted mode values are never explained, leaving several parameters undocumented anywhere.

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 makes clear this extracts a lead line from a repeating phrase by scoring candidate pitches across repetitions and returning notes_write rows. It also names two siblings (analyze_melody, notes_from_audio_loop) and their failure modes, aiding differentiation. The core purpose statement is buried in a run-on opening rather than front and center, but it is identifiable.

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 explains implicitly when to reach for this rather than analyze_melody (warns of a second part within 6 dB) or notes_from_audio_loop (doubles the lead at the octave), plus 'pass only the bars where the phrase really repeats' as a data-hygiene hint. It doesn't give explicit when-not-to-use or prerequisites (e.g., source must be a stem with a lead), so it stops short of a 5.

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