Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Notes Clash

notes_clash

Detects clashing semitone overlaps and out-of-key notes in pitched parts so you can find weird, wrong, or leftover melodies and fix rubbing parts before review or after edits.

Instructions

Find melodic leftovers in the arrangement, from the notes (no render, ledger:M282): notes from DIFFERENT pitched parts sounding together a semitone apart (a minor 2nd, a minor 9th, or those plus octaves; a close major 7th of 11 semitones is a chord colour and not listed) for at least min_overlap beats, and notes out of the key. Reach for it when a melody sounds weird, wrong or left over, when two parts rub or clash, before an exam, and after removing or moving notes ("no weird melodies left over"). key: 'G minor', 'Am', 'D dorian' (default the project's or the sketch's key; with none, found from the notes, weighted by length and velocity, and named with its fit r). A minor key allows its raised 7th (the major V chord's third). min_overlap (beats, default 0.1): shorter overlaps are passing tones and not listed; raise it to keep only held rubs. tracks=[names]: read only these, each as pitched. bars=[a, b] (inclusive) cuts the range. n: the most audible findings shown per list (counts cover all). Pitched parts only: kit pads that play their note's pitch (a synth blip) are read, drums, fixed-pitch samples and synths (a cowbell), code voices named as drums or effects ('eh_drums', 'drums/kit70'), unmapped pads and muted tracks are skipped and named. Notes of one part never clash with each other (a voicing). Returns a header (parts read and skipped, the key and where it came from), the clashes per pair of parts with their bars, then the top n clashes and the top n out-of-key notes, most audible first. A finding is one place in the bar that repeats: bar and beat in the bar from 0 (as notes_read shows it) of its loudest time, the two parts and their notes with velocity, the overlap in beats, the interval, how many times and in which bars. Audible = the quieter note's level (velocity and fader, dB) times the square root of the overlap.

Input Schema

NameRequiredDescriptionDefault
nNo
keyNo
barsNo
tracksNo
projectYes
min_overlapNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.5/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 richly: it discloses that no render is needed, which parts are skipped and named (drums, fixed-pitch synths, code voices named as drums, muted tracks), that kit pads playing a pitch are read, that notes of one part never clash with each other, and how the key is inferred (weighted by length and velocity, with its fit r). This is exactly the behavioral context an agent needs and would not get from structured fields.

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?

It is front-loaded with the core purpose and each sentence carries real information, but the prose is extremely dense, with nested parentheticals, abbreviations ('ledger:M282', 'fit r'), and long run-on clauses that cost some parseability. Efficient in content, heavier than ideal in delivery.

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?

An output schema exists, so return values need not be spelled out, yet the description still gives the header/pair/top-n structure and defines 'audible' (quieter level times sqrt of overlap). Combined with its thorough coverage of a complex 6-parameter detection tool, an agent has everything needed to call it correctly.

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 coverage is 0%, so the description must compensate, and it does: key (format examples, default resolution strategy, raised-7th allowance), min_overlap (default 0.1, passing tones excluded, raise to keep held rubs), tracks (read as pitched), bars (inclusive range), and n (top-n per list with counts covering all). Only 'project' is left to inference, which is self-evident. The added meaning far exceeds the bare schema.

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 opening states a specific verb and resource ('Find melodic leftovers in the arrangement, from the notes (no render...)') and defines exactly what a clash is: different pitched parts a semitone apart (minor 2nd, minor 9th, plus octaves; excluding close major 7ths) or notes out of key. The function is unmistakable. It does not name or differentiate itself from plausible siblings like analyze_melody, melody_consensus, or analyze_chords, keeping it at 4 rather than 5.

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 explicit trigger conditions: 'when a melody sounds weird, wrong or left over, when two parts rub or clash, before an exam, and after removing or moving notes.' This is clear when-to-use guidance. It stops short of naming alternative tools or stating when not to use it, so 4 rather than 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