Skip to main content
Glama

analyze_pitch

Idempotent

Measure pitch accuracy of sung audio by comparing notes to a reference MIDI melody or chosen key, reporting cents deviation, vibrato, note accuracy, and timing alignment.

Instructions

Measures the pitch accuracy of sung audio (solo voice, one melodic line).

Args:
    audio: audio path (wav/flac/mp3/m4a) or a name returned by record_audio.
    reference_midi: optional path to a .mid with the expected melody. Tolerates singing an
        octave up/down, starting at another moment and a somewhat different tempo.
    key: optional when there is no MIDI, e.g. "A minor", "G major", "F#" (Spanish names such as
        "La menor" also work): each note is compared with the nearest note of that scale.
        Without it, with the nearest equal-tempered note.
    midi_track: index of the MIDI track to use (default: the non-drum track with most notes).

Returns `summary` (notes, range, pct_within_25_cents, signed mean_deviation_cents,
tendency flat/sharp/centered, drift_cents between 1st and 2nd half, stability counts; with
MIDI also missed, extra_notes, wrong_notes, onsets on_time/late/early, octave_shift,
start_offset_ms and relative_tempo >1 = slower) and `notes`: t (s), dur, note or
expected/sung, cents (+ = sharp), stability (stable | vibrato with vibrato_hz and
vibrato_pp_cents | unstable with std_cents), drift_cents within the note and, with MIDI,
onset_ms/onset; reference notes not sung have status=missed and unmatched sung notes
status=extra. If the list does not fit, the most problematic notes are shown and the rest
is in `full_details`.

Input Schema

NameRequiredDescriptionDefault
keyNo
audioYes
midi_trackNo
reference_midiNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover safety (non-destructive, idempotent, closed-world), so the description correctly spends its words on tolerance behaviour an agent could not infer: octave-up/down singing, late starting points, tempo variance, and the fallback comparison path. It does not mention failure modes (polyphonic input, unreadable files) or processing cost.

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 and parameter block are front-loaded and efficient, but the Returns paragraph is a dense run-on enumeration of summary and note fields that largely duplicates the output schema. An agent must parse a long comma-spliced sentence to extract the few novel semantics (cents sign, tempo ratio direction).

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 4-param analysis tool with an output schema, the description covers input formats, matching modes and result interpretation; the return-value detail is a bonus rather than a gap. Only edge-case behaviour and the constraint enforcement on polyphonic audio are unaddressed.

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%, yet all four parameters are documented with real semantics: accepted audio formats and the link to record_audio names, the .mid expectation, key syntax with examples in two languages, and midi_track's default resolution rule. This fully compensates for the empty 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?

States a specific verb and resource ('Measures the pitch accuracy of sung audio') plus the scope constraint 'solo voice, one melodic line', which tells an agent immediately what input is valid. This is clearly distinguishable from recording, transcription or pronunciation siblings without opening a schema.

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?

Gives conditional guidance on the two analysis modes: reference_midi when a score exists, key when there is no MIDI, and plain nearest-note comparison when neither is supplied. It stops short of explicitly naming alternatives (e.g. 'use transcribe for text output') or stating when not to use it.

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