ismail: agent DAW (MCP server)

Overview Schema Source Related Servers Discussions Admin

Spectrogram

spectrogram

Render a mel-frequency PNG for a time/frequency window with optional bar lines, ruler, and word markers, returning the image path plus a JSON pixel map for visual audio comparison.

Instructions

Write a mel spectrogram PNG with bar lines (the one non-text view). Returns the PNG path. A picture for the person to look at AND mark is exam_picture_round, not a PNG: they flip between the two and pin what differs. For eyes (zoomed on one sound, to compare two by picture): seconds=[t0, t1] inside bars (or the source), the band f_lo..f_hi Hz, ruler=True (ms from the window start), words=[{'w', 't0', 't1'}] in s. That picture sits on a fixed plot box, so two of the same window line up pixel for pixel, and a .json beside it maps a pixel to (s, Hz). Zoom early, not as a last resort, when: the person names a texture (robotic, digital, bitcrushed, smeared, gargle, old TTS, cut off, pre-delay, reversed, phaser); the numbers say close but the ear says no; the sound is a voice, sung words or a played instrument; two rounds passed without progress; or to see that a fix made its spot fade. Draw the reference and yours on the same window, two ways (a few ms around an edge; a whole word or note for texture; sound_zoom draws both in one picture), and read them one above the other (references/listening.md, "When to zoom"). Where yours differs beyond the reference's own spread: sound_zoom_diff.

Input Schema

Name	Required	Description	Default
`out`	No
`bars`	No
`f_hi`	No
`f_lo`	No
`ruler`	No
`words`	No
`source`	No
`project`	Yes
`seconds`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.4.0Oct 26, 2026

addedInput schema / properties / f_hi

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

addedInput schema / properties / f_lo

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

addedInput schema / properties / ruler

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

addedInput schema / properties / seconds

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

addedInput schema / properties / words

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

First observedv0.3.0Oct 3, 2026

TDQS

A4.1/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 disclose real behavior beyond the name: it writes a PNG file, returns its path, emits a sidecar .json mapping pixels to (s, Hz), and places the image on a fixed plot box so same-window shots align pixel for pixel. It does not state overwrite semantics for `out` or cost of rendering, so it is strong but not complete for an unannotated tool.

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?

Purpose and return are correctly front-loaded, and most sentences carry information that is not in structured fields. But the prose is a dense run-on with cryptic fragments ("A picture for the person to look at AND mark is exam_picture_round, not a PNG") and no list structure, so the parameter and trigger content has to be re-parsed rather than scanned.

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?

Usage triggers and sibling routing are unusually complete, and an output schema exists so return values need no explanation. The gap is on the input side: 9 parameters at 0% schema coverage with 4 undocumented and one ambiguously notated, which is a real shortfall for a tool whose whole purpose is dialing in a zoom window.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% over 9 parameters, so the description must compensate; it explains seconds=[t0,t1], f_lo..f_hi, ruler=True (ms from window start) and words, which is real added meaning. However `out`, `bars`, `source` and `project` go unexplained, and the notation "words=[{'w', 't0', 't1'}]" reads like a set of strings rather than an array of objects, which risks mis-constructing the argument.

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?

Opens with a specific verb+resource: "Write a mel spectrogram PNG with bar lines", and immediately distinguishes itself as "the one non-text view" that returns a PNG path. It also separates itself from the similarly named exam_picture_round and from sound_zoom/sound_zoom_diff, so an agent can place it among siblings without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger list for when to use it ("Zoom early, not as a last resort, when: the person names a texture...; the numbers say close but the ear says no; two rounds passed without progress") and names alternatives for adjacent needs (exam_picture_round for marking, sound_zoom to draw both in one picture, sound_zoom_diff for divergence). This is genuine when/when-not/alternative routing.

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

Deploy Server