ismail: agent DAW (MCP server)

Overview Schema Source Related Servers Discussions Admin

Analyze Swing

analyze_swing

Measure how late swung hi-hats land in beats and milliseconds, compare a reference or track, and detect timing drift so you can write or verify swung note placement.

Instructions

How late the swung hi-hats land, in beats and ms (16ths: the 'a' against the 'and'; 8ths: the 'and' against the beat). Default source: the reference drum stem if there is one, else the reference/render. Use it on a reference before writing swung notes, and on 'track:' to check yours. Straight = 0. follow=True reads a record that drifts (played without a click): a beat line follows the thumb, bass or kick (55-190 Hz) from the project tempo, every 16th step is read on it in band_hz ([lo, hi] Hz, default [1500, 6000] for finger plucks; [6000, 16000] for hats), and it prints the hits, accents and median offset per step against the plucks on the beats, and the most-played 16-step strings with the timing inside them. A step counts as a pluck when its peak is over threshold x the 95th percentile peak (raise it, e.g. 0.5, when a dense stem reads X on every step). Without follow, a line says when the beat drifts more than 3% and the fixed grid smears the offsets.

Input Schema

Name	Required	Description	Default
`follow`	No
`source`	No
`band_hz`	No
`project`	Yes
`threshold`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.4.0Oct 26, 2026

addedInput schema / properties / band_hz

Added value: +{
+  "default": null,
+  "items": {},
+  "type": "array"
+}

addedInput schema / properties / follow

Added value: +{
+  "default": false,
+  "type": "boolean"
+}

addedInput schema / properties / threshold

Added value: +{
+  "default": 0.35,
+  "type": "number"
+}

First observedv0.3.0Oct 3, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: default source resolution order, per-step output contents (hits, accents, median offset, most-played 16-step strings), pluck detection logic via threshold against the 95th percentile peak, and drift reporting above 3%. It never states that the operation is read-only/non-destructive or what permissions/project state it requires, which is the remaining gap for a zero-annotation tool.

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 purpose is front-loaded in the first sentence and almost every clause adds operational information rather than filler. The cost is density: a single ~70-word sentence covers all of follow mode, and undefined/elliptical references ('reads X', 'the thumb') make parts harder to parse than necessary.

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 five-parameter analysis tool with an output schema (so return format needn't be re-explained) and no annotations, the description covers sources, modes, thresholds, band defaults and the fixed-grid caveat — enough to call it correctly in normal cases. It omits any statement of safety/read-only nature or what 'project' expects, which keeps it from being fully self-sufficient.

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% across five params, and the description compensates for most of them: source default resolution and 'track:<hats>' syntax, follow semantics at length, band_hz defaults per material ([1500,6000] plucks, [6000,16000] hats), and threshold's meaning plus a suggested value (0.5). Only 'project' is left implicit, and the threshold guidance contains an undefined placeholder ('reads X on every step'), which blunts precision.

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 opening sentence states a precise measurement — how late swung hi-hats land, in beats and milliseconds — and anchors the scale with 'Straight = 0' and the 16th/8th reference points, so the resource and output semantics are unambiguous. It never names a sibling (e.g. analyze_grid, analyze_roll) to explicitly delimit scope, though the closing mention of 'the fixed grid smears the offsets' implicitly contrasts grid-based timing with this beat-line reading.

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 gives two concrete usage scenarios: 'Use it on a reference before writing swung notes, and on track:<hats> to check yours.' It also states the condition that selects follow=True (a record that drifts, played without a click). There is no explicit when-not or named alternative tool, so it stops short of a 5.

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

Deploy Server