Free CC0 sound effects for apps and games: roles, sets, search; 20 keyless downloads a day; make one
Scored across 10 tools
Most tools have clearly distinct purposes: generation variants are explicitly split by sound type, retrieval tools are differentiated by single metadata, role-based selection, or set selection, and change_sound is scoped to modifying an existing take. A few boundaries, such as get_role_sound versus get_sound_set versus search_sounds, require reading the descriptions, but they are still workable.
The tool set mostly follows a predictable snake_case verb_noun pattern: change_sound, generate_*, get_*, search_sounds. The only notable deviation is studio_list_link, which is readable but does not match the dominant verb-first convention.
Ten tools is well within a reasonable scope for a sound-library and generation server. Each tool covers a distinct operation: search, metadata retrieval, role/set selection, generation, modification, polling, and missing-sound linking.
The surface covers the core sound workflow end to end: discover via search or roles, inspect metadata, generate new sounds or ambience/music, modify existing takes, poll generation status, and create a Studio link for missing sounds. No obvious lifecycle gap or dead end is apparent.
Change one take of a generation this account made, from the take itself: say what is off in the user's words (change, any language) or name the action. Three versions come back (a light, medium and strong change; for a loop, three seams) as CC0 WAV files. Free: no generation is used and no plan is needed. When the words ask for a different sound rather than a change to this one, it answers no_action with a description to pass to generate_sound. The user should listen and pick one.
| Name | Required | Description | Default |
|---|---|---|---|
| take | Yes | Which of its takes (index, 1-4), finished | |
| action | No | crisper: too muddy; heavier: too light; shorter_tail: rings on too long; longer_tail: stops too abruptly; room: too dry; far: too close; loop: make it loop | |
| change | No | What is off, in the user's words: 'too muddy', 'make it loop', 'sounds too close' | |
| order_id | Yes | The generation, from generate_sound or get_generation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (which only say readOnlyHint=false, destructiveHint=false, openWorldHint=false) by disclosing that output is three CC0 WAV variants (light/medium/strong, or three loop seams), that the call is free with no generation or plan consumed, and that the no_action response carries a payload for generate_sound. It also tells the caller the user must audition and pick one, which affects downstream flow.
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?
Front-loaded with the core verb and scope, then layered with the no_action fallback and the free/no-plan note. It is dense and the parenthetical about light/medium/strong and loop seams packs a lot into one clause, but no sentence is filler.
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?
There is no output schema, and the description compensates by explaining exactly what comes back — three WAV files of varying strength, or three seam variants for loops — plus the special no_action outcome. Combined with the 100% schema coverage on inputs, an agent has everything needed to call and interpret it.
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 the baseline is 3, but the description adds real semantics the schema does not: it clarifies that 'change' and 'action' are alternative ways to express the same request rather than both being needed, and that free text may be in any language. It also explains the three-variant output per change, which gives meaning to the take index.
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?
States a specific verb and resource — change one take of a generation this account made — and scopes the input to 'from the take itself.' It also distinguishes itself from the sibling generate_sound by describing the no_action routing, so an agent can tell the two apart without opening either schema.
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 gives two ways to invoke (free-text 'change' in any language, or a named action) and states the exclusion condition: when the user wants a different sound rather than a modification of this one, the tool returns no_action with a description to pass to generate_sound. That names the alternative and the condition that selects it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a continuous environmental sound bed such as rain, waves, a forest or a crowd, not a musical track or an isolated event. Makes 30-second CC0 WAV takes and attempts seamless loops. Needs an SFXMint API key and credits or a plan; sound-effect free tries do not apply. Missing access returns website_url for Studio Ambience; payment_required also returns buy_url. Returns order_id, files and loop_url when available; if pending after about 25 seconds, poll get_generation. Listen in context before use.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | With enhance=false, describe the audible environment in plain English, at most 400 characters. Name the place and continuous sound bed, its intensity, texture and pace; include occasional events, their spacing and distance only when requested or established by context. Keep it steady and repeatable. Example: 'Gentle ocean waves wash onto a sandy beach and recede at a steady pace, with soft foamy hiss and a low rolling wash.' Preserve the user's sources and spatial details; omit excluded sounds entirely rather than listing 'no music' or 'without voices'. Avoid metaphors that introduce other sources. The server adds the SFX tag and continuous-ambience instruction. With enhance=true, a brief in any language is enough. | |
| enhance | No | Default false. Write final English using this tool's prompt guidance to skip server AI rewriting. True asks the corresponding ambience or music writer to adapt a brief in any language; enhanced_prompt reports the result. Non-Latin input may still require server translation with false. | |
| duration_s | No | Take length, fixed at 30 seconds; omit or pass 30. A returned loop may be shorter. A loop is not guaranteed: inspect loop_cut and loop_url. | |
| variations | No | How many takes to make (default 4; one generation either way) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses the API key/credits/plan prerequisite, that free tries don't apply, the fallback responses (website_url, buy_url on payment_required), the ~25-second pending window and get_generation polling, the 30-second CC0 WAV constraint, and that loops are only attempted and not guaranteed (inspect loop_cut/loop_url). This is exactly the operational context annotations can't carry.
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?
Purpose is front-loaded in the first sentence, followed by prerequisites, return values and polling guidance. It is dense with clauses and a bit telegraphic, but nearly every clause conveys actionable 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?
With no output schema, the description shoulders return-value disclosure and does so (order_id, files, loop_url, pending polling). Combined with auth requirements and the loop-not-guaranteed caveat, an agent has everything needed to call and interpret results.
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 each parameter is already fully documented in the schema, setting the baseline at 3. The description corroborates the 30-second take length and the returns, but adds no parameter meaning that isn't already in the rich schema descriptions.
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?
States a specific verb+resource ('Make a continuous environmental sound bed') and immediately excludes the wrong categories ('not a musical track or an isolated event'), which is exactly the distinction needed against siblings like generate_music and generate_sound. An agent can tell what this produces without opening the schema.
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 exclusions ('not a musical track or an isolated event') and the 'listen in context before use' guidance give clear context for when this tool applies, and it routes to get_generation for pending jobs. It stops short of naming the sibling tools to use instead for music or one-shot SFX, leaving that inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make instrumental background music (BGM), including ambient music, for an app or game; for environmental sounds use generate_ambience. Makes 30-second CC0 WAV takes and attempts to extract repeating musical loops. Needs an SFXMint API key and credits or a plan; sound-effect free tries do not apply. Missing access returns website_url for Studio BGM; payment_required also returns buy_url. Returns order_id, files and loop_url when available; if pending after about 25 seconds, poll get_generation. Supports instrumental music, not intelligible vocals or lyrics; clarify a vocal request with the user instead of silently substituting. Listen in context before use.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | With enhance=false, write a plain English instrumental music description, at most 400 characters, usually 1-3 sentences. State the genre, instruments and what they play, mood, energy and tempo (BPM if specified). Preserve named genres, instruments and pace; choose compatible instrumentation only when the brief leaves it open. Describe a repeating motif and steady accompaniment suitable for a background loop. Example: 'A calm fantasy instrumental loop at 80 BPM, with gentle harp arpeggios, warm sustained strings and a simple flute melody, keeping a steady, hopeful mood.' Use positive audible terms; omit unwanted sources instead of naming them in exclusions. Avoid artist, song or game names, lyrics and the 'TrackType: SFX' tag. With enhance=true, give the musical brief in any language and the music writer adapts it. | |
| enhance | No | Default false. Write final English using this tool's prompt guidance to skip server AI rewriting. True asks the corresponding ambience or music writer to adapt a brief in any language; enhanced_prompt reports the result. Non-Latin input may still require server translation with false. | |
| duration_s | No | Take length, fixed at 30 seconds; omit or pass 30. A returned loop may be shorter. A loop is not guaranteed: inspect loop_cut and loop_url. | |
| variations | No | How many takes to make (default 4; one generation either way) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic write/no-destroy profile; the description adds substantial beyond-schema behavior: 30-second CC0 WAV takes, best-effort loop extraction, missing-access returns website_url via studio_list_link patterns, payment_required returns buy_url, and the ~25s pending threshold. That is exactly the operational context an agent needs to avoid a failed call loop.
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?
Front-loaded with purpose and the sibling boundary, and every clause carries actionable information (access, return shape, polling, vocal limitation). It is dense with semicolon-joined clauses, making it slightly harder to scan than a bulleted equivalent.
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, yet the description names the returned fields (order_id, files, loop_url, enhanced_prompt, loop_cut) and the async polling path. Combined with auth/credit prerequisites and the instrumental-only constraint, an agent has everything needed to call it and handle outcomes.
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 each parameter already carries rich, self-contained guidance (prompt crafting, enhance semantics, fixed 30s duration, variations enum). The description adds little parameter-level detail beyond the fixed 30-second take and loop caveat, so baseline 3 is appropriate.
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?
States a specific verb and resource (make instrumental background music, including ambient music, for apps/games) and immediately names the sibling boundary: environmental sounds belong to generate_ambience. It also rules out a whole category (intelligible vocals/lyrics), so an agent can distinguish it from generate_sound and generate_ambience without opening a schema.
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?
Explicit routing: use generate_ambience for environmental sounds, poll get_generation if pending after ~25 seconds, and clarify a vocal request with the user rather than silently substituting. It also states the access precondition (API key + credits or plan; sound-effect free tries do not apply).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an individual 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). For continuous environmental beds or instrumental background music, use generate_ambience or generate_music when offered. Needs an SFXMint API key and uses the account's 1 free try first, then credits or a plan on the account — a credit pack ($3.90 for 10 credits or $9.90 for 30, never expiring) or the unlimited plan ($19.90 for 30 days, unlimited sounds) — each up to 4 CC0 WAV takes of up to 10 s (with an OGG of each when credits or a plan made it); one that makes no take does not count; with neither it answers payment_required with buy_url and website_url (the website's page where the user can make it and hear it first). Returns CC0 WAV files (signed links valid 15 minutes) with SHA-256 and seed, and ogg_url (Ogg Vorbis, made from the WAV on its first request) for takes made with credits or a plan; 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.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | For enhance=false, write the final audible description in plain English, usually 1-3 sentences, at most 400 characters. Start with 'TrackType: SFX,'. Name the source, action and relevant material; preserve requested count, intensity, pace and how the sound starts, develops and ends. Translate a use such as 'success' into the intended audible event, e.g. 'TrackType: SFX, three bright electronic tones rise in pitch, each fading quickly.' Preserve an explicitly requested sound: a confirmation click stays a click. Mention only sounds to be heard; omit excluded sounds entirely instead of writing 'no music' or 'without speech'. Avoid brands, character names and metaphors that name unwanted sources. Add perspective, environment or timbre only when requested or established by context; do not invent extra events. Keep simple sounds short. Put total length in duration_s. For enhance=true, a plain-language brief in any language is enough; SFXMint writes the model description. | |
| enhance | No | Default false. Prefer false when you can write the final English sound description using the prompt guidance: it skips the server AI rewrite. True asks SFXMint to expand or adapt a brief, as the website's AI Enhance does; the result includes enhanced_prompt. With false, non-Latin text may still trigger server translation, so write English to avoid that extra call. Neither setting guarantees audio quality; listen to the takes. | |
| 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) | |
| variations_of | No | A variation set instead of a new sound: four takes started from one finished take of this account's generation, close to it, for a game to play at random so the sound does not repeat (footsteps, hits, shots). The result adds engine files (a Godot AudioStreamRandomizer .tres and a Unity script) to save beside the WAVs. Uses one generation; prompt then only names the set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare write/non-open-world, so the description carries most of the burden and does add real value: API key requirement, the free-try-then-credits flow, the payment_required response with buy_url, and the 15-minute signed-link lifetime. However it buries pricing minutiae ('$3.90 for 10 credits or $9.90 for 30, never expiring... $19.90 for 30 days') that is commercial noise rather than behavior an agent needs to plan a call, and it doesn't state rate limits or whether a failed generation consumes credits beyond the one-line 'one that makes no take does not count'.
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?
Front-loading is good — the core purpose and the sibling routing come first. But the body is a single ~230-word run-on with heavy em-dash and parenthetical chaining, and the credit-pack pricing sentence (
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?
placeholder
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 the prompt guidance is already exhaustively documented in the schema, so baseline 3 applies. The description adds only marginal parameter-level meaning ('each up to 4 CC0 WAV takes of up to 10 s', 'Uses one generation' for variations_of), which duplicates rather than extends what the schema already says.
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?
States a specific verb and resource ('Make an individual sound effect from a description') and immediately bounds the scope against the retrieval path ('when the library has nothing suitable... search_sounds has no full match... returns generate_available'). It also names the two siblings that cover the adjacent cases (generate_ambience, generate_music), so an agent can route without opening a schema.
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?
Gives an explicit precondition for use (search failed and closest sounds don't suit), explicit exclusions routed to alternatives (continuous environmental beds → generate_ambience, instrumental background music → generate_music), and a fallback path (get_generation when takes exceed ~25s). Nothing about when-to-use 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.
Check a generation started with generate_sound, generate_ambience, generate_music or change_sound: status, kind and fresh download links for the finished takes, including loop_url when a loop was made.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The order_id returned by generate_sound, generate_ambience, generate_music or change_sound |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the description is free to add value — and it does, by disclosing the return surface: status, kind, fresh download links, and loop_url only when a loop was produced. The word 'fresh' usefully signals that links are re-issued and may not be durable, though it does not spell out expiry or polling cadence.
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?
One dense but well-ordered sentence: the trigger condition comes first, the returned fields second. Every clause carries information, though the trailing enumeration of four generator names and three output fields makes it slightly list-like rather than maximally scannable.
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 annotations handling safety and no output schema, the description steps in to describe the response shape, which is exactly the gap that needed filling for a single-parameter polling tool. Minor omissions remain — no indication of what status values mean or whether the agent should retry while the job is pending.
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?
There is a single parameter with 100% schema description coverage, and the schema already states that order_id comes from the four generation tools. The description restates the same provenance rather than adding anything new (e.g., format, whether IDs expire, or what happens with an unknown ID), so 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?
Specific verb ('check') plus resource ('a generation') with the exact provenance chain named (generate_sound, generate_ambience, generate_music, change_sound). An agent can immediately tell this is the polling/status tool for jobs created by the generate_* family, distinct from get_sound/get_sound_set.
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 clearly establishes the usage context: it is the follow-up to one of the four generation tools, so the agent knows to call it after starting a job. It does not, however, state any exclusions or point to alternatives (e.g., when to use get_sound instead of polling a generation), so it stops short of a full when/when-not treatment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. Download selected files locally and retain originals. Task-permitted processing requires a recipe, output SHA256, renewed file checks and a listening check. 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.
| 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 | Delivery format the candidate must have (ogg = Ogg Vorbis, only sounds published before 2026-10-14 have it); default MP3 and WAV URLs. | |
| max_duration_ms | No | Hard maximum length of the sound in milliseconds: a file may run longer with near-silence after the sound (audible_ms is the sound, duration_ms the file; checks say which was met). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare a safe read operation, the description adds substantial context beyond them: return shape (candidate plus 2-3 alternates and family page URL), unknown-role failure mode (not_found with role list), local download/processing requirements (recipe, SHA256, renewed checks, listening check), and the roles API endpoint. This is rich behavioral disclosure.
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 usage guidance and role examples are front-loaded and every sentence carries information, but the paragraph is dense and long, with download/processing details that could be trimmed. Front-loading is strong, minor verbosity costs a point.
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?
For a read tool with no output schema, the description sufficiently covers return values, error behavior, format and style options, and the local-download/processing caveat. An agent has everything needed to call it correctly and interpret results.
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 the schema already documents params well, and the description largely mirrors the style and role semantics. It does add value by confirming aliases/plain words are accepted and by disclosing the not_found fallback for unknown roles, pushing it slightly above the baseline of 3.
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 opens with a specific verb-and-resource framing ('a sound for a named event or interaction') and enumerates concrete role examples (button click, purchase success, error beep). It also clearly distinguishes itself from siblings by naming get_sound_set and search_sounds as different branches.
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?
It states explicit routing conditions: use get_sound_set for multiple events, search_sounds for a description or a gap, and explicitly notes 'these are task branches, not a fixed sequence.' This gives an agent clear when-to-use and when-to-use-something-else guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full metadata for one sound by slug, including download URLs, description and acoustics measured from the WAV (silence before the sound, where it peaks, audible length, attack, tail, brightness, levels, character labels).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Sound slug, e.g. 'impact-punch-01' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds real value by disclosing that acoustics are measured from the WAV file (silence, peak, attack, tail, brightness) — information an agent cannot get from structured fields and that clarifies the data's provenance and trustworthiness.
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?
One sentence, front-loaded with the action and resource, with the field enumeration placed after so an agent can stop reading early if it only needs the purpose. Nothing is redundant — the enumeration substitutes for the absent output schema.
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 no output schema, the description carries the burden of describing returns and does so thoroughly (download URLs, description, acoustic measurements). It does not mention behavior on an unknown slug (error vs empty) or any rate/auth constraints, which are the only remaining gaps for a simple read 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?
Schema coverage is 100% and the schema itself supplies the example format ('impact-punch-01'). The description only restates that the slug identifies a single sound, adding no format or edge-case meaning beyond the schema; 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?
Specific verb (get) plus resource (full metadata for one sound) plus lookup key (slug), and it enumerates exactly what comes back. 'One sound by slug' cleanly separates it from search_sounds (listing/querying) and change_sound (mutation) without needing to name them.
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 phrase 'by slug' implies a slug must already be known (presumably from search_sounds), but the description never states when to use this versus search_sounds or get_generation, nor any exclusions. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. Listen to the files in context. Sets include UI styles, game and app scenarios, acoustic-drum-kit, animal-calls (15 isolated calls), and dungeon-traps (6 isolated mechanisms).
| 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; OGG only among sounds published before 2026-10-14). Legacy urls remains MP3; download_urls follows this format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, closed read, so the bar is lower; the description still adds real value by disclosing the return payload (format metadata, hashes, stable download URLs) and by enumerating what the sets actually contain. It does not discuss size limits or whether the returned URLs expire, which is a minor remaining gap.
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?
Front-loaded with purpose and the sibling distinction, then the set inventory. The trailing "Listen to the files in context" is a slightly odd imperative but is short and actionable rather than filler.
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 no output schema, the description carries the return-value burden and does so by naming format metadata, hashes and download URLs. The set inventory compensates for the opaque enum. Only pagination/response-size behaviour is unaddressed, which is small for a set-returning 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?
Schema coverage is 100%, so the enum and format semantics are already documented. The description goes beyond this by describing the character of the set families and noting that animal-calls contains 15 isolated calls and dungeon-traps 6 isolated mechanisms, which shapes how the agent uses the returned files.
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?
States a specific verb and resource ('Get a coherent set of sounds') plus the shape of the result — one sound per role with format metadata, hashes and stable download URLs. It explicitly distinguishes itself from get_role_sound, so an agent can choose between them without opening either schema.
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?
"Use it when the task needs a whole kit; use get_role_sound for one event" gives both the positive condition and the named alternative in one sentence. The added note to listen to files in context tells the agent what to do with the result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 (generate_available; type ambience or bgm for looping environments or background music; use its mcp_tool when present and authorized, or its Studio page). Returns direct, hotlinkable MP3/WAV URLs and verified OGG (Vorbis) URLs where available — no API key, no attribution required — plus acoustics measured from the WAV (onset_ms, peak_ms, audible_ms, attack_ms, tail_ms, centroid_hz, peak_dbfs, rms_dbfs), 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).
| 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 10, max 50) | |
| query | Yes | Use concise English search terms for the source or event, action and essential audible traits from the user's request or project context: 'door slam', 'soft UI confirmation chime', 'coin pickup'. A single clear source such as 'thunder' is valid; do not pad it. Translate other languages while preserving meaning. Avoid full generation prompts, app backstory, synonym lists and invented materials or environments: full matches must cover every query word. Put duration, loop and format requirements in their separate fields. If no full match exists, inspect closest and missing_terms; simplify only optional wording, never silently drop a required trait. | |
| format | No | Delivery format (ogg = Ogg Vorbis, only sounds published before 2026-10-14 have it); 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 length of the sound in milliseconds: a file may run longer with near-silence after the sound (audible_ms is the sound, duration_ms the file; checks say which was met). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm read-only, non-destructive, non-open-world behavior, but the description adds substantial context: fallback to closest matches with missing_terms, library_fit levels, generation options, direct hotlinkable URLs, no API key or attribution, audio measurements, and QC status. No contradiction with annotations is present.
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 purpose and alternatives are front-loaded, but the description is a dense single paragraph packed with output details, fallback behavior, and acoustic metadata. Most content is relevant, but the lack of structure and sheer length make it harder to scan than necessary.
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?
There is no output schema, so the description carries the burden of explaining return values. It does so thoroughly: results vs. closest, missing_terms, library_fit, generation options, direct audio URLs, acoustics, character labels, loop/QC status, and score/match ranking semantics.
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 query, loop, limit, format, category, and max_duration_ms are already well documented. The description reinforces that hard constraints always apply and explains fallback matching semantics, but it does not add parameter-specific syntax or constraints 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 states a specific verb and resource: 'Free-text search over the SFXMint library of free CC0 sound effects.' It explicitly distinguishes this tool from siblings get_role_sound and get_sound_set by naming their different use cases.
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?
It gives explicit when-to-use guidance for sound descriptions, constraints, or gaps, and names alternatives for named events and multi-event tasks. It also explains that these are task branches rather than a fixed sequence, and describes fallback behavior when no full match exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One link to SFXMint Studio for every sound the library lacks in this task: pass each missing sound as a short description and give the user the returned user_message once, instead of one link per sound. The page lists them ready to make one by one, heard before paying; nothing is made or charged here, and no API key is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| sounds | Yes | Each missing sound as a short description of what is heard, e.g. 'alien shotgun blast', 'slime monster death gurgle'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, yet the description still adds real value: nothing is made or charged, no API key is required, and the page is a preview the user hears before paying. The only gap is that the 30-sound cap is left to the schema.
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, front-loaded with the core concept and followed by the operational instruction. The prose is dense and slightly run-on ('The page lists them ready to make one by one, heard before paying'), but nothing is wasted.
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?
For a one-parameter, non-destructive link-generation tool with no output schema, the description covers cost, auth, and the key return field (user_message) that must be relayed. Only the batching limit is unaddressed, and the schema carries that.
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% and the single parameter is documented with concrete examples ('alien shotgun blast'), so the schema does the heavy lifting. The description's 'pass each missing sound as a short description' is consistent but adds no syntax or constraint detail 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 names the resource (a single SFXMint Studio link listing all missing sounds) and implicitly contrasts it with the sibling generators by stating 'nothing is made or charged here.' The phrasing 'for every sound the library lacks in this task' is slightly convoluted, but an agent can still distinguish this from generate_sound or search_sounds.
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?
It gives a clear usage rule: pass each missing sound as a short description and hand the user the returned user_message once, rather than one link per sound. That is a strong batching directive, though it never explicitly names the alternative sibling tools (e.g. generate_sound) it replaces.
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.
search_sounds1 field changedInput schema / properties / limit / descriptionPrevious value: -"Max results (default 20, max 50)"New value: +"Max results (default 10, max 50)"generate_sound1 field changedInput schema / properties / variations_of / properties / order_id / descriptionAdded value: +"The generation, from generate_sound or get_generation"get_generation1 field changedInput schema / properties / order_id / descriptionAdded value: +"The order_id returned by generate_sound, generate_ambience, generate_music or change_sound"get_role_sound1 field changedInput schema / properties / format / descriptionAdded value: +"Delivery format the candidate must have (ogg = Ogg Vorbis, only sounds published before 2026-10-14 have it); default MP3 and WAV URLs."studio_list_linkget_role_sound1 field changedInput schema / properties / max_duration_ms / descriptionPrevious value: -"Hard maximum delivered duration in milliseconds."New value: +"Hard maximum length of the sound in milliseconds: a file may run longer with near-silence after the sound (audible_ms is the sound, duration_ms the file; checks say which was met)."search_sounds1 field changedInput schema / properties / max_duration_ms / descriptionPrevious value: -"Hard maximum delivered duration in milliseconds; format-specific measurement is required."New value: +"Hard maximum length of the sound in milliseconds: a file may run longer with near-silence after the sound (audible_ms is the sound, duration_ms the file; checks say which was met)."generate_ambiencegenerate_musicgenerate_sound2 fields changedInput schema / properties / enhance / descriptionPrevious value: -"Recommended: SFXMint writes the prompt into the description the model gets, as the website's AI Enhance does, and the result gives that description. Default false: the prompt goes to the model exactly as written."New value: +"Default false. Prefer false when you can write the final English sound description using the prompt guidance: it skips the server AI rewrite. True asks SFXMint to expand or adapt a brief, as the website's AI Enhance does; the result includes enhanced_prompt. With false, non-Latin text may still trigger server translation, so write English to avoid that extra call. Neither setting guarantees audio quality; listen to the takes."Input schema / properties / prompt / descriptionPrevious value: -"The sound the user needs, in plain words and any language: what it is for and what should be heard. With enhance (recommended), SFXMint writes the description the model gets. Leave out lengths (use duration_s)."New value: +"For enhance=false, write the final audible description in plain English, usually 1-3 sentences, at most 400 characters. Start with 'TrackType: SFX,'. Name the source, action and relevant material; preserve requested count, intensity, pace and how the sound starts, develops and ends. Translate a use such as 'success' into the intended audible event, e.g. 'TrackType: SFX, three bright electronic tones rise in pitch, each fading quickly.' Preserve an explicitly requested sound: a confirmation click stays a click. Mention only sounds to be heard; omit excluded sounds entirely instead of writing 'no music' or 'without speech'. Avoid brands, character names and metaphors that name unwanted sources. Add perspective, environment or timbre only when requested or established by context; do not invent extra events. Keep simple sounds short. Put total length in duration_s. For enhance=true, a plain-language brief in any language is enough; SFXMint writes the model description."search_sounds1 field changedInput schema / properties / query / descriptionPrevious value: -"Keywords or a natural-language description, e.g. 'door slam', 'soft UI confirmation chime', 'coin pickup'"New value: +"Use concise English search terms for the source or event, action and essential audible traits from the user's request or project context: 'door slam', 'soft UI confirmation chime', 'coin pickup'. A single clear source such as 'thunder' is valid; do not pad it. Translate other languages while preserving meaning. Avoid full generation prompts, app backstory, synonym lists and invented materials or environments: full matches must cover every query word. Put duration, loop and format requirements in their separate fields. If no full match exists, inspect closest and missing_terms; simplify only optional wording, never silently drop a required trait."generate_sound1 field changedInput schema / properties / variations_ofAdded value: +{
+ "description": "A variation set instead of a new sound: four takes started from one finished take of this account's generation, close to it, for a game to play at random so the sound does not repeat (footsteps, hits, shots). The result adds engine files (a Godot AudioStreamRandomizer .tres and a Unity script) to save beside the WAVs. Uses one generation; prompt then only names the set.",
+ "properties": {
+ "order_id": {
+ "type": "string"
+ },
+ "take": {
+ "description": "Which of its takes (1-4)",
+ "type": "number"
+ }
+ },
+ "required": [
+ "order_id",
+ "take"
+ ],
+ "type": "object"
+}add_kit_soundschange_kit_takeexport_game_kitfill_kit_from_libraryfind_kit_sound_candidatesget_game_kitlist_kit_soundsmake_kit_soundspick_kit_takestart_game_kituse_library_soundFree sound effects, music and ambience for games, videos and apps. Search, play and download.
CC0 sound effects API for AI agents — search, preview, and download via MCP.
Game sound effects from a text prompt: game-ready WAVs with seamless loops and variations.
Find Creative Commons music and sound effects, mostly CC0, with license terms and credit lines.
Add one secure layer between your agents and this server.