Skip to main content
Glama
Sign In
SFX Brew

SFX Brew

by 2365836149-sketch
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Render a custom sound patch

render_patch

Render a hand-edited sound patch to a WAV file, turning JSON layer and effect settings into audio.

Instructions

Render a hand-edited patch (for example one returned by generate_sfx with changed values) to a WAV file. A patch is JSON: { layers: Layer[1..6], reverb 0-1, echo 0-0.9, echoTime s, drive 0-1, crush 0|1-16 bits, gain 0-1 }. Layer fields (all optional, defaults in brackets): type: "tone"|"fm"|"string"|"pluck"|"bell"|"noise" ["tone"]; wave: "sine"|"triangle"|"square"|"sawtooth" (tone/fm/pluck) string: physically modelled plucked string (Karplus-Strong); bright 0-1 [0.5] = darker (guqin) to brighter (pipa); decay = ring time bell: partials = [[ratio, amplitude, decayMultiplier 0-1], ...] (max 16) for custom bells, gongs, wood blocks; default is a metal bar sample: a CC0 recording; sample = one of drum-center-loud, drum-center-soft, drum-edge-loud, drum-rim, lightning-1, lightning-2, gong-1, gong-2, erhu-d3, erhu-f5, sword-clash, footstep-stone, arrow, footstep-grass, land, shield-block, page-turn, typewriter, chest-open, monster-growl, campfire, stream; pitch / pitchEnd semitones (slide over slideTime); offset s into the recording; set hold ≈ recording length to let it ring naturally (lengths s: drum-center-loud 2.7, drum-center-soft 2.7, drum-edge-loud 3.5, drum-rim 1.8, lightning-1 6.5, lightning-2 7, gong-1 10, gong-2 12, erhu-d3 4.9, erhu-f5 6, sword-clash 7.2, footstep-stone 5.4, arrow 4, footstep-grass 3.2, land 2.1, shield-block 3.6, page-turn 8.75, typewriter 4.55, chest-open 11.1, monster-growl 12.8, campfire 10.4, stream 10.4) freq, freqEnd: Hz, pitch slides exponentially from freq to freqEnd; slideTime: s the slide takes (0 = whole sound) hold: s to stay at full volume before the decay starts (louder, more violent bodies) repAccel: gap multiplier per repeat (<1 speeds up, e.g. 0.86 for an accelerating drum build-up); repGain: loudness multiplier per repeat (>1 crescendo) freqPeak / cutoffPeak (Hz, 0 = off): go up to this value by the end of attack, then down to freqEnd / cutoffEnd (Doppler-like pass-by for swishes) start: s delay; attack: s; decay: s (exponential fade); vol: 0-1 filter: "none"|"lowpass"|"highpass"|"bandpass"; cutoff, cutoffEnd: Hz; sweepTime: s (0 = whole); q: resonance vib: vibrato depth in cents; vibRate: Hz rep: number of repeats; repGap: s between repeats; repStep: pitch step per repeat; scale: "penta"|"chromatic" (unit of repStep) jitter 0-1: random gaps (1 = Poisson-like) and loudness per repeat; pitchJitter: semitones of random pitch/cutoff per repeat (crackles, bubbles, debris) noise layers: color "white"|"pink"|"brown"; any layer: trem 0-1 + tremRate Hz = wavering loudness (flames, rumble) patch.seed: integer that fixes the random pattern of jitter unison: 1-5 stacked voices; detune: cents spread fmRatio, fmIndex, fmDecay: FM modulator ratio, depth and how fast the depth decays (type "fm" only) Tips: punchy impacts = short noise layer (decay ~0.01) + tone with fast slideTime (~0.04); metallic = fm or bell; keep total vol*gain under ~1.

Input Schema

NameRequiredDescriptionDefault
nameNoName used for the JS play function (default: file name)
patchYesPatch JSON object with a "layers" array
js_pathNoAlso write a .js file with a play function for this sound
out_pathYesWAV file to write

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only declare destructiveHint=false, so the description carries most of the load and does state the material side effects: a WAV is written to out_path and, if js_path is given, a .js play function file is also written. It omits overwrite semantics, error behavior on invalid patches, and runtime cost, which keeps it below a 5.

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 purpose is front-loaded and the reference block is genuinely useful, but the description is very long and crammed into dense semicolon-chained lines with inline sample-length tables that would read better as schema properties or linked docs. Size is defensible for the payload complexity, but structure and density cost it.

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 nested-object tool with no output schema, the definition supplies the full patch grammar, defaults, value ranges, seed semantics, and even construction tips for common timbres. An agent has enough to author a valid patch and predict the audible outcome without further lookups.

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

Parameters5/5

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

Top-level schema coverage is 100%, but the patch parameter is an opaque `additionalProperties: {}` object, so the schema documents none of the layer structure. The description fully compensates by enumerating layer types, field ranges defaults in brackets, and sample names with their recording lengths, which is meaning the schema cannot provide.

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?

The first sentence states a specific verb and resource ('Render a hand-edited patch ... to a WAV file') and identifies the sibling generate_sfx as the producer of such patches, so the agent can distinguish it from generate_sfx and list_presets 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?

It gives a clear when-to-use signal: this is for patches you have edited yourself, such as one returned by generate_sfx with changed values, which implicitly routes generation-only requests to generate_sfx. It stops short of explicit exclusions or prerequisites such as whether an existing out_path is overwritten.

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