Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Analyze Feel

analyze_feel

Measure per-note timing and level feel against a reference to diagnose why a MIDI part sounds mechanical, stiff, or quantized, including beat offsets, offbeat placement, and level steps.

Instructions

The per-note feel of a part: what makes a draft "sound MIDI" or "mechanical", measured on a beat line that follows the record (a drifting or rubato take stays locked). For every slot of bars [a, b] (the beats, and the 8ths (per_beat=2) or 16ths (per_beat=4) spread evenly between the followed beats) it reads the onset within window_ms in band ([lo, hi] Hz, default [600, 4000]) and the slot's peak level there, then prints: the timing spread (sd, ms) of the notes between the beats with each beat's own offset taken out; where the offbeat 8th sits as a share of the beat (0.500 = even); the mean level by metric position against its bar's mean (beat 1, 2, ..., and the e, &, a); the sd of note-to-note level steps; the beats it could not follow. against='ref' (with source='render' or 'track:') prints both columns and the differences, and names the ones that read as MIDI-like. Reach for it when a draft sounds MIDI, mechanical, robotic, stiff or quantized against a reference, or to check feel_from_ref's result. Read a stem (ref:, track:) when the part shares its band with others.

Input Schema

NameRequiredDescriptionDefault
bandNo
barsYes
sourceYes
againstNo
projectYes
per_beatNo
window_msNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.3

TDQS

A3.9/5.0
Behavior4/5

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

No annotations are provided, so the description carries the behavioral burden, and it does disclose measurement windows, band defaults, per_beat subdivisions, printed columns, reference-comparison output, and beats it could not follow. It does not explicitly state read-only/no-side-effect behavior, though the analysis framing strongly implies it.

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 is front-loaded, but the description is a dense, run-on paragraph with nested parentheticals that is hard to scan. Most details earn their place for a complex analysis tool, but the structure is not concise.

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 7-parameter analysis tool with no annotations and no schema descriptions, the description gives enough measurement and output behavior to invoke it correctly, and the output schema covers return values. Minor gaps remain around the project parameter and an explicit no-mutation statement.

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 schema description coverage at 0%, the description compensates well by explaining band defaults, window_ms, per_beat values, source formats such as render and track:<name>, against='ref', and bars slots. It leaves project unexplained and gives only an approximate format for the bars array.

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 identifies a specific analysis target—per-note feel—and enumerates timing and level metrics such as timing spread, offbeat placement, and level by metric position. It distinguishes the reference-comparison mode and feel_from_ref check, but does not explicitly differentiate itself from nearby siblings like analyze_swing or analyze_grid.

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?

It explicitly says to reach for the tool when a draft sounds MIDI-like, mechanical, robotic, stiff, or quantized against a reference, or to check feel_from_ref's result. It also advises reading a stem when the part shares its band, but does not give explicit when-not conditions or a full list of alternatives.

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