Skip to main content
Glama

stretch_midi_notes

Scale MIDI note timing by a factor around a pivot to create half-time or double-time rhythms while preserving each note's relative spacing.

Instructions

Stretch or compress MIDI timing (half-time, double-time, or any ratio).

Each targeted note scales as a rigid unit about one fixed pivot: its distance from the pivot and its own length both multiply by factor, so the rhythm is preserved and only the speed changes. Notes that land past the item end are kept as-is; one pushed before the item start begins at the item start but keeps its scaled end, so it comes out shorter. Both are counted in out_of_bounds (clamped stays 0 here).

Args: factor: Time scale ratio, must be > 0. 2.0 = twice as long (half-time), 0.5 = half as long (double-time). pivot_beat: The fixed point, in beats from the item start; may be negative. None = the earliest targeted onset.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.7.3

TDQS

A4.3/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 rich behavioral detail: the rigid-unit scaling mechanic, pivot behavior, edge-case handling for notes past the item end and before the item start, and the out_of_bounds/clamped counting semantics. This is exactly the kind of non-obvious behavior an agent needs to invoke correctly.

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?

Front-loaded with the core action and examples, then a dense but purposeful paragraph on mechanics, then the Args section. Slightly verbose in the edge-case explanation but 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?

For a mutation tool with no annotations and no output schema, the description covers the critical non-obvious behavior (pivot mechanics, boundary handling, counting). It falls short only on the un-narrated upper/mid note-selection parameters, but the core contract is complete enough to call safely.

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%, so the description must compensate, and it does for the two most semantically loaded params: factor (ratio direction and magnitude) and pivot_beat (definition, negative allowed, None default). The other nine parameters (track_index, item_index, fields, channel, start_beat, end_beat, pitch_low, pitch_high, return_notes) are left entirely undocumented, which is a real gap but the hardest ones are 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?

States a specific verb (stretch/compress) and resource (MIDI timing) with concrete examples (half-time, double-time, any ratio). Clearly distinct from siblings like nudge_midi_notes or quantize_midi_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?

The description implies when to use it (changing MIDI timing) but does not name alternatives such as nudge_midi_notes or set_tempo, nor does it say when NOT to use it. Usage is only inferable from the purpose.

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