Skip to main content
Glama
Sign In
ismail: agent DAW (MCP server)

ismail: agent DAW (MCP server)

by newsbubbles
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Sound Speak

sound_speak

Convert text to speech into the project's sound bank using the OS voice engine, with optional rhythm mapping to align spoken syllables to musical beats.

Instructions

Text-to-speech into the sound bank with the OS's own engine: Windows SAPI (voices like David, Zira; the default is David), macOS say (Alex, Samantha ...), Linux espeak-ng (en-us, en-gb ...). A voice the engine doesn't have falls back to its default. rate -10..10. Use as a vocoder modulator (vocoder fx, modulator='sound:' or a muted track holding it as audio clips), a sampler source, or an audio clip. On Windows the engine's own word and phone timings are saved next to the sound (sounds/.timings.json); other systems give no timings. Reach for rhythm= when spoken words must land on the beat (a narrator, a chopped vocal line): rhythm='night 0; shift 2; engineer 12 14 16' gives each word one 16th position per syllable (counted from the line's beat 1, negative before it; '-' skips a syllable; one position keeps the word whole), and each syllable is cut where the next one starts and set on its 16th at bpm (default the project's). The sound then starts on its first syllable's slot; the reply says where to place it. Windows SAPI only (the timings come from its events; built in a song and proven there).

Input Schema

NameRequiredDescriptionDefault
bpmNo
nameYes
rateNo
textYes
voiceNo
rhythmNo
projectYes
normalizeNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.4.0
    • addedInput schema / properties / bpm
      Added value: +{
+  "default": null,
+  "type": "number"
+}
    • addedInput schema / properties / rhythm
      Added value: +{
+  "default": null,
+  "type": "string"
+}
  2. First observedv0.3.0

TDQS

A4.2/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 well: it discloses the unknown-voice fallback, platform-dependent timing-file side effects (sounds/<name>.timings.json on Windows only), and that rhythm mode is Windows-SAPI-only. It omits what happens if a sound of that name already exists (overwrite vs. error) and any failure modes, which matters for a tool that writes into the sound bank.

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 core purpose is front-loaded, but the middle section is a dense run-on that interleaves the rhythm syntax with the platform caveat, and asides like 'built in a song and proven there' add no decision value. The rhythm rules could be split into shorter sentences without losing content.

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?

An output schema exists, so return values need no explanation, and the description still usefully says the reply indicates placement. For an 8-parameter write tool at 0% schema coverage the coverage is strong; the remaining gap is `normalize` plus overwrite/collision behavior on the target sound name.

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 does the work: it explains `voice` naming and fallback, `rate` bounds (-10..10), `rhythm` syntax in real depth with an example, `bpm` defaulting to the project tempo, and `name`'s role in the timings filename. `normalize` is never explained and `project` is only implied, leaving one parameter opaque.

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 and resource: text-to-speech rendered into the sound bank using the OS engine, and it goes further by naming the actual engines/voices per platform. An agent knows exactly what will be produced (a named sound asset) and where it lands, which is more than the title conveys.

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?

Explicit use contexts are given: vocoder modulator (with the exact `sound:<name>` reference form), sampler source, or audio clip, plus a clear rule for when to reach for `rhythm=`. It stops short of naming adjacent sibling tools that also produce speech (phone_say, stage_say, chat_say) or when not to use this instead of them.

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