ismail: agent DAW (MCP server)

Overview Schema Source Related Servers Discussions Admin

Sketch

sketch

Create musical drafts by describing your vision in plain language. Specify genre, tempo, and instrumentation, then guide the sound with follow-up instructions to refine the composition.

Instructions

First sound for a new song, in one call: short sketches on the showcase voices, each a project in /sketches/-/, rendered to mp3 (wav without ffmpeg). brief: the person's words. The brief is read: a tempo ('90 BPM'), a key ('A minor'), a genre (trip-hop, house, jazz, rock, ambient, a church prelude or hymn ...), gentle or soft words, instruments and a form (intro, groove, breakdown, return, fade) shape the sketch; three readings come back (as asked, sparser, busier). Whatever has no voice yet is named first in the reply ("asked for Rhodes: ... grand_piano plays its part"): tell the person. A brief naming no genre or instrument gets three contrasting styles (piano, chamber, band). base='' (or its letter): the next round, that sketch changed by the brief's words ("slower, no guitar, add a pad", "a bit happier"): as asked, then the change taken further; n: how many (default 3, or 2 with base). styles: force the fixed styles. key, bpm, bars, progression ('i VI III VII' or chord names) override. Play each to the person, ask which is closest or what each is missing, then sketch_keep(project, ''). For a person on plain words it is different: play version 1 at once (the rest are spares), offer the 2 or 3 everyday-word choices in SAY TO THE PERSON plus "or tell me anything", and play each change new version first. The first sketch comes back as soon as it is rendered and the others render in the background (background= False waits for all): play the first while they land, and sketch_wait(project) says when they are ready. The reply opens with SAY TO THE PERSON, written for them: read it out as it is. Every sketch is mixed (the tune sits 4-6 LU over the rest: it rises at most 8 dB and the other parts come down for the rest, and the reply gives the level measured in the final mix) and mastered for its style. Versions are numbered across rounds (a next round's first is version 4 after three), so every number names one sketch. A next round (base=) keeps the person's tune and chords and changes only what their words name; its reply names the version to play as "before". wait: when the machine is busy, stand in line this long ('2m' default, '0' refuses at once). A bare number is minutes: wait='10' is ten minutes; for seconds write wait='600s'.

Input Schema

Name	Required	Default
`n`	No
`bpm`	No
`key`	No
`bars`	No
`base`	No
`seed`	No
`wait`	No	2m
`brief`	Yes
`styles`	No
`project`	Yes
`background`	No
`progression`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.0Oct 26, 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 full burden and discloses a lot beyond the schema: files are written to <project>/sketches/<letter>-<label>/, output is mp3 (wav without ffmpeg), the first sketch returns while the rest render in the background, background=False waits, wait='0' refuses at once, every sketch is mixed (tune 4-6 LU over the rest, max 8 dB rise) and mastered, and version numbers are global across rounds. Gaps remain: nothing about permissions, cost/time, or whether an existing sketch path is overwritten (it is a filesystem mutation), and no error behavior is described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content mostly earns its place, but the structure does not: it is one long block of run-on sentences with subordinate clauses stacked in parentheses ('(as asked, sparser, busier)', '(background=False waits for all)'), and a critical operational instruction — read SAY TO THE PERSON aloud as written — appears mid-paragraph. Key routing facts (wait semantics, background render timing) are buried near the end rather than front-loaded, forcing an agent to parse the whole block to act correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter generative tool with no annotations, the description covers what is created, where, in what format, how rounds work, how output is mixed/mastered, what the reply contains ('SAY TO THE PERSON', measured levels, named missing voices), and how to hand off to sketch_keep and sketch_wait. An output schema exists, so return-value structure need not be restated. The only real omission is 'seed', which is minor against the overall coverage.

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 description coverage is 0%, so the description must compensate across 12 parameters, and it does for almost all of them: brief (with a full grammar of tempo, key, genre, mood words, instruments, form), base, n (default 3, or 2 with base), styles, key, bpm, bars, progression, wait (including bare-number-is-minutes and '600s' syntax), and background. Only 'seed' is left completely unexplained, and 'project' is only implied by the output path. Strong compensation, short of complete.

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 names a specific verb and artefact ('First sound for a new song, in one call: short sketches on the showcase voices, each a project in <project>/sketches/<letter>-<label>/, rendered to mp3'), so an agent knows exactly what is produced and where. It implicitly separates itself from sibling tools sketch_keep and sketch_wait by referencing them as the follow-up steps. Clarity is slightly reduced by the run-on phrasing that packs multiple ideas into one sentence.

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?

Explicit when-to-use is given throughout: use base='<version>' for a next round, use styles to force fixed styles, key/bpm/bars/progression to override, and the distinct plain-words path ('play version 1 at once... offer the 2 or 3 everyday-word choices... play each change new version first'). It also prescribes the surrounding workflow ('Play each to the person, ask which is closest or what each is missing, then sketch_keep(project, '<version>')') and when to call sketch_wait. Alternatives and conditions are named rather than inferred.

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

Deploy Server