Skip to main content
Glama

humanize_midi_notes

Nudge MIDI note timing and velocity with seeded random offsets to add human feel while keeping results reproducible and pitches unchanged.

Instructions

Humanize MIDI: nudge timing and velocity by small random amounts, reproducibly.

Each note gets its own timing and velocity offset drawn from a bell curve. Note lengths are preserved (start and end move together) and pitches are never touched. The randomness is seeded, so the same take with the same seed and settings gives identical results every time. Velocities are clamped to 1-127 and counted in clamped; notes pushed past the item end are kept and reported in out_of_bounds.

Unlike the other timing tools, a note pushed before the item start is placed at the item start and counted in out_of_bounds, not clamped; clamped here counts only the velocity clamp.

Args: timing: Timing spread in beats (standard deviation); 0.02 is a subtle human feel, 0.0 leaves timing alone. velocity: Velocity spread (standard deviation, in velocity units); 0.0 leaves velocity alone. seed: Any integer. The same seed, settings and take give the same result. max_sigma: Cap on how far one note may stray, in multiples of the spread.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
seedNo
fieldsNo
timingNo
channelNo
end_beatNo
velocityNo
max_sigmaNo
pitch_lowNo
item_indexYes
pitch_highNo
start_beatNo
track_indexYes
return_notesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.7.3

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does so well: bell-curve offsets, preserved note lengths, untouched pitches, seeded reproducibility, velocity clamping to 1-127, out-of-bounds notes past item end kept and reported, and pre-start notes snapped to item start. It omits which notes are targeted (all vs. selection) and the return shape beyond the clamped/out_of_bounds counts.

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 one-line summary followed by behavior, edge cases, and an Args block — logical and mostly earned. The middle paragraph on clamping vs. out_of_bounds is dense and slightly redundant, but appropriate for a tool with this much edge-case behavior.

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?

For a 13-parameter mutation tool with no output schema and no annotations, the description covers the core effect and edge cases but leaves the scope filters (fields, channel, pitch range, beat range) and return_notes undocumented. An agent cannot fully determine which notes will be modified or what to pass for half the parameters.

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% and there are 13 parameters, but the Args section documents only timing, velocity, seed, and max_sigma. Nine parameters (track_index, item_index, fields, channel, start_beat, end_beat, pitch_low, pitch_high, return_notes) get no explanation in either the schema or the description, so the low coverage is not compensated.

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+resource ("Humanize MIDI: nudge timing and velocity") and specifies the mechanism (small random amounts, reproducibly). It explicitly positions itself relative to other tools with "Unlike the other timing tools," so an agent can distinguish it from nudge/quantize/strum siblings.

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?

Usage is implied by the purpose and the "Unlike the other timing tools" comparison, but there is no explicit when-to-use/when-not guidance or named alternative (e.g., use nudge_midi_notes for deterministic shifts, quantize for grid snap). The agent must infer the choice.

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