Skip to main content
Glama
zimba7768

NoiseSmith

by zimba7768
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

mix_sounds

Layer multiple sounds into a single scene such as a storm or busy street by combining recipes, audio files, and custom generators with precise timing and volume control.

Instructions

Layer several sounds into one scene, such as a storm, a busy street or a haunted room.

layers is a list of dictionaries. Each has exactly ONE source: {"recipe": "wind", "intensity": 1.0, "style": "howling"} a NoiseSmith recipe {"file": "sounds/thunder.wav"} an audio file (wav, flac, ogg, mp3) {"generator": {"type": "noise", "color": "brown", "duration_s": 3, ...}} a custom sound A recipe layer also takes that recipe's intensity, size, style, duration_s and seed. Every layer can set: gain_db (volume in decibels, 0 default, -6 half as loud), start_s, length_s, fade_in_s, fade_out_s, speed (below 1 lower and slower), and repeat_every_s with repeat_jitter (0 to 1, uneven spacing), repeat_count and speed_jitter to repeat the sound through the scene. Example, a storm: [{"recipe": "wind", "intensity": 0.9, "style": "gusty", "duration_s": 20, "gain_db": -3}, {"recipe": "rain", "intensity": 0.8, "duration_s": 20, "gain_db": -6}, {"recipe": "impact", "style": "stone", "size": 1.0, "intensity": 0.6, "gain_db": -12, "start_s": 4, "repeat_every_s": 9, "repeat_jitter": 0.6}] A custom generator is {"type": "noise" or "tone", "duration_s", "color" (white/pink/brown), "wave" (sine/triangle/square/saw), "freq_hz" (a number or {"from": hz, "to": hz}), "filters" (a list of lowpass/highpass/bandpass with freq_hz and q) and "envelope" (attack_s, hold_s, decay_s, release_s)}. Generators are for machinery, sci-fi and similar sounds, not animals or voices.

duration_s is the length of the whole scene (up to 120 s). loop, loop_crossfade_s, format and loudness work as in create_sound. If the layers add up too loud, the mix is turned down to stay clear of clipping. Scenes made only from recipes and generators are CC0; a file layer carries whatever license that file has.

Input Schema

NameRequiredDescriptionDefault
loopNo
nameNo
seedNo
formatNowav
layersYes
loudnessNo
duration_sYes
output_dirNo
descriptionNo
loop_crossfade_sNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the load and does well: it discloses the 120s scene cap, automatic gain reduction to avoid clipping ("the mix is turned down to stay clear of clipping"), and per-layer licensing (CC0 for recipes/generators, inherited for file layers). It does not state whether the scene is written to disk or previewed, nor what the call returns.

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

Conciseness5/5

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

Front-loaded with a one-line purpose, then organized into layer kinds, shared layer fields, a worked example, generator sub-spec, and scene-level caveats. Despite its length every block carries information an agent cannot get from the empty-coverage schema.

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 10-param, no-annotation, no-output-schema tool this is unusually complete on inputs and constraints. The remaining gap is output behavior — no indication of what is produced, where it lands, or how output_dir/name/description affect the result.

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%, so the description must compensate, and it does for most of the 10 params: `layers` gets a detailed union spec (recipe/file/generator) plus shared fields (gain_db, start_s, length_s, fades, speed, repeat_*), and duration_s, loop, loop_crossfade_s, format and loudness are all addressed. `name`, `description` and `output_dir` are never mentioned, leaving three params entirely undocumented.

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: "Layer several sounds into one scene," and immediately grounds it with concrete scene examples (storm, busy street, haunted room). This is clearly distinguishable from create_sound (single sound) and make_loop (looping) without opening any schema.

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?

Use cases are given concretely and a full worked storm example shows the intended call shape, plus a negative rule ("Generators are for machinery, sci-fi and similar sounds, not animals or voices"). It never explicitly says when to prefer create_sound or make_loop instead, so routing between siblings is left to inference.

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