Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bfxr2-music-generator Generate a laser sound effect"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides music and sound effect generation tools using the existing Bfxr2 codebase.
Related MCP server: sfx-gen-mcp
Sound Effect Generation: Create preset sound effects (pickup, laser, explosion, etc.)
Custom Sound Creation: Full parameter control for custom sounds
Random Generation: Generate random sounds with optional seeding
WAV Export: Export generated sounds as WAV files (base64 or data URI)
Parameter Inspection: View and modify sound parameters
Zero Code Duplication: Uses existing Bfxr2 JavaScript files directly
cd mcp
npm installTo use the bfxr2 MCP server with Cline or other MCP clients, add this configuration:
{
"mcpServers": {
"bfxr2-music-generator": {
"autoApprove": [
"list_presets",
"get_parameters",
"generate_sound_effect",
"randomize_sound"
],
"disabled": false,
"timeout": 30,
"type": "stdio",
"command": "node",
"args": [
"/path/to/your/bfxr2/mcp/src/server.js"
]
}
}
}Note: Update the path in args to match your actual bfxr2 installation directory.
npm startgenerate_sound_effect
Generate preset sound effects
Types: pickup, laser, explosion, powerup, hit, jump, blip
Optional custom parameter overrides
generate_named_sound
Generate sounds from precomputed named presets
Presets: cry, pluck, splash, droplet, rip, woof, pushrock, glass, bark, powerdown, smallbark, bounce
Each preset has carefully tuned parameters for specific sound characters
create_custom_sound
Full control over all sound parameters
Specify waveType, frequency, envelope, effects, etc.
create_sound_with_wave
Create sounds using wave type by name
Wave types: Square, Saw, Sin, White, Triangle, Rasp, Tan, Whistle, Breaker, Bitnoise, FMSyn, Voice
randomize_sound
Generate completely random sounds
Optional seed for reproducible results
mutate_sound
Create variations of the last generated sound
Slightly randomizes parameters while maintaining general character
export_wav
Export last generated sound as WAV
Formats: base64 or data URI
get_parameters
View current sound parameters
list_presets
List available generator presets (pickup, laser, etc.)
list_named_presets
List available named presets with descriptions (cry, bark, splash, etc.)
list_wave_types
List all available wave types with descriptions
{
"name": "generate_sound_effect",
"arguments": {
"type": "laser",
"customParams": {
"frequency_start": 0.7,
"attackTime": 0.1
}
}
}{
"name": "create_custom_sound",
"arguments": {
"parameters": {
"waveType": 2,
"frequency_start": 0.5,
"sustainTime": 0.3,
"vibratoDepth": 0.2
}
}
}{
"name": "generate_named_sound",
"arguments": {
"preset": "bark",
"filepath": "/tmp/bark.wav"
}
}{
"name": "create_sound_with_wave",
"arguments": {
"waveType": "Whistle",
"parameters": {
"frequency_start": 0.6,
"sustainTime": 0.4
},
"filepath": "/tmp/whistle.wav"
}
}{
"name": "mutate_sound",
"arguments": {
"filepath": "/tmp/mutated.wav"
}
}The MCP server uses a lightweight wrapper approach:
bfxr-wrapper.js: Provides minimal browser API mocks and loads existing Bfxr2 files
server.js: MCP server implementation with tool handlers
No code duplication: Directly imports from ../js/ directory
ID | Name | Description |
0 | Square | Classic square wave, good for retro game sounds |
1 | Saw | Sawtooth wave, raspy and buzzy |
2 | Sin | Pure sine wave, clean and simple |
3 | White | White noise, good for explosions and static |
4 | Triangle | Triangle wave, softer than square |
5 | Rasp | Periodic 1-bit noise, digital buzz |
6 | Tan | Tangent wave, potentially crazy/distorted |
7 | Whistle | Sin with overtone, breathy/hollow |
8 | Breaker | Quadratic wave, smooth and slick |
9 | Bitnoise | Periodic 1-bit white noise, glitchy |
10 | FMSyn | FM synthesis, dense and breathy |
11 | Voice | Digital voice sample |
Pre-configured sounds with carefully tuned parameters:
Name | Wave Type | Description |
cry | Voice | A crying/whimpering voice sound |
pluck | Voice | A plucked string instrument sound |
splash | Sin | A water splash effect |
droplet | Whistle | A water droplet sound |
rip | Voice | A tearing/ripping sound |
woof | Square | A dog bark/woof sound |
pushrock | White | A heavy object pushing/scraping sound |
glass | Whistle | A glass breaking/tinkling sound |
bark | Rasp | A sharp bark sound |
powerdown | White | A power-down/shutdown sound |
smallbark | Rasp | A small/quiet bark sound |
bounce | FMSyn | A bouncy/springy sound |
Key parameters you can control:
waveType: Wave shape (0-11)
frequency_start: Base frequency (0-1)
frequency_slide: Frequency sweep (-0.5 to 0.5)
attackTime: Volume envelope attack (0-1)
sustainTime: Volume envelope sustain (0-1)
decayTime: Volume envelope decay (0.03-1)
vibratoDepth: Vibrato strength (0-1)
vibratoSpeed: Vibrato speed (0-1)
We welcome contributions! Please see CONTRIBUTING.md for guidelines on how to get started.
See CHANGELOG.md for a list of changes in each version.
This project is licensed under the MIT License - see the LICENSE file for details.
Create completely custom retro sound effects with full control over all synthesis parameters. Define waveform type (square, saw, sine, noise, etc.), frequency characteristics, envelope shaping (attack/sustain/decay), vibrato effects, and frequency slides to craft unique 8-bit style audio.
| Name | Required | Description | Default |
|---|---|---|---|
| parameters | Yes | Sound generation parameters | |
| filepath | Yes | Full path where to save the WAV file (including .wav extension) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It describes the creation of audio and lists parameters, but it does not mention what the function returns (nothing expected) or the side effect of saving to a file. It lacks details on required permissions, whether the output is immediately audible, or if existing files are overwritten. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states core purpose, second enumerates parameter categories. No redundant or vague phrasing. Every sentence adds value, and key details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 nested parameters, no output schema, no annotations), the description covers the synthesis domain but omits the filepath parameter and any return value information. It assumes familiarity with sound synthesis terminology (e.g., attack, sustain). An AI agent might need more explanation of how parameters interact or typical values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description groups parameters into categories (waveform, frequency, envelope, vibrato) adding some semantic grouping beyond raw schema fields. However, it does not explain numeric ranges or the mapping of parameters to sound characteristics, which would enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates completely custom retro sound effects with full control over synthesis parameters. It lists the specific parameter groups (waveform, frequency, envelope, vibrato), distinguishing it from siblings like create_sound_with_wave (which likely offers simpler presets) and generate_sound_effect (which may be more automated).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for full custom control (as opposed to simpler generation), but it does not explicitly state when to use it over alternatives like create_sound_with_wave or generate_named_sound. No direct exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a sound using a specific wave type by name. Allows specifying the wave type using its name (e.g., 'Square', 'Saw', 'Whistle') instead of a numeric ID.
| Name | Required | Description | Default |
|---|---|---|---|
| waveType | Yes | Name of the wave type to use | |
| parameters | No | Additional sound parameters | |
| filepath | Yes | Full path where to save the WAV file (including .wav extension) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not mention that the tool creates a WAV file (though filepath in schema indicates this), nor any side effects, permissions, or overwrite behavior. It only says 'create a sound', which is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and no unnecessary words. It is efficient but could integrate the file creation aspect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits that the tool outputs a WAV file and does not mention the customizable parameters object. Given no output schema and nested parameters, more context is needed for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds examples for waveType but adds no additional meaning for the parameters object or filepath beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a sound using a wave type by name, and distinguishes from numeric ID usage. However, it does not fully differentiate from siblings like create_custom_sound or generate_named_sound.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using this tool when you know the wave type name versus a numeric ID, but it does not explicitly state when to use it over siblings or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the most recently generated sound effect to a new WAV file. Useful for saving variations of a sound or creating multiple copies with different filenames without regenerating the audio.
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes | Full path where to save the WAV file (including .wav extension) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description reveals state dependency on prior generation but omits side effects, error conditions (e.g., no sound generated), and whether operation is destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, no redundancy, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for simple export with clear purpose, but lacks details on prerequisites (must have generated sound) and return value (though no output schema expected).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter fully described in schema (100% coverage). Description adds no extra semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: exports WAV file from most recent sound effect. Distinguishes from sibling generation tools by focusing on saving existing sound.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states usefulness for saving variations or copies without regenerating, implying when to use. No explicit when-not or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a sound from precomputed named presets. These are carefully crafted sound configurations for specific effects like 'cry', 'splash', 'bark', 'glass', etc. Each preset has been fine-tuned for a particular sound character.
| Name | Required | Description | Default |
|---|---|---|---|
| preset | Yes | Name of the preset to generate | |
| customParams | No | Optional custom parameters to override preset values | |
| filepath | Yes | Full path where to save the WAV file (including .wav extension) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states 'generate a sound' but does not specify that it saves a WAV file (only hinted by the filepath parameter) or any side effects, output format, or permissions required. This leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are concise. However, the description could be front-loaded with the key detail about saving to a WAV file. Overall no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite full schema coverage, the description lacks critical details about what the tool returns (only filepath suggests output). It does not clarify whether the sound is played, returned as data, or saved. Sibling tools hint at output, but the description alone is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already explains customParams for overriding presets. The description adds context about preset quality but no additional meaning for required parameters (preset, filepath) or nested customParams fields. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a sound from precomputed named presets, listing examples like 'cry', 'splash', 'bark'. It distinguishes from sibling tools (e.g., create_custom_sound, generate_sound_effect) by specifying it uses precomputed presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a ready-made, finely tuned sound effect is desired, but does not explicitly contrast with alternatives like create_custom_sound or randomize_sound. The mention of presets being 'carefully crafted' provides usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate retro-style game sound effects using built-in presets. Choose from classic 8-bit sounds like coin pickups, laser shots, explosions, powerups, hit sounds, jump effects, and UI blips. Optionally override specific parameters to customize the sound while maintaining the preset's character.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Type of sound effect to generate | |
| customParams | No | Optional custom parameters to override | |
| filepath | Yes | Full path where to save the WAV file (including .wav extension) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions generating and saving a file (via filepath parameter), but does not clarify whether it overwrites existing files, what the success/failure response is, or any required permissions. It lacks some behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states the core purpose and the second lists examples and customization option. No redundant information; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, nested customParams object, no output schema), the description adequately covers preset usage and file saving but lacks details on error handling, parameter validation, or the exact output format (WAV is only in schema). It is sufficient but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, so baseline is 3. The description adds context about 'built-in presets' and 'classic 8-bit sounds', and mentions optional parameter overrides, but does not explain the meaning of individual sub-parameters (e.g., waveType values). It adds modest value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool generates retro-style game sound effects using built-in presets, and lists specific examples like coin pickups and laser shots. This distinguishes it from siblings like 'create_custom_sound' or 'create_sound_with_wave' which imply different generation methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for preset-based retro sound generation with optional customization, but it does not explicitly state when to use this tool versus alternatives like 'create_custom_sound' or 'randomize_sound'. No exclusions or comparative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect the synthesis parameters of the last generated sound. Returns detailed information about waveform type, frequency settings, envelope characteristics, and effects. Essential for understanding how sounds are constructed, reverse-engineering presets, or using existing sounds as starting points for modifications.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It describes the tool as inspecting and returning detailed parameter information, which implies a read-only operation with no side effects. It does not explicitly state mutability or preconditions (e.g., requiring a prior sound generation), but 'inspect the last generated sound' provides sufficient context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by return details and usage context. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description adequately summarizes return values (waveform type, frequency settings, envelope characteristics, effects). It covers the essential information for an agent to understand what the tool provides. With no params, the description is sufficiently complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage), so the description does not need to add parameter details. Baseline 4 is appropriate; the description adds no parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'inspect' and resource 'synthesis parameters of the last generated sound', and lists what it returns (waveform type, frequency settings, envelope characteristics, effects). It clearly distinguishes from sibling tools like create, export, list, mutate, randomize which are active or listing tools, whereas this is purely inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is 'essential for understanding how sounds are constructed, reverse-engineering presets, or using existing sounds as starting points for modifications', giving clear contexts for use. However, it does not explicitly mention when not to use or compare to alternatives like mutate_sound or list_presets, though the inspection vs. modification distinction is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available named sound presets with descriptions. These are precomputed configurations for specific sound effects like animal sounds, environmental effects, and more.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool lists presets but does not disclose any pagination behavior, ordering, or whether it requires authentication. For a simple list tool, the description is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two clear sentences with no redundant information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple listing function, the description is sufficiently complete. It explains what presets are and gives examples, though it could mention the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema description coverage is 100%. The description does not add parameter-level detail, which is appropriate since there are none. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists 'all available named sound presets with descriptions' and gives examples. However, it does not explicitly differentiate from the sibling tool 'list_presets', which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_presets' or 'generate_named_sound'. The description only implies basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Display all available built-in sound effect presets with descriptions. Shows the complete library of retro game sounds including pickup coins, laser weapons, explosions, powerups, hit effects, jump sounds, and UI elements.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It correctly indicates a read-only listing behavior, but could explicitly state it does not modify anything and is safe to call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading the purpose and providing concrete examples of returned sounds, zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully characterizes what the tool returns and its scope (built-in presets only). No gaps for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, baseline 4. Description adds value by specifying the output is a library of built-in presets with descriptions, beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Display' and resource 'built-in sound effect presets', lists examples of included sounds, and is distinct from sibling tools like list_named_presets which likely targets named presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage (to view library) but provides no when-to-use vs alternatives. Sibling tools exist for creating or mutating sounds, so explicit guidance would help selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available wave types (oscillator shapes) that can be used for sound generation. Each wave type produces a different tonal character - from clean sine waves to harsh noise.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool lists wave types and notes tonal character, but does not disclose behavioral traits like read-only nature, auth requirements, or side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with purpose. Highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could mention the return format (e.g., names, IDs) to be more complete. Currently adequate but lacking output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the baseline is 4. The description adds no param info, which is acceptable since there are no params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available wave types for sound generation, and explains tonal character. The name and description align perfectly, distinguishing it from sibling tools like create_custom_sound.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for sound generation but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mutate the current sound by slightly randomizing its parameters. Creates variations of the last generated sound while maintaining its general character. Great for creating sound families or finding interesting variations.
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes | Full path where to save the WAV file (including .wav extension) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully burdened. It discloses randomization effect and file saving, but does not clarify if in-place mutation occurs, what happens on file overwrite, or if return value exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with core action, no unnecessary words. Perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, description is mostly adequate but lacks details on side effects (e.g., does it change internal sound state?) and what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add extra meaning beyond what the schema states for the filepath parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool mutates the current sound by slightly randomizing parameters and creates variations while maintaining character. Implicitly differentiates from randomize_sound by emphasizing 'slightly', but does not explicitly distinguish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a use case ('creating sound families or finding interesting variations'), but no explicit when-to-use or when-not-to-use compared to sibling tools like randomize_sound.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate surprising and creative sound effects by randomizing all synthesis parameters. Perfect for discovering new sounds or creating unique audio textures. Use an optional seed value to make results reproducible for consistent random generation.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Optional seed for reproducible results | |
| filepath | Yes | Full path where to save the WAV file (including .wav extension) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that all synthesis parameters are randomized, and that an optional seed makes results reproducible. For a simple random generation tool, this is transparent and adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two clear, front-loaded sentences with no wasted words. Every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are only 2 parameters, no output schema, and no annotations, the description is fairly complete. It covers purpose, usage, parameter details (seed and filepath), and behavior. It lacks mention of return values, but no output schema is present, so it's not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema: it mentions the optional seed for reproducibility, which is already in the schema. The filepath parameter is sufficiently described in both.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates sound effects by randomizing all synthesis parameters. It uses a specific verb ('Generate') and resource ('sound effects'), and distinguishes it from siblings like create_custom_sound or mutate_sound by focusing on randomization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: 'Perfect for discovering new sounds or creating unique audio textures.' It implies when to use the tool, though it does not explicitly exclude cases or mention alternatives like mutate_sound.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.2.2create_custom_soundcreate_sound_with_waveexport_wavgenerate_named_soundgenerate_sound_effectget_parameterslist_named_presetslist_presetslist_wave_typesmutate_soundrandomize_soundScored across 11 tools
Each tool targets a distinct action: creating from presets vs. custom parameters, listing different resource types, mutating vs. randomizing, and exporting. No two tools have overlapping purposes; descriptions clearly differentiate them.
The naming follows snake_case with a consistent verb_noun pattern (e.g., list_presets, create_custom_sound). Minor variation like 'create_sound_with_wave' (prepositional phrase) is slightly inconsistent but still clear.
11 tools is well-scoped for a sound generation server: discovery (list presets, wave types), generation (custom, presets, named), manipulation (mutate, randomize), export, and inspection. No unnecessary tools.
Covers the core workflow: listing presets, generating from presets, custom creation, mutation, randomization, export, and parameter inspection. Missing a tool to save custom presets, but the surface is largely complete for retro sound effects.
Create, inspect, and manage Wubble music, speech, voice, and sound-effect requests through MCP.
MCP server for Producer/Riffusion AI music generation
Free CC0 sound effects for agents: ask by role (button-click, coin), sets, or search 4,600+.
Generate game assets with AI: sprites, 3D models, animations, sound effects, music, and voices.
