F
licenseNot graded
qualityB
maintenanceProvides local MCP tools to search and retrieve CC0 sound effects by keyword, category, duration, or ID, along with metadata, previews, and WAV/MP3 download URLs.
-
sounds
by com.sfxmint
Server Details
Free CC0 sound effects: search, roles and sets with no key; generate new ones with an API key.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 37 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.2/5.0
Scored across 6 tools
Disambiguation4/5
Three retrieval tools (search_sounds, get_role_sound, get_sound_set) overlap in purpose, but their descriptions explicitly distinguish when to use each ('use get_role_sound for one event, get_sound_set for multiple; search_sounds for descriptions or gaps'). get_sound (by slug), generate_sound, and get_generation are clearly distinct, so an agent can route reliably despite the retrieval overlap.
Naming Consistency5/5
All six names follow a consistent snake_case verb_noun pattern (generate_sound, get_generation, get_role_sound, get_sound, get_sound_set, search_sounds). No mixed conventions or vague verbs appear.
Tool Count5/5
Six tools is well-scoped for a sound-effect library: search, fetch-by-slug, fetch-by-role, fetch-a-set, generate, and poll-generation. Each earns its place with no redundant bulk.
Completeness4/5
The surface covers discovery (search_sounds), direct/role/set retrieval, AI generation, and async job polling, forming a full lifecycle. Minor gaps exist, such as no dedicated list/browse-roles tool (only an HTTP endpoint is mentioned) and no library-management operations.
Available Tools
16 toolsadd_kit_soundsInspect
Add the user's own list of sounds to a kit (an app's or a game's events: names, optional moments and lengths), or a ready set's events with its library sounds already in use. Names, keys, order and lengths stay the user's; SFXMint writes how each sounds. Without kit_id it starts a new kit for the list. Free (no generation). Then call fill_kit_from_library to use free library sounds first, and make only the gaps.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| set | No | Instead of sounds: a ready set's id from get_sound_set (its events, with its library sounds in use). | |
| name | No | A new kit's name (optional). | |
| kit_id | No | Add to this kit (kit_…); leave out to start a new kit. | |
| sounds | No | The sounds, in the user's order. |
export_game_kitInspect
What to put in the project: every included sound's event key and the take in use (file link valid 15 minutes, SHA-256), the sounds not ready yet, and zip_url for one ZIP (download it with the same Authorization header) holding the files in the chosen format, sounds.json (event key → file) and a README. Wire the game's events to sounds.json and let the user check the sounds in the game.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | File type in the ZIP (default wav). | |
| kit_id | Yes | The kit id from start_game_kit or add_kit_sounds (kit_…). |
fill_kit_from_libraryInspect
Fill a kit's sounds from the free CC0 library first: each sound without a take is searched by its name and length, and a full match becomes its take in use, free. Answers what matched (let the user listen), the nearest sounds for others (use_library_sound to use one) and the gaps to make with make_kit_sounds.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kit_id | Yes | The kit id from start_game_kit or add_kit_sounds (kit_…). | |
| sound_ids | No | Only these sounds (default: every sound without a take). |
find_kit_sound_candidatesInspect
Up to five free library sounds for one kit sound, by its name or your own words, with their length, character and a listening URL. Nothing changes until use_library_sound.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Other words to search with (optional). | |
| kit_id | Yes | The kit id from start_game_kit or add_kit_sounds (kit_…). | |
| sound_id | Yes | A sound id from get_game_kit (ks_…). |
generate_soundInspect
Make a new sound effect from a description when the library has nothing suitable (search_sounds has no full match and its closest sounds do not suit; it then returns generate_available). Needs an SFXMint API key; free: 3 generations a day per account (50 to 200 with a plan), each up to 4 CC0 WAV takes of up to 10 s; one that makes no take does not count. Returns CC0 WAV files (signed links valid 15 minutes) with SHA-256 and seed; if they are not ready within about 25 seconds, it returns the order id for get_generation. AI-generated: the user should listen before use.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | One sound, in plain English: what makes it, what it does and how it develops, e.g. 'a heavy wooden door slams shut and rattles in its frame' or 'three bright notes rise quickly, then a soft sparkle'. Name what is heard, not what it is for. Write only what should be heard: the model reads 'no thunder' as thunder. Leave out lengths (use duration_s) and 'sound effect'; add a place (large hall, distant, outdoors) when it matters. For a one- or two-word idea, another language or words that exclude something, set enhance. The model's weak spots: ${weakSpotGuide()}. | |
| enhance | No | Let SFXMint write the prompt into a full sound description first, as the website's AI Enhance does: a short idea ('coin', 'level complete'), another language, or words that leave something out. Default false: the prompt goes to the model exactly as written. The result gives the description it used. | |
| duration_s | No | Longest length in seconds. Leave it out and SFXMint chooses from the description; either way the silence before and after the sound is cut, so a take can be shorter | |
| variations | No | How many takes to make (default 4; one generation either way) |
get_game_kitInspect
A Game kit's state: its scenes, its sounds (event key, when it plays, status, the takes made with short-lived file links, SHA-256 and length, and the take in use), how its makes are paid (the account's free generations of the day, or its plan's) and next_step. Needs the API key that started the kit.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kit_id | Yes | The kit id from start_game_kit or add_kit_sounds (kit_…). |
get_generationAInspect
Check a generation started with generate_sound: status, and fresh download links for the finished takes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two useful traits: it returns status and 'fresh' download links, implying links are regenerated per call rather than cached. However, it omits error/failure states, whether completed takes persist, and any polling-timing behavior, so disclosure is partial.
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?
A single tight sentence that front-loads the action and resource with zero filler. The colon-delimited return summary is efficiently packed rather than padded.
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 one-parameter polling tool with no output schema, the description covers what the agent gets back (status and download links), which is the key unknown. It falls short only on polling cadence and failure-state behavior, which are minor for a simple status-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter order_id is undocumented in both schema and description. The description partially compensates by implying the id originates from generate_sound ('a generation started with generate_sound'), but gives no format, source field, or validity details.
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?
States a specific verb (check) and resource (a generation started with generate_sound) and names what it returns: status plus download links for finished takes. This clearly ties it to the generate_sound sibling, though it does not explicitly distinguish itself from the other sound-retrieval siblings like get_sound or get_role_sound.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this is the follow-up call after generate_sound to poll a generation. There is no explicit when-to-use statement, no guidance on how soon or how often to poll, and no stated alternative or when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_role_soundAInspect
Choose this when the task calls for a sound for a named event or interaction — a button click, purchase success, error beep, level-up, dialogue blip, notification. Pass the role as plain words: role ids (click, success, purchase-success, dialogue-blip, notification…) and common aliases (button click, ka-ching, jump scare, text blip…) are all accepted. Returns a qualified candidate for that role when one satisfies the requested constraints, with MP3/WAV URLs, 2-3 alternates and the family page for browsing more. Five core game roles include content_check (verified/unverified/rejected), scoped to scene, role, format and exact file SHA256; unverified previews are not certified suitable. Download selected files locally and retain originals. Task-permitted processing requires a recipe, output SHA256, renewed file checks and a listening check; changed bytes do not inherit content review. Other task-permitted sources or local synthesis may be mixed in. Optional style: crisp (short, bright, dry), soft (darker, gentler), spacious (reverb, longer tail), balanced (default: most typical). For multiple events consider get_sound_set; use search_sounds for a description or a gap. These are task branches, not a fixed sequence. Unknown roles return not_found with the full role list; GET https://sfxmint.com/api/v1/roles lists roles with aliases.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| loop | No | Require prepared loop metadata; seam evidence is returned separately. | |
| role | Yes | Role id or alias, e.g. 'click', 'button click', 'purchase-success', 'ka-ching', 'error beep', 'level-up', 'dialogue blip', 'notification' | |
| style | No | Optional. balanced (default) = the family's most typical take; crisp = short, bright, dry; soft = darker, gentler; spacious = reverb, longer tail | |
| format | No | ||
| max_duration_ms | No | Hard maximum delivered duration in milliseconds. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so richly: it discloses return contents (URLs, alternates, family page), content-check scoping and certification limits, local download expectations, processing constraints including SHA256 and listening checks, handling of changed bytes, behavior for unknown roles, and a roles-list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely informative and well front-loaded with the primary usage guidance. Some sections, such as the content_check and processing details, add complexity but are relevant to safe and correct invocation. It earns a 4 rather than 5 because the density could make it harder to scan quickly.
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?
Given five parameters, no annotations, and no output schema, the description covers what the tool returns, failure modes, parameter interpretation, alternatives, and important processing constraints. An agent has enough information to select and invoke the tool correctly in most scenarios.
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 80%, so the baseline is 3. The description adds meaningful semantics beyond the schema for the role parameter (accepts aliases, examples, not_found behavior) and the style parameter (defines crisp/soft/spacious/balanced). It does not add much for loop, format, or max_duration, but those are adequately described in the schema.
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 description opens with a specific use case—retrieving a sound for a named event or interaction—and lists concrete examples. It clearly distinguishes this tool from siblings by explicitly naming get_sound_set and search_sounds as alternatives for different tasks.
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?
The description states exactly when to choose this tool ('Choose this when the task calls for a sound for a named event') and when to prefer alternatives ('For multiple events consider get_sound_set; use search_sounds for a description or a gap'). It even notes that these are task branches, not a fixed sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_soundAInspect
Get full metadata for one sound by slug, including download URLs, description and measured acoustics (attack/tail/brightness + character labels).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Sound slug, e.g. 'impact-punch-01' |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal the return contents (download URLs, description, acoustics) but does not mention error behavior, authentication needs, or whether the operation is read-only. For a simple get, this is adequate but not fully transparent.
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?
A single sentence that front-loads the action and scope ('Get full metadata for one sound by slug') followed by a compact list of return fields. Every word earns its place; no filler or repetition.
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 one-parameter read tool with no output schema, the description covers the essential invocation context: what to pass (slug), what you get back (metadata fields), and the scope (one sound). It lacks explicit error handling or how to obtain a slug, but those are minor for this simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (slug is described with an example), so the schema already explains the parameter. The description adds only that the slug identifies the sound whose metadata is fetched, which is marginal value beyond the structured data. Baseline 3 applies.
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 description uses a specific verb ('Get') and resource ('full metadata for one sound by slug'), clearly distinguishing it from siblings like search_sounds (searching) and get_sound_set (multiple sounds). It also enumerates the key contents (download URLs, description, acoustics), leaving no ambiguity about what the tool does.
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?
The description clearly implies the use case: when you have a sound slug and need full metadata. It does not explicitly name alternatives or state when not to use this tool, but the 'by slug' phrasing gives enough context for an agent to infer the appropriate trigger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sound_setAInspect
Get a coherent set of sounds for an app or game in one call — one sound per role, with format metadata, hashes and stable download URLs. Use it when the task needs a whole kit; use get_role_sound for one event. Check content_check: verified/unverified/rejected is bound to the exact role, format and file SHA256; unverified files still require listening in context. Sets include UI styles, game and app scenarios, acoustic-drum-kit, animal-calls (15 isolated calls), and dungeon-traps (6 isolated mechanisms).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| set | No | Set id (default ui-crisp). Includes acoustic-drum-kit, animal-calls and dungeon-traps alongside the UI and scenario sets listed in the enum. | |
| format | No | File format for selection and checks (default WAV). Legacy urls remains MP3; download_urls follows this format. |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It reveals key behaviors: one sound per role, format metadata, hashes, stable download URLs, and the meaning of content_check states including the warning that unverified files still require listening in context. Minor behavioral details such as side effects or permissions are not stated, but the description is strong for a read-style retrieval tool.
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?
The description is compact and front-loaded: core purpose, usage guidance, safety caveat, and set inventory in four sentences. Every sentence contributes useful information, and no filler or repetition exists.
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 two-parameter tool with no output schema, the description is sufficiently complete. It explains what the response contains, when to use the tool, how to interpret content verification, and which specialized sets are available. The enum in the schema already lists set ids, and the description adds the missing counts for animal-calls and dungeon-traps.
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 100% and both parameters have enum descriptions, so the baseline is 3. The description adds extra meaning by explaining that the result includes format metadata and that content_check is bound to role, format, and SHA256, which clarifies how the format parameter affects validation and output. This goes beyond the bare schema definitions.
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 description states a clear, specific action: 'Get a coherent set of sounds for an app or game in one call — one sound per role.' It also distinguishes this tool from get_role_sound by explicitly framing set retrieval versus single-event retrieval, so an agent can differentiate siblings without opening schemas.
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?
The description gives explicit usage direction: 'Use it when the task needs a whole kit; use get_role_sound for one event.' It also provides a practical caution about content_check and unverified files, which helps the agent decide when and how to apply the result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_kit_soundsInspect
List the sounds of a Game kit's scenes, free: after start_game_kit planned the scenes, show them to the user, then call this with the scenes to keep (all by default; the others are switched off). Call get_game_kit after about 15 seconds.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kit_id | Yes | The kit id from start_game_kit or add_kit_sounds (kit_…). | |
| scene_ids | No | Scene ids to list (default: every scene). |
make_kit_soundsInspect
Make sounds in a Game kit: each sound gets up to four takes, and each sound made is one generation. Each uses one of the account's generations of the day, shared with generate_sound: 3 free, or its plan's. Nothing is charged. When none is left it answers with plans_url: the user chooses a plan on that page (from $9.90 for 30 days: 50 to 200 generations a day for the whole account), never the agent.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kit_id | Yes | The kit id from start_game_kit or add_kit_sounds (kit_…). | |
| sound_ids | No | Sounds to make or remake (default: every listed sound not made yet). |
pick_kit_takeInspect
Use one of a sound's takes in the kit (the first take is used until the user picks). Let the user listen to the takes first.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kit_id | Yes | The kit id from start_game_kit or add_kit_sounds (kit_…). | |
| take_id | Yes | ||
| sound_id | Yes |
search_soundsInspect
Free-text search over the SFXMint library of free CC0 sound effects. Use it for sound descriptions, additional constraints or gaps left by another tool. Choose get_role_sound for a named event or get_sound_set for multiple events when that fits the task; these are task branches, not a fixed sequence. Hard constraints (duration, loop, format, excluded words) always apply. results hold sounds whose text has every word of the query. When there are none, closest lists the nearest sounds that meet every hard constraint, best first, each with missing_terms: judge them from title and description and let the user listen. library_fit says how well the library covers the request (full, close, weak, none); anything short of full also returns generation options. Returns direct, hotlinkable MP3/WAV URLs and verified OGG (Vorbis) URLs where available — no API key, no attribution required — plus measured acoustics (attack_ms, tail_ms, centroid_hz), character labels like 'bright · punchy · tight', loop/file-QC status, and score/match as ranking evidence only (role = known role default, exact = all words hit, partial = some words hit, semantic = nearest by meaning).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| loop | No | Require (true) or exclude (false) a candidate marked with prepared loop metadata; seam evidence is returned separately. | |
| limit | No | Max results (default 20, max 50) | |
| query | Yes | Keywords or a natural-language description, e.g. 'door slam', 'soft UI confirmation chime', 'coin pickup' | |
| format | No | Delivery format (ogg = Ogg Vorbis); loop=true defaults to WAV when omitted. | |
| category | No | Optional category slug: ui, retro-game, transition, impact, ambience, water, fire-electric, footsteps, door, mechanical, paper-fabric, glass, animal, crowd, cartoon, magic-scifi, horror, feedback, instrument, office, human, vehicle, household | |
| max_duration_ms | No | Hard maximum delivered duration in milliseconds; format-specific measurement is required. |
start_game_kitInspect
Start a Game kit: SFXMint plans the sounds one game needs and makes them as CC0 takes to pick from — the same project the user sees on the website. Use it when the user wants sounds for a whole game or scene and the library (get_sound_set, get_role_sound) does not cover them. Needs an SFXMint API key. Planning and listing are free; each sound made uses one of the account's generations of the day: 3 free, or its plan's (from $9.90 for 30 days: 50 to 200 generations a day for the whole account), which the user buys in the browser (see get_game_kit). Returns kit_id and kit_url; call get_game_kit after about 15 seconds.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| feel | No | How the sounds should feel (optional). | |
| game | Yes | What the game is and what the player does, in a few sentences (genre, setting, main actions). For one scene, what happens in it. | |
| avoid | No | What the sounds should leave out, e.g. 'voices, music' (optional). | |
| feel_text | No | More words on the feel, e.g. 'soft, warm' (optional). | |
| one_scene | No | true: list 3–6 sounds for one scene at once; making them uses free generations like generate_sound. Default false: plan the whole game's scenes first. |
use_library_soundInspect
Use a library sound (its slug) as a take of a kit sound, free. It becomes the take in use when the sound has none; otherwise it waits beside the others for the user to compare.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The library sound's slug. | |
| kit_id | Yes | The kit id from start_game_kit or add_kit_sounds (kit_…). | |
| sound_id | Yes | A sound id from get_game_kit (ks_…). |
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
9 tool updates
- Added
add_kit_sounds - Changed
export_game_kit1 field changed- changed
Input schema / properties / kit_id / descriptionPrevious value: -"The kit id from start_game_kit (kit_…)."New value: +"The kit id from start_game_kit or add_kit_sounds (kit_…)."
- Added
fill_kit_from_library - Added
find_kit_sound_candidates - Changed
get_game_kit1 field changed- changed
Input schema / properties / kit_id / descriptionPrevious value: -"The kit id from start_game_kit (kit_…)."New value: +"The kit id from start_game_kit or add_kit_sounds (kit_…)."
- Changed
list_kit_sounds1 field changed- changed
Input schema / properties / kit_id / descriptionPrevious value: -"The kit id from start_game_kit (kit_…)."New value: +"The kit id from start_game_kit or add_kit_sounds (kit_…)."
- Changed
make_kit_sounds1 field changed- changed
Input schema / properties / kit_id / descriptionPrevious value: -"The kit id from start_game_kit (kit_…)."New value: +"The kit id from start_game_kit or add_kit_sounds (kit_…)."
- Changed
pick_kit_take1 field changed- changed
Input schema / properties / kit_id / descriptionPrevious value: -"The kit id from start_game_kit (kit_…)."New value: +"The kit id from start_game_kit or add_kit_sounds (kit_…)."
- Added
use_library_sound
1 tool update
- Changed
generate_sound1 field changed- changed
Input schema / properties / prompt / descriptionPrevious value: -"One sound, in plain English: what makes it, what it does and how it develops, e.g. 'a heavy wooden door slams shut and rattles in its frame' or 'three bright notes rise quickly, then a soft sparkle'. Name what is heard, not what it is for. Write only what should be heard: the model reads 'no thunder' as thunder. Leave out lengths (use duration_s) and 'sound effect'; add a place (large hall, distant, outdoors) when it matters. For a one- or two-word idea, another language or words that exclude something, set enhance."New value: +"One sound, in plain English: what makes it, what it does and how it develops, e.g. 'a heavy wooden door slams shut and rattles in its frame' or 'three bright notes rise quickly, then a soft sparkle'. Name what is heard, not what it is for. Write only what should be heard: the model reads 'no thunder' as thunder. Leave out lengths (use duration_s) and 'sound effect'; add a place (large hall, distant, outdoors) when it matters. For a one- or two-word idea, another language or words that exclude something, set enhance. The model's weak spots: ${weakSpotGuide()}."
3 tool updates
- Changed
generate_sound1 field changed- changed
Input schema / properties / variations / descriptionPrevious value: -"How many takes to make (default 4; the price is the same)"New value: +"How many takes to make (default 4; one generation either way)"
- Changed
make_kit_sounds2 fields changed- removed
Input schema / properties / confirm_creditsRemoved value: -{ - "description": "The credits the user agreed to spend, as quoted by the previous call.", - "type": "number" -} - removed
Input schema / properties / use_creditsRemoved value: -{ - "description": "Explicitly use credits instead of an active Kit daily allowance. Requires confirm_credits after the quoted cost is accepted; never enable automatically.", - "type": "boolean" -}
- Changed
start_game_kit1 field changed- changed
Input schema / properties / one_scene / descriptionPrevious value: -"true: list 3–6 sounds for one scene at once, priced in credits like generate_sound. Default false: plan the whole game's scenes first."New value: +"true: list 3–6 sounds for one scene at once; making them uses free generations like generate_sound. Default false: plan the whole game's scenes first."
1 tool update
- Changed
generate_sound1 field changed- changed
Input schema / properties / enhance / descriptionPrevious value: -"Let SFXMint rewrite a short or unclear idea ('coin', 'level complete') into a full sound description first; a clear description still goes as written (default false: the prompt is used as written). The result gives the rewrite it used, if any."New value: +"Let SFXMint write the prompt into a full sound description first, as the website's AI Enhance does: a short idea ('coin', 'level complete'), another language, or words that leave something out. Default false: the prompt goes to the model exactly as written. The result gives the description it used."
1 tool update
- Changed
generate_sound1 field changed- changed
Input schema / properties / prompt / descriptionPrevious value: -"One sound, in English: a short noun phrase that ends with the sound itself, e.g. 'heavy wooden door slam' or 'bright rising three-note chime'. Name what is heard, not what it is for; leave out no/not/without, lengths (use duration_s) and 'sound effect'. Add a place (large hall, distant, outdoors) only when it matters. For a one- or two-word idea, set enhance."New value: +"One sound, in plain English: what makes it, what it does and how it develops, e.g. 'a heavy wooden door slams shut and rattles in its frame' or 'three bright notes rise quickly, then a soft sparkle'. Name what is heard, not what it is for. Write only what should be heard: the model reads 'no thunder' as thunder. Leave out lengths (use duration_s) and 'sound effect'; add a place (large hall, distant, outdoors) when it matters. For a one- or two-word idea, another language or words that exclude something, set enhance."
1 tool update
- Changed
make_kit_sounds1 field changed- added
Input schema / properties / use_creditsAdded value: +{ + "description": "Explicitly use credits instead of an active Kit daily allowance. Requires confirm_credits after the quoted cost is accepted; never enable automatically.", + "type": "boolean" +}
6 tool updates
- Added
export_game_kit - Added
get_game_kit - Added
list_kit_sounds - Added
make_kit_sounds - Added
pick_kit_take - Added
start_game_kit
2 tool updates
- Added
generate_sound - Added
get_generation
1 tool update
- Changed
search_sounds1 field changed- changed
Input schema / properties / category / descriptionPrevious value: -"Optional category slug: ui, retro-game, transition, impact, ambience, water, fire-electric, footsteps, door, mechanical, paper-fabric, glass, animal, crowd, cartoon, magic-scifi, horror, feedback, instrument, office"New value: +"Optional category slug: ui, retro-game, transition, impact, ambience, water, fire-electric, footsteps, door, mechanical, paper-fabric, glass, animal, crowd, cartoon, magic-scifi, horror, feedback, instrument, office, human, vehicle, household"
1 tool update
- Changed
get_role_sound1 field changed- changed
Input schema / properties / role / descriptionPrevious value: -"Role id or alias, e.g. 'click', 'button click', 'purchase-success', 'ka-ching', 'error beep', 'level-up', 'dialogue blip', 'rain-loop'"New value: +"Role id or alias, e.g. 'click', 'button click', 'purchase-success', 'ka-ching', 'error beep', 'level-up', 'dialogue blip', 'notification'"
1 tool update
- Removed
get_job
Related MCP Connectors
CC0 sound effects API for AI agents — search, preview, and download via MCP.
Audio for your agent: transcribe, speak, translate, summarise, plus sound effects and music.
Free, copyright-safe AI music library for video creators and AI agents.
Generate, edit and stream royalty-free music, or search a licensed catalogue.
Related MCP Servers
- AlicenseAqualityCmaintenanceGenerates music and sound effects using Bfxr2, with preset or custom parameter control.1112 npm2MIT
- AlicenseNot gradedqualityCmaintenanceEnables local generation of game sound effects from text prompts using Stability AI's Stable Audio Open model, with no API keys or per-generation cost.1MIT
- AlicenseBqualityDmaintenanceEnables searching and downloading audio samples from Freesound using keywords, filters, and sound IDs. It provides detailed sound metadata including duration, license information, and preview URLs.217 npm1MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.