What can you do with this server?

The midi-composer-mcp server provides a rich set of deterministic music theory and composition tools for generating, analyzing, and rendering music — from individual notes and chords to full multi-track MIDI files. Scale & Chord Discovery * List and retrieve definitions for 40+ scale types (major, modal, jazz, symmetric, world/exotic) and 35+ chord types (triads through 13ths and altered chords) * Generate notes from a root with or without octave specifications (e.g., get_scale('dorian', 'E') → E F# G A B C# D E) Note & Chord Matching * Find scales or chords that contain given notes (octaves ignored), including inversions (e.g., E G C → C/E) and partial matches Diatonic Harmony * Get chords for each scale degree with Roman numerals and harmonic functions (tonic/subdominant/dominant) * Resolve degree sequences (e.g., I–V–vi–IV) into concrete chord symbols and notes in any key/scale Advanced Harmony & Melody * Analyze and reharmonize chord progressions with voice leading, secondary dominants, tritone substitutions, and negative harmony * Create melodies from scale degrees, arpeggios, motif grammars (ABAC forms with transpose/invert/retrograde), melodic walks, and sequences * Generate rule-following countermelodies (species 1–5) against a cantus firmus Rhythm Generation * Create reproducible (seeded) random rhythm patterns, Euclidean rhythms (Bjorklund algorithm), or named groove presets (backbeat, clave, bossa nova, etc.) Song Structure & Arrangement * Plan song sections (verse/chorus/bridge) on a timeline and assemble them into a full multi-track MIDI arrangement MIDI & Audio Rendering * Render note sequences, chord progressions (block or arpeggiated), and drum patterns to MIDI files * Quickly create a two-track MIDI file with melody and chord accompaniment via song_to_midi * Render MIDI to playable WAV audio using a built-in synth — no external soundfonts needed All tools are deterministic (except clearly marked seeded random functions) and composable, with outputs compatible across tools for chaining complex compositions.

Which integrations are available for this server?

Provides tools for music theory operations and MIDI file generation, enabling AI agents to compose music by chaining deterministic steps such as scale/chord lookup, rhythm generation, and rendering MIDI files.

How do I use midi-composer-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@midi-composer-mcp generate a i-VI-III-VII progression in A minor" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

midi-composer-mcp

by voho

Overview Schema Related Servers Score Discussions

Python

Local

The midi-composer-mcp server provides a rich set of deterministic music theory and composition tools for generating, analyzing, and rendering music — from individual notes and chords to full multi-track MIDI files.

Scale & Chord Discovery

List and retrieve definitions for 40+ scale types (major, modal, jazz, symmetric, world/exotic) and 35+ chord types (triads through 13ths and altered chords)
Generate notes from a root with or without octave specifications (e.g., get_scale('dorian', 'E') → E F# G A B C# D E)

Note & Chord Matching

Find scales or chords that contain given notes (octaves ignored), including inversions (e.g., E G C → C/E) and partial matches

Diatonic Harmony

Get chords for each scale degree with Roman numerals and harmonic functions (tonic/subdominant/dominant)
Resolve degree sequences (e.g., I–V–vi–IV) into concrete chord symbols and notes in any key/scale

Advanced Harmony & Melody

Analyze and reharmonize chord progressions with voice leading, secondary dominants, tritone substitutions, and negative harmony
Create melodies from scale degrees, arpeggios, motif grammars (ABAC forms with transpose/invert/retrograde), melodic walks, and sequences
Generate rule-following countermelodies (species 1–5) against a cantus firmus

Rhythm Generation

Create reproducible (seeded) random rhythm patterns, Euclidean rhythms (Bjorklund algorithm), or named groove presets (backbeat, clave, bossa nova, etc.)

Song Structure & Arrangement

Plan song sections (verse/chorus/bridge) on a timeline and assemble them into a full multi-track MIDI arrangement

MIDI & Audio Rendering

Render note sequences, chord progressions (block or arpeggiated), and drum patterns to MIDI files
Quickly create a two-track MIDI file with melody and chord accompaniment via song_to_midi
Render MIDI to playable WAV audio using a built-in synth — no external soundfonts needed

All tools are deterministic (except clearly marked seeded random functions) and composable, with outputs compatible across tools for chaining complex compositions.

midi-composer-mcp

An MCP server that gives an LLM a large palette of deterministic music-theory and composition tools, so a composer can state a goal and the LLM finds the best way to achieve it by linking the tools into a composition draft — from "give me the notes of this scale" to a full multi-track song you can actually play.

The guiding split: the tools contain the rules, the LLM contains the creativity. Every tool is a small, deterministic step — scales and chords, diatonic harmony, intervals, voice leading, reharmonization, the circle of fifths, motif grammars, sequences, tintinnabuli, species counterpoint, song structure, MIDI and audio rendering. A tool never decides what is "good"; it mechanically applies a rule. The LLM decides which rules to invoke and how to combine them, so the music follows real theory and is not random.

Two more invariants: all tools are compatible (the note/chord/degree/rhythm output of one is valid input to another), and randomness is contained in a few clearly-named, seeded tools (random_notes, random_rhythm) — everything else is deterministic. See CLAUDE.md for the full design principles.

Note format

Notes are strings: C, F#, Bb, Ebb (case-insensitive, unicode ♯/♭ accepted).
A note without an octave is an abstract pitch class.
A note with an octave is a concrete pitch: C4 is middle C (MIDI 60), Eb3, A5... Generation respects it: get_scale("major", "C5") → C5 D5 E5 F5 G5 A5 B5 C6 with MIDI numbers; get_chord("9", "C4") → C4 E4 G4 Bb4 D5.
Matching ignores octaves: match_chords(["E3","G4","C5"]) → C/E (first inversion), exactly as ["E","G","C"] would.
Note lists may be JSON arrays (["C", "E", "G"]) or plain strings ("c e g", "C, E, G").
Spelling is proper: F major has a Bb (not A#), Cdim7 has a Bbb.

Related MCP server: CHUK Music MCP Server

Tools

The toolset is organized by layer — scales, chords, harmony rules, melody, rhythm, song structure, and rendering — so the LLM can go from an idea to a finished multi-track song. Everything is deterministic (seeded where random).

Scales & chords

Tool	What it does
`list_scales` / `get_scale`	40+ scale types (common, modal, jazz, symmetric, world/exotic), each with a description; generate notes from a root. `maj + C → C D E F G A B C`.
`list_chords` / `get_chord`	35+ chord types (triads → 13ths and altered), each with a description; generate notes. `min + F → F Ab C`.
`match_scales` / `match_chords`	Find scales/chords containing given notes (octaves ignored); inversions detected (`e g c → C/E`), partials list missing notes.
`diatonic_chords`	The chord on each scale degree, with roman numerals, degree names and harmonic functions.
`degrees_to_chords`	Resolve a chosen degree sequence (`[1,5,6,4]`, `"I V vi IV"`) into concrete chords.

Harmony rules

Tool	What it does
`circle_of_fifths`	Key signatures, relative/parallel minors, and closely related keys (for modulations and bridges).
`interval_between`	Name the interval between two notes (`C→Eb = m3`, `C→F# = A4` vs `C→Gb = d5`).
`analyze_progression`	The inverse of `degrees_to_chords`: chords → roman numerals + functions, chromatic chords flagged.
`voice_leading`	Voice a progression smoothly (nearest inversion, common tones held) — natural pads instead of parallel blocks.
`secondary_dominant` / `tritone_substitute`	Classic reharmonizations (`V/ii of Dm → A7`; `G7 → Db7`).
`negative_harmony`	Reflect notes through a key's negative-harmony axis (major ↔ minor shadow).
`harmonize_melody`	Put a chord under each melody note — searching the whole chord database — that reuses as many notes from the previous chord as possible, then voice-leads it. Returns ranked options + a `render_hint`.

Melody

Tool	What it does
`notes_from_degrees`	Write a melody as scale degrees → notes; transposable to any key/scale. `[1,2,3,5,8]` in C → `C D E G C`.
`motif_grammar`	Build a phrase from a form like `ABAC` over labeled motifs; a variant can `transpose`/`invert`/`retrograde`/`rotate` another. Works on notes, degrees, or rhythm.
`melodic_walk`	A singable line by a seeded random walk over a scale ladder (mostly stepwise).
`melodic_sequence`	Repeat a motif as a diatonic sequence (e.g. down a step each time).
`arpeggiate`	Reorder a chord/scale into an arpeggio (up/down/updown/converge/…, multi-octave).
`tintinnabuli_voice`	Arvo Pärt's tintinnabuli: shadow a melody with the nearest notes of a fixed triad (T1/T2, above/below/alternating).
`counterpoint`	Species counterpoint (1–5): a rule-following counter-melody to a cantus firmus — note-against-note through florid, with passing tones and resolving suspensions, no parallel fifths/octaves. Returns a `render_hint` of ready tracks.
`snap_to_scale`	Snap any line to the nearest scale notes — guarantees a melody fits the key/chords.
`transpose_notes`	Transpose a note list by semitones.
`random_notes`	🎲 Uniform random picks from any note pool (seeded).

Rhythm

Tool	What it does
`random_rhythm`	🎲 Random pattern `O...Oo..` — `O` strong, `o` weak, `.` rest (seeded).
`euclidean_rhythm`	Evenly-spread Bjorklund rhythm; `euclidean_rhythm(3,8) → O..o..o.` (tresillo).
`groove` / `list_grooves`	Named presets: four-on-the-floor, backbeat, tresillo, son/rumba clave, bossa nova, dembow…

Song structure & rendering

Tool	What it does
`plan_sections`	Lay out a form (`"intro verse chorus … outro"` / `"AABA"`) on the timeline — start bars, beats, seconds.
`arrange_song`	The capstone: assemble named sections (intro/verse/chorus/bridge/outro) into one whole-song MIDI; like-named tracks stitch into continuous parts.
`notes_to_midi` / `chords_to_midi` / `drums_to_midi`	Render a single track (melody/scale, chords block-or-arpeggiated, GM drum lanes).
`arrange_to_midi`	Render any number of fitting tracks (chords, bass, melody, drums) into one multi-track `.mid`.
`song_to_midi`	Melody + chords as a two-track file (shortcut for the common case).
`midi_to_audio`	Render any generated `.mid` into a playable WAV with a built-in synth (no soundfont needed).

MIDI/audio tools write to ./midi_output (override per call with output_dir or globally with MIDI_COMPOSER_OUTPUT_DIR) and also return the file base64-encoded.

Examples

Each example is a sequence of tool calls. The composer states a goal; the LLM chains tools to reach it. Outputs feed the next call — that's the whole idea.

Simple

"Give me the notes of E Dorian."

get_scale("dorian", "E")            → E F# G A B C# D E

"What chord do the notes C, E, G make? And what scales fit them?"

match_chords(["C", "E", "G"])       → C (exact);  "E G C" → C/E (first inversion)
match_scales(["C", "E", "G"])       → C major pentatonic, C major, A minor, …

(Octaves are ignored, so ["C5","E5","G5"] gives the same answer.)

"A ii–V–I in F, with sevenths."

degrees_to_chords("F", "major", "ii V I", sevenths=True)   → Gm7  C7  Fmaj7

"A random melody from A minor pentatonic, then save it as MIDI."

get_scale("minor pentatonic", "A5")            → A5 C6 D6 E6 G6 A6   (octave-aware)
random_notes(<those notes>, count=8, seed=1)   → a reproducible 8-note line  [contained randomness]
notes_to_midi(<the notes>, tempo=120)          → a .mid file (+ base64)
midi_to_audio(<that file>)                     → a playable .wav

Intermediate

"Build a pop loop: I–V–vi–IV in C with a bass, a hook, and a backbeat."

voice_leading(["C","G","Am","F"])                          → smooth pad voicings
notes_from_degrees("C5","major",[5,5,6,5,3,2,1,1])         → a diatonic hook
groove("backbeat"); groove("four_on_floor")               → drum patterns
arrange_to_midi([                                          → one 4-track .mid
  {"type":"chords","name":"pad","chords":<voicings>,"beats_per_chord":4},
  {"type":"notes","name":"bass","notes":["C","G","A","F"],"step_beats":4,"octave":2,"program":33},
  {"type":"notes","name":"lead","notes":<hook>,"octave":5,"program":80},
  {"type":"drums","name":"drums","step_beats":0.25,"lanes":{"kick":"O...O...O...O...","snare":"....O.......O...","hat":"o.o.o.o.o.o.o.o."}},
])

"Reharmonize G7→C and analyze it."

tritone_substitute("G7")                  → Db7   (chromatic bass G→Db→C)
secondary_dominant("Dm")                  → A7    (V7 of ii)
analyze_progression(["C","A7","Dm","G7","C"], "C", "major")
                                          → I, V7/ii (chromatic), ii, V7, I

"Where can I modulate from C major?"

circle_of_fifths("C")    → dominant G, subdominant F, relative A minor,
                           closely related: A minor, G major, E minor, F major, D minor

"Put chords under this melody, reusing as many notes as possible between chords."

harmonize_melody(["C5","E5","F5","A5","G5"], root="C", scale_type="major", in_scale=True)
   → searches the whole chord DB for chords containing each note, ranks them by shared
     notes with the previous chord, picks the smoothest, and voice-leads:
     C → C → Cadd4 → Am7 → C6 …   (each chord keeps 3 notes from the last)
   → plus ranked `options` per note and a render_hint (harmony + melody) for arrange_to_midi

Advanced

"Write a third-species counterpoint to a cantus firmus."

counterpoint(["C5","D5","E5","F5","E5","D5","C5"], "C", "major", species=3)
   → cantus + a 4:1 counter-line (passing tones, perfect-consonance cadence, no parallel 5ths/8ves)
   → plus render_hint.tracks  →  arrange_to_midi(<render_hint tracks>)  →  midi_to_audio(…)

"Develop a melody by motif grammar (ABAC), kept in key."

motif_grammar("ABAC", {                                    # kind="degrees" stays diatonic
  "A":[1,2,3,5], "B":{"vary":"A","transpose":1}, "C":{"vary":"A","retrograde":true}}, kind="degrees")
notes_from_degrees("C5","major", <those degrees>)          → the realized, in-key phrase

"Compose with tintinnabuli rules over a few maj7 chords, with two verses and a chorus."

# Verse M-voice (A minor) + its tintinnabuli T-voice, over voice-led maj7/m7 pads:
m = notes_from_degrees("A4","natural minor",
       motif_grammar("ABAC", {"A":[1,2,3,2],"B":{"vary":"A","transpose":1},"C":[3,2,1,1]}, kind="degrees")["degrees"])
t = tintinnabuli_voice(m, "Am", position="inferior", rank=1)          # nearest A-minor triad note below each M note
verse_pads  = voice_leading(["Am7","Dm7","Fmaj7","Cmaj7"])["chords"]
chorus_pads = voice_leading(["Fmaj7","Cmaj7","Dm7","Em7"])["chords"]

arrange_song({                                                        # sequence sections into a song
  "verse":  {"bars":4, "tracks":[
     {"type":"chords","name":"pads","chords":verse_pads,"beats_per_chord":4,"program":89},
     {"type":"notes","name":"M-voice","notes":m,"step_beats":2,"octave":5,"program":48,"sustain":true},
     {"type":"notes","name":"T-voice","notes":t,"step_beats":2,"octave":4,"program":9,"sustain":true}]},
  "chorus": {"bars":4, "tracks":[
     {"type":"chords","name":"pads","chords":chorus_pads,"beats_per_chord":4,"program":89},
     {"type":"notes","name":"M-voice","notes":notes_from_degrees("C5","major",[5,6,8,6,5,3,2,1])["notes"],"step_beats":2,"octave":5,"program":48,"sustain":true},
     {"type":"notes","name":"bass","notes":["F","C","D","E"],"step_beats":4,"octave":2,"program":33}]},
}, form="verse verse chorus", tempo=72)   →   midi_to_audio(<the song>)

These advanced examples (a Pärt tintinnabuli study, a species-3 counterpoint, the tintinnabuli verse/chorus song, and a full verse/chorus/bridge song) are runnable in examples/generate_examples.py:

python examples/generate_examples.py            # writes .mid + .wav for each

Demo gallery

The demos/ folder is a gallery of finished pieces, each paired with the plain-language prompt it answers — from a Pärt-style tintinnabuli study to a modulating pop anthem, a jazz reharmonization, all five counterpoint species, a flamenco piece in Phrygian dominant, and a negative-harmony before/after. The .mid files are committed (open them in a DAW); regenerate everything with:

python demos/generate.py                        # rewrites demos/*.mid and *.wav

Playable output

A bare .mid is a valid Standard MIDI File (Format 1, tempo map, General MIDI programs, drums on channel 10) that plays in any DAW or synth — but it needs a soundfont to be heard. midi_to_audio solves that: it synthesizes the MIDI into a 16-bit PCM WAV using only the Python standard library (additive tones for pitched parts, percussive synthesis for drums), so every result is playable anywhere — no soundfont, no external synth. It's a faithful preview, not a production mix.

A composing session looks like this

The LLM drives; each tool call is one mechanical step:

get_scale("harmonic minor", "C") → C D Eb F G Ab B (+ a description of the scale's character)
diatonic_chords("C", "harmonic minor", sevenths=true) → the 7th chord on each degree, with roman numerals and functions
LLM decides on i–iv–V–i → degrees_to_chords("C", "harmonic minor", "i iv V i", sevenths=true) → CmMaj7 Fm7 G7 CmMaj7
euclidean_rhythm(5, 16) → O..o..o..o..o... for a bass groove
random_notes / hand-written melody from the scale notes
arrange_to_midi([...pad, bass, lead, drums...]) → a four-track .mid
midi_to_audio(file) → a .wav you can play immediately

Every intermediate result is plain data the LLM can inspect, edit by hand (tweak a rhythm string, swap a chord), or feed into another tool.

Arrangement track shapes (for `arrange_to_midi`)

[
  {"type":"chords","name":"pad",   "chords":["Am","F","C","G"], "beats_per_chord":4, "octave":4, "program":89},
  {"type":"notes", "name":"bass",  "notes":["A","F","C","G"],   "rhythm":"O..o..o..o..o...", "octave":2, "program":33, "step_beats":0.25},
  {"type":"notes", "name":"lead",  "notes":["A4","C5","E5","D5"], "octave":5, "program":0},
  {"type":"drums", "name":"drums", "lanes":{"kick":"O...O...","snare":"..O...O.","hat":"oooooooo"}}
]

Shared per-track options: name, velocity, start_beat (beat offset for intros/drops), step_beats, channel (auto-assigned; drums forced to the GM percussion channel).

Installation

Requires Python ≥ 3.10.

# with uv (recommended)
uv pip install .          # or: uv sync && uv run midi-composer-mcp

# or with pip
pip install .

Run the server (stdio transport):

midi-composer-mcp
# or without installing:
uv run --with mcp --with mido python -m midi_composer_mcp.server

Claude Code

claude mcp add midi-composer -- uv run --directory /path/to/midi-composer-mcp midi-composer-mcp

Claude Desktop

{
  "mcpServers": {
    "midi-composer": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/midi-composer-mcp", "midi-composer-mcp"],
      "env": { "MIDI_COMPOSER_OUTPUT_DIR": "/path/to/your/midi/files" }
    }
  }
}

Development

uv venv && uv pip install -e ".[dev]"
.venv/bin/python -m pytest

Layout:

src/midi_composer_mcp/
  notes.py        # note parsing, proper spelling, octaves, MIDI numbers
  scales.py       # scale database (40+, described), generation, matching
  chords.py       # chord database (35+, described), symbols, generation, matching
  diatonic.py     # chords per scale degree, degree-sequence resolution
  circle.py       # circle of fifths: key signatures and related keys
  harmony.py      # intervals, roman-numeral analysis, voice leading, reharmonization
  melody.py       # degrees, arpeggios, walks, motif grammar, sequence, snap, tintinnabuli
  counterpoint.py # first-species counterpoint (deterministic, rule-following)
  generate.py     # seeded dice + euclidean rhythm + groove presets
  structure.py    # song structure: plan sections, assemble a whole song
  midi_io.py      # deterministic MIDI rendering: notes, chords, drums, multi-track (mido)
  audio.py        # MIDI -> playable WAV preview, pure standard library
  server.py       # the MCP server (FastMCP) — thin wrappers over the above

Roadmap ideas

Rhythmic chord comping (a rhythm on chord tracks, for stabs/funk/reggae)
Swing/shuffle and humanize (timing/velocity jitter as a seeded, mechanical step)
Higher-species counterpoint
Reading MIDI files back into note/chord data

Available Tools

13 tools

chords_to_midiA

Write a chord sequence to a MIDI file (block chords, or arpeggiated).

chords items are chord symbols ('C', 'Am7', 'F#dim', 'C/E', 'C4maj7' — e.g. the symbols output of degrees_to_chords) and/or explicit note arrays (['C','E','G'] or ['C4','E4','G4']). Octave-less chords are voiced upward from octave. Each chord lasts beats_per_chord. Returns the file path and base64 plus each chord's voiced notes and MIDI numbers.

ParametersJSON Schema

Name	Required	Description	Default
`chords`	Yes
`beats_per_chord`	No
`tempo`	No
`octave`	No
`arpeggiate`	No
`velocity`	No
`program`	No
`file_name`	No
`output_dir`	No

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description covers behavior without annotations: chord input format, octave voicing, beats per chord, tempo, arpeggiation, velocity, program, file naming, and return values. Minor gaps like file overwrite behavior or error handling.

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?

Three concise sentences, front-loaded with main action. Could be more structured (e.g., listing parameters), but no wasted words.

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?

Given 9 parameters and no output schema, description explains input types, defaults, behavior, and return info. Missing details like file overwrite policy or edge cases, but sufficient for typical use.

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

Parameters4/5

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

Schema coverage is 0%, but description adds meaning for most parameters (beats_per_chord, tempo, octave, arpeggiate, velocity, program, file_name, output_dir). Not all parameters fully explained, but adds substantial value beyond raw 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 description clearly states the tool writes chord sequences to MIDI files, with block or arpeggiated modes. It distinguishes from siblings like notes_to_midi and degrees_to_chords by specifying chord-level input, but lacks explicit sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives (e.g., notes_to_midi, song_to_midi). No prerequisites, context, or conditionals provided.

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

degrees_to_chordsA

Resolve a chord-degree sequence you chose into concrete chords of a scale.

degrees is your sequence as numbers or roman numerals: [1, 5, 6, 4], 'I V vi IV' or '1-5-6-4'. Returns the chord (symbol + notes) on each chosen degree, in order — e.g. in C major: C, G, Am, F. The symbols array feeds directly into chords_to_midi / song_to_midi. This tool only maps degrees to chords; choosing and ordering the degrees is up to you.

ParametersJSON Schema

Name	Required	Description	Default
`root`	Yes
`scale_type`	Yes
`degrees`	Yes
`sevenths`	No

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It explains input parameters and output format (chord symbol + notes). Lacks details on idempotency, error handling, or authorization, but covers basic behavior.

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?

Two paragraphs with essential information. First sentence states purpose, then lists formats, output, and limitation. No fluff, but could be slightly more streamlined.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers mapping logic and output format adequately for a simple tool. Missing details on valid root/scale_type values and error cases, but given no output schema, it provides necessary context.

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

Parameters2/5

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

Schema coverage is 0%. The description explains 'degrees' format in detail but does not elaborate on 'root' and 'scale_type' valid values (e.g., note names, major/minor). 'Sevenths' is briefly described.

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 clearly states the tool resolves chord-degree sequences into concrete chords, with examples and output format. It distinguishes from siblings like 'diatonic_chords' and 'get_chord' by focusing on mapping a sequence.

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?

The description says 'This tool only maps degrees to chords; choosing and ordering the degrees is up to you,' implying when to use it. It doesn't explicitly exclude alternatives but provides clear context.

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

diatonic_chordsA

List the chord built on each degree of a scale (triads, or sevenths).

E.g. diatonic_chords('C', 'major') -> I=C, ii=Dm, iii=Em, IV=F, V=G, vi=Am, vii°=Bdim. Seven-note scales also get roman numerals, degree names and harmonic functions (tonic/subdominant/dominant) — the raw material for designing a progression yourself; then resolve it with degrees_to_chords. A root with an octave (e.g. 'C4') yields concrete pitches with MIDI numbers.

ParametersJSON Schema

Name	Required	Description	Default
`root`	Yes
`scale_type`	Yes
`sevenths`	No

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses output format (roman numerals, degree names, harmonic functions) and special behavior for octave roots (MIDI numbers). However, it does not specify valid scale_type values, error handling, or limitations (e.g., only seven-note scales get full output).

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 purpose and includes a clear example. The second paragraph adds useful context but is slightly verbose. Overall, it is efficient for the complexity of the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and moderate complexity, the description covers return values and a workflow. However, it lacks details on edge cases, valid inputs, and errors, which an agent would need for reliable invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so description must compensate. It only hints at 'root' and 'scale_type' via example, and 'sevenths' is mentioned but not explicitly described. No valid values or constraints for parameters are provided, leaving ambiguity for an AI agent.

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 clearly states the tool lists chords built on each degree of a scale, with explicit example and mention of return values (roman numerals, degree names, harmonic functions). It distinguishes from sibling degrees_to_chords by describing a workflow.

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?

The description implies a usage pattern: use this tool to get diatonic chords as raw material, then resolve with degrees_to_chords. It does not explicitly state when to avoid this tool, but the example and workflow guidance are sufficient for an AI agent to infer its primary use.

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

get_chordA

Describe a chord type; with a root note, generate its notes.

Without root: intervals and degrees only (e.g. minor 7 = 0 3 7 10). With root: the spelled chord, e.g. get_chord('min', 'F') -> F Ab C. Give the root an octave for concrete pitches: get_chord('9', 'C4') -> C4 E4 G4 Bb4 D5 plus MIDI numbers. The returned notes array feeds directly into random_notes, notes_to_midi, match_scales, etc.

ParametersJSON Schema

Name	Required	Description	Default
`chord_type`	Yes
`root`	No

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description fully explains behavior: intervals only without root, spelled notes with root, and MIDI numbers with octave. No contradictions or gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four concise sentences, front-loaded with purpose, no redundant information.

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?

Despite no output schema, the description explains return values (intervals, notes, MIDI) and notes interoperability with sibling tools, making it complete.

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

Parameters4/5

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

With 0% schema description coverage, the description explains both parameters well, including the effect of root. Lacks explicit enumeration of chord types but provides illustrative examples.

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 the tool's function with specific verbs ('describe', 'generate') and clearly distinguishes from siblings like get_scale and list_chords by focusing on chord types and note generation.

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?

Explanation of two modes (with/without root) and mention of output feeding into other tools provides good usage context, but does not explicitly exclude alternative tools.

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

get_scaleA

Describe a scale type; with a root note, generate its notes.

Without root: intervals and degree labels only (e.g. major = 0 2 4 5 7 9 11). With root: the spelled notes, e.g. get_scale('major', 'C') -> C D E F G A B C. Give the root an octave for concrete pitches: get_scale('major', 'C5') -> C5 ... C6 plus MIDI numbers. The returned notes array feeds directly into match_chords, random_notes, notes_to_midi, etc.

ParametersJSON Schema

Name	Required	Description	Default
`scale_type`	Yes
`root`	No

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full burden. It discloses the behavior for each input combination (no root, root, root with octave), the return format, and that the output feeds into other tools. No side effects mentioned, which is appropriate. Lacks details on error handling or limits, but overall transparent for a read-only computation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: one sentence for overall purpose, then clear bullet-like explanations for each mode, and a final note on output usage. Every sentence adds value and the structure is front-loaded.

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 no output schema, the description fully explains return values for all input variants. It also mentions how the output integrates with other tools, which is helpful context. No missing information for this tool's complexity.

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 description must add meaning. It explains that scale_type is a scale name (e.g., major), root is optional and affects output: without root returns intervals, with root returns notes, and with octave returns pitches with MIDI numbers. This fully clarifies parameter behavior beyond the schema.

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 clearly states the tool's purpose: 'Describe a scale type; with a root note, generate its notes.' It distinguishes two modes (without root gives intervals, with root gives notes, with octave gives concrete pitches), which differentiates it from sibling tools like list_scales or match_scales.

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?

The description provides guidance on when to use each mode: without root for intervals, with root for notes, with octave for concrete pitches. It also mentions integration with other tools. However, it does not explicitly exclude use cases or compare to alternatives like get_chord, but for a scale-focused tool this is sufficient.

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

list_chordsA

List every chord type in the database with intervals, degree labels, symbol suffixes and aliases.

Use a chord type's name or symbol suffix with get_chord, and root+suffix symbols (e.g. 'Am', 'G7', 'F#m7b5') anywhere a chord symbol is accepted.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It describes the return content but does not disclose whether the operation is read-only, how it handles large datasets, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two precise sentences: first states the tool's purpose, second gives usage context. No filler; every sentence earns its place.

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?

With zero parameters and no output schema, the description adequately explains the tool's function and how it relates to sibling tools, though it could mention if the list is complete or paginated.

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

Parameters4/5

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

There are no parameters, so the description inherently adds value by explaining what the tool returns and how to use the output, which is sufficient beyond the schema.

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 explicitly states it lists every chord type with intervals, degree labels, symbol suffixes, and aliases, distinguishing itself from sibling tools like 'get_chord' which retrieves a specific chord.

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?

The description provides guidance on when to use this tool (to list chord types) and how to use the results with 'get_chord' and chord symbols, though it lacks explicit exclusion of alternatives.

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

list_scalesA

List every scale type in the database with intervals, degree labels and aliases.

Use a scale type's name (or any alias) with get_scale, match_scales, diatonic_chords and degrees_to_chords.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It describes the output (list of scales with attributes) but does not mention any side effects, rate limits, or potential performance considerations. For a simple read-only listing, this is adequate but could be improved.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first defines the action and output, second provides usage context. No unnecessary words or repetition.

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?

Given zero parameters and no output schema, the description provides sufficient context: what the list contains and how to use the results with sibling tools. It could mention ordering or limits, but overall it is complete for the tool's simplicity.

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

Parameters4/5

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

The tool has zero parameters, so baseline is 4. The description adds no parameter-specific information beyond the schema (which is already 100% covered).

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 clearly states the tool lists every scale type with intervals, degree labels, and aliases. It distinguishes from siblings like get_scale (single) and match_scales (search) by indicating a full listing.

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?

The description explicitly tells how to use the output (scale names or aliases) with specific tools like get_scale, match_scales, etc. While it doesn't explicitly state when to use this tool over siblings, the guidance is clear and helpful.

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

match_chordsA

Find chords that match the given notes (octaves are ignored).

'exact' matches use exactly the input pitch classes; when the first input note is not the chord root the inversion is reported with slash notation (e.g. 'E G C' -> C/E, first inversion). 'partial' matches are chords that contain all input notes plus the listed missing_notes.

ParametersJSON Schema

Name	Required	Description	Default
`notes`	Yes
`include_partial`	No
`limit`	No

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that octaves are ignored, inversion notation is used, and partial matches include missing_notes. But it does not describe return format, performance, or potential edge cases.

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 well-structured with a clear first sentence stating the purpose, followed by explanations of the two modes. It is not overly verbose, though could be slightly tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and low parameter coverage, the description should be more complete. It lacks details on the note input format and the return value structure (what exact information is returned for each chord). The 'limit' parameter is unmentioned.

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

Parameters2/5

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

Schema coverage is 0%, so description must compensate. It explains the meaning of 'include_partial' through the mode descriptions, but does not specify the note format (e.g., 'C', 'C#') nor explain the 'limit' parameter at all. This is insufficient for a tool with 3 parameters.

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 clearly states the tool finds chords matching given notes, with exact and partial modes explained. It distinguishes from siblings like get_chord (gets a specific chord by name) and list_chords (lists all chords) by focusing on matching input notes.

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?

The description provides clear guidance on when to use exact vs partial matches, explaining behavior for inversions and missing notes. However, it does not explicitly compare to alternatives like match_scales or other sibling tools.

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

match_scalesA

Find scales that contain all of the given notes (octaves are ignored).

notes is a list like ['C', 'E', 'G'] or a string 'c e g' — any other tool's notes output works as-is. A match is 'exact' when the input uses every note of the scale; otherwise 'contains', with the scale's extra notes listed in added_notes. Exact and tighter (smaller) scales sort first.

ParametersJSON Schema

Name	Required	Description	Default
`notes`	Yes
`exact_only`	No
`limit`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description discloses key behaviors: octave ignorance, input flexibility, match types, sorting. This provides good transparency beyond the bare minimum.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is exceptionally concise with two sentences plus a brief explanatory block. Every sentence is meaningful, and key information is front-loaded.

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?

Given the tool's complexity (3 params, no output schema, no annotations), the description covers purpose, input, matching, and sorting. It could mention return format but is still quite complete.

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?

Schema coverage is 0%, so description must compensate. It explains the 'notes' parameter format well, but 'exact_only' and 'limit' are not explicitly described, though implied by the behavioral context.

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 clearly states the tool finds scales that contain given notes, with specific verb 'find' and resource 'scales'. It distinguishes from siblings like 'match_chords' by focusing on scales.

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?

The description explains when to use this tool: to find scales containing given notes. It details matching behavior (exact vs contains) and sorting, but lacks explicit alternatives or when-not-to-use guidance.

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

notes_to_midiA

Write a note sequence (scale, arpeggio or melody) to a MIDI file.

Plays the notes in order, one per step_beats. With rhythm (a pattern like 'O.oo.O..' from random_rhythm or hand-written), each step follows the pattern: O = accented note, o = soft note, . = pause (notes are consumed in order and wrap around if the pattern needs more; with sustain=true pauses extend the previous note instead). Octave-less notes are placed by octave_policy: 'nearest' for melodies, 'ascending' for scale runs. Returns the file path and base64 plus the exact note events written.

ParametersJSON Schema

Name	Required	Default
`notes`	Yes
`rhythm`	No
`step_beats`	No
`tempo`	No
`octave`	No
`octave_policy`	No	nearest
`velocity`	No
`accent_velocity`	No
`sustain`	No
`program`	No
`file_name`	No
`output_dir`	No

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 delivers thorough behavioral details: note playback order, rhythm pattern (O, o, .), sustain behavior, octave_policy, and return of file path, base64, and event list. No contradictions.

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 moderately sized and front-loaded with the main action. It includes necessary details on rhythm and octave policy without excessive verbosity, though it could be slightly more compact.

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?

With 12 parameters, no output schema, and no annotations, the description provides a solid overview of behavior, key parameters, and return values. It covers the core functionality well but could elaborate on less common parameters or edge cases.

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

Parameters4/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. It explains the key parameters (rhythm, step_beats, octave_policy, velocity, sustain) in context. However, it does not clarify the format of the notes parameter (string vs array) or some defaults like tempo, octave, program, file_name, output_dir.

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 clearly states the tool's purpose: 'Write a note sequence (scale, arpeggio or melody) to a MIDI file.' This is a specific verb+resource combination that distinguishes it from siblings like chords_to_midi and song_to_midi.

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?

The description explains how to use the tool (e.g., playing notes per step_beats, rhythm pattern interpretation, octave_policy suggestions) and what output to expect. It does not explicitly state when to avoid using it, but given the sibling tools, the context is clear.

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

random_notesA

Pick count uniformly random notes from a pool of notes (a pure dice roll).

The pool is any notes array — typically from get_scale or get_chord, e.g. random notes from A minor pentatonic. Octaves in the pool are kept. Reproducible via seed; the seed used is always returned.

ParametersJSON Schema

Name	Required	Description	Default
`notes`	Yes
`count`	No
`allow_repeats`	No
`seed`	No

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description details that the selection is a 'pure dice roll', octaves are preserved, and the operation is reproducible via a seed which is always returned. This goes beyond mere operation to provide behavioral insight, compensating for the absence of annotations.

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 short (three sentences) and front-loads the main purpose. It uses clear language but could be slightly more structured with explicit parameter descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should explain the return value. It only mentions that the seed is returned, but not the format of the random notes themselves. This omission leaves the agent uncertain about the output structure, reducing completeness.

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?

The description explains 'count' and 'seed' parameters (count controls number of picks, seed for reproducibility). However, 'notes' and 'allow_repeats' are not described; the schema has 0% coverage, so the description should have covered all parameters. It adds partial value but is incomplete.

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 clearly states the tool picks uniformly random notes from a pool, with an example referencing get_scale/get_chord. This distinguishes it from sibling tools like get_chord or get_scale, which produce deterministic outputs.

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?

The description indicates the typical source of the pool (get_scale/get_chord) and that this is a random selection. It provides context for when to use this tool but does not explicitly mention when not to use it or suggest alternatives.

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

random_rhythmA

Roll a random rhythm pattern of length steps (a pure dice roll).

Returns a pattern string like 'O...Oo..' where O = strong beat, o = weak beat, . = pause. density is the chance a step holds a note; accent_probability the chance a note is strong. The pattern feeds the rhythm argument of notes_to_midi / song_to_midi; you can also edit it by hand first. Reproducible via seed; the seed used is always returned.

ParametersJSON Schema

Name	Required	Description	Default
`length`	No
`density`	No
`accent_probability`	No
`seed`	No

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the random dice roll behavior, output format, and seed reproducibility. No annotations exist, so description carries burden; however, it lacks details on randomness quality or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise, front-loaded with the core purpose, and each sentence adds value. No unnecessary words.

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 simple random generator tool with no output schema, the description fully explains the return format, how to use results, and all parameters. Completeness is high given the tool's complexity.

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?

With 0% schema coverage, the description explains all four parameters (length, density, accent_probability, seed) in clear terms, adding meaning beyond the schema types 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?

Clearly states it generates a random rhythm pattern of a given length. Distinguishes from siblings by mentioning its output feeds into notes_to_midi/song_to_midi, but does not explicitly differentiate from random_notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance on when to use the tool (generating rhythm for notes_to_midi or song_to_midi) and suggests editing by hand. Does not explicitly state when not to use alternatives.

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

song_to_midiA

Write a melody plus chord accompaniment into one two-track MIDI file.

Track 1 plays melody_notes (optionally shaped by melody_rhythm, same rules as notes_to_midi); track 2 plays chords (same formats as chords_to_midi), one every beats_per_chord. You decide which melody notes go over which chords — align them by length: a melody over 4 chords of 4 beats with 0.5-beat steps needs a 32-step rhythm/notes. General MIDI *_program numbers pick instruments (0 piano, 32 bass, 48 strings...).

ParametersJSON Schema

Name	Required	Default
`melody_notes`	Yes
`chords`	Yes
`melody_rhythm`	No
`step_beats`	No
`beats_per_chord`	No
`tempo`	No
`melody_octave`	No
`chord_octave`	No
`octave_policy`	No	nearest
`melody_velocity`	No
`accent_velocity`	No
`chord_velocity`	No
`sustain`	No
`arpeggiate_chords`	No
`melody_program`	No
`chord_program`	No
`file_name`	No
`output_dir`	No

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explains the two-track structure, alignment logic, and instrument selection, but does not disclose output behavior (e.g., whether it saves to file or returns MIDI data), side effects, or permissions. With no annotations, more transparency is needed.

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 a single, well-structured paragraph that front-loads the main purpose. The alignment example adds clarity but could be seen as slightly verbose; overall it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 18 parameters, no schema descriptions, and no output schema, a complete description should cover most parameters and return behavior. This description only covers a fraction of the parameters and omits output details, making it insufficient for a complex tool.

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

Parameters2/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. It explains melody_notes, melody_rhythm, chords, beats_per_chord, and program numbers, but leaves 13 out of 18 parameters (e.g., step_beats, tempo, octaves, velocities, sustain, file_name) completely unexplained.

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 clearly states it writes a melody plus chord accompaniment into a two-track MIDI file, and distinguishes from sibling tools by mentioning 'same rules as notes_to_midi' and 'same formats as chords_to_midi', indicating it combines both functionalities.

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?

The description provides a clear context for use, including alignment guidance with an example ('a melody over 4 chords of 4 beats with 0.5-beat steps needs a 32-step rhythm/notes'). However, it does not explicitly state when to use this tool versus alternatives like using notes_to_midi and chords_to_midi separately.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

13 tool updatesv0.1.0Jun 12, 2026
- First observedchords_to_midi
- First observeddegrees_to_chords
- First observeddiatonic_chords
- First observedget_chord
- First observedget_scale
- First observedlist_chords
- First observedlist_scales
- First observedmatch_chords
- First observedmatch_scales
- First observednotes_to_midi
- First observedrandom_notes
- First observedrandom_rhythm
- First observedsong_to_midi

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: chord/scale retrieval, matching, progression building, and MIDI writing. No two tools overlap in functionality.

Naming Consistency5/5

All tool names follow either a verb_noun pattern (get_chord, list_scales) or a noun_to_noun pattern (chords_to_midi), with consistent snake_case throughout.

Tool Count5/5

13 tools cover a broad range of music composition tasks without being overwhelming. Each tool serves a specific need, fitting well within the optimal 3-15 range.

Completeness5/5

The set covers music theory retrieval (scales, chords), progression building, random generation, and MIDI output (notes, chords, combined tracks). No obvious gaps for its stated purpose.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

THIRI Chord Intelligence A
ai.thiri
Deterministic music theory for agents: analyze, voice, reharmonize, conduct — computed, not guessed
Entertainment & Media Audio Processing AI & Machine Learning
526
Zachary Roth Music A
com.zacharyr0th.music
Anonymous public tools for Zachary Roth Music. See the published agent boundary before use.
Entertainment & Media Audio Processing
101
melody-genieOAuth
app.melodygenie
Write lyrics in 100+ styles, score them, generate full songs with 4 engines, split stems. OAuth.
1
FreqBlog Music Metadata A
com.freqblog
Audio features + harmonic set-building for tracks by name/ISRC. Spotify audio-features replacement.
Entertainment & Media Audio Processing
122

Related MCP Servers

Vibe Composer MIDI MCP
Audio Processing Multimedia Processing Entertainment & Media
mikeborozdin
A
license
C
quality
D
maintenance
Enables LLMs to compose and play multi-track MIDI music through natural language prompts. Supports outputting to software or hardware synthesizers for enhanced audio quality.
Updated 8 months ago (2025-12-30 22:53 UTC)
2
24
24
MIT
CHUK Music MCP Server
Multimedia Processing Audio Processing Developer Tools
chrishayuk
A
license
Not graded
quality
D
maintenance
Enables AI-assisted music composition through copyable pattern templates, style constraints, and arrangement tools that compile to MIDI files. Provides 30+ tools for managing musical structures, layers, patterns, and styles with deterministic compilation from YAML arrangements.
Updated 8 months ago (2025-12-24 01:23 UTC)
1
MIT
Scribbletune MCP Server
Audio Processing Multimedia Processing
claboran
A
license
Not graded
quality
D
maintenance
Enables AI agents to generate MIDI clips from natural language descriptions and export them for import into digital audio workstations. Wraps Scribbletune to provide music composition tools for creating riffs, chords, and arpeggios with scale-aware progressions, rhythmic patterns, and genre-specific parameters.
Updated 5 months ago (2026-04-07 10:41 UTC)
MIT
THIRI Chord Intelligence —
Audio Processing Education & Learning Tools
BluesPrince
A
license
A
quality
A
maintenance
Deterministic music-theory MCP server and API for AI agents — analyze chords, run Roman-numeral analysis, generate voicings, and reharmonize progressions. Computed from music theory, not hallucinated.
Updated a month ago (2026-08-10 01:22 UTC)
5
100
6
PolyForm Noncommercial 1.0.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/voho/midi-composer-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

midi-composer-mcp

Note format

Tools

Scales & chords

Harmony rules

Melody

Rhythm

Song structure & rendering

Examples

Simple

Intermediate

Advanced

Demo gallery

Playable output

A composing session looks like this

Arrangement track shapes (for arrange_to_midi)

Installation

Claude Code

Claude Desktop

Development

Roadmap ideas

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Arrangement track shapes (for `arrange_to_midi`)