Skip to main content
Glama

transpose_midi_notes

Shift MIDI notes up or down by semitones to change pitch; notes outside 0-127 are kept and skipped.

Instructions

Transpose MIDI notes by a number of semitones (12 = an octave).

A note that would land outside pitch 0-127 keeps its original pitch and is counted in skipped instead.

Args: semitones: Signed shift; positive is up, negative is down. 0 = no-op.

Returns: {ok, notes_changed, clamped, skipped, out_of_bounds, notes:[...]}, where notes is the full note list after the transform, re-indexed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fieldsNo
channelNo
end_beatNo
pitch_lowNo
semitonesYes
item_indexYes
pitch_highNo
start_beatNo
track_indexYes
return_notesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.7.3

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses that out-of-bounds notes keep their original pitch and are counted in `skipped`, and it names the return fields. But it says nothing about required track/item context, permissions, undo behavior, or what `clamped` and `out_of_bounds` mean in relation to `skipped`.

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 and front-loaded: purpose first, then a key edge case, then Args and Returns. It is not bloated, though the Args section is so sparse that it reads as incomplete rather than concise.

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?

For a 10-parameter mutation-style tool with no annotations and no output schema, the description is substantially incomplete. It covers the main parameter and return shape but omits most of the parameters an agent needs to call it correctly, including required track_index and item_index.

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 the description must compensate. It explains only `semitones` (signed shift, 0 = no-op) and leaves nine parameters—track_index, item_index, channel, pitch_low, pitch_high, start_beat, end_beat, fields, return_notes—without any semantic detail.

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?

States a specific verb ('Transpose') and resource ('MIDI notes') and clarifies the unit of shift (semitones, 12 = octave). It does not name or differentiate itself from sibling MIDI-note tools such as snap_midi_notes_to_scale or nudge_midi_notes, so it falls short of a 5.

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 versus alternatives like set_midi_note, nudge_midi_notes, or snap_midi_notes_to_scale. The description only defines the transform, not the context or prerequisites for invoking it.

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