Skip to main content
Glama

sounds

by com.sfxmint
OverviewDiscussionsAdmin

Server Details

Free CC0 sound effects for agents: ask by role (button-click, coin), sets, or search 4,600+.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 17 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: job lookup, role-based retrieval, metadata by slug, set retrieval, and free-text search. No overlap or ambiguity exists between them.

Naming Consistency5/5

All retrieval tools follow the 'get_' prefix (get_job, get_role_sound, get_sound, get_sound_set), with search_sounds as the only non-get tool, which is a natural exception for a search action. The pattern is consistent and predictable.

Tool Count5/5

Five tools is an ideal scope for a sound effects library, covering search, role-based selection, set retrieval, metadata lookup, and historical job access without being overwhelming or sparse.

Completeness5/5

The tool surface covers the full lifecycle of sound discovery and retrieval: search, role-based selection, sets, individual metadata, and historical jobs. No obvious gaps exist, and even role listing is handled via the not_found response in get_role_sound.

Available Tools

5 tools
get_jobBInspect

Look up a historical generation job by job_id. New generation is no longer available.

ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYes

TDQS

B3.1/5.0
Behavior3/5

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

'Look up' implies a read-only retrieval, and the note about new generation being unavailable adds meaningful context beyond the tool name. However, since there are no annotations, the description does not clarify what the tool returns, error behavior, or access prerequisites, leaving notable gaps.

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 very concise—two short sentences, both conveying essential information with no filler. The first sentence front-loads the core action, and the second adds an important context note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple lookup-by-id tool, the description gives the minimum viable information. But with no annotations and no output schema, it would help to state what a returned job represents or the fact that this only retrieves job metadata rather than sound assets.

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

Parameters2/5

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

The description mentions job_id but adds little meaning beyond the schema property name. With 0% schema_description_coverage, the description should compensate by explaining the format, source, or semantics of job_id, but it only restates that the lookup happens 'by job_id.'

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?

The description clearly states that the tool looks up a historical generation job by job_id, which is specific and action-oriented. It does not explicitly distinguish itself from sibling tools like get_sound, but the focus on 'generation job' makes the tool's purpose reasonably unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'New generation is no longer available' hints that this tool is for existing/historical jobs only, but it does not explain when to use this tool versus alternatives such as get_sound or get_role_sound. No exclusions or decision guidance is provided.

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, rain loop. Pass the role as plain words: role ids (click, success, purchase-success, dialogue-blip, rain-loop…) 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). Loop roles require prepared loop metadata; WAV seam evidence and MP3 padding are reported separately and may remain unknown. 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
NameRequiredDescriptionDefault
loopNoRequire prepared loop metadata; seam evidence is returned separately.
roleYesRole id or alias, e.g. 'click', 'button click', 'purchase-success', 'ka-ching', 'error beep', 'level-up', 'dialogue blip', 'rain-loop'
styleNoOptional. balanced (default) = the family's most typical take; crisp = short, bright, dry; soft = darker, gentler; spacious = reverb, longer tail
formatNo
max_duration_msNoHard maximum delivered duration in milliseconds.

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries full disclosure burden. It goes beyond the schema by explaining role/alias flexibility, content_check states (verified/unverified/rejected), unverified preview certification limits, processing requirements with SHA256 and listening checks, loop seam evidence reporting, unknown-role not_found behavior, and a roles-list endpoint. This is unusually transparent.

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

Conciseness3/5

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

The description is front-loaded with the main use case and input guidance, but the middle section expands into procedural policies (downloading, processing recipes, SHA256 checks, mixing sources) that are tangential to selecting and invoking this specific tool. It is informative but dense and could be restructured into scannable sections.

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?

Despite no output schema, the description explains what will be returned (URLs, alternates, family page), how errors are surfaced (not_found with role list), how loop roles behave, and how to choose sibling tools. It also covers style, alias handling, and content certification, leaving little ambiguity for correct invocation.

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 high (80%), so the baseline is 3. The description adds real meaning for 'role' by stating that ids and common aliases are accepted and by giving many examples. It also elaborates style meanings and loop requirements. However, it adds little for 'format' or 'max_duration_ms', though those are already schema-covered.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with an explicit usage trigger: 'Choose this when the task calls for a sound for a named event or interaction' and names concrete examples (button click, purchase success, error beep). It clearly states the resource and action: 'Returns a qualified candidate for that role... with MP3/WAV URLs, 2-3 alternates and the family page.' It also distinguishes itself from get_sound_set and search_sounds.

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?

Provides direct routing guidance: 'For multiple events consider get_sound_set; use search_sounds for a description or a gap.' It also clarifies 'These are task branches, not a fixed sequence,' which helps an agent decide between tools rather than chaining them mechanically.

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, generation prompt and measured acoustics (attack/tail/brightness + character labels).

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesSound 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?

No annotations are present, so the description carries the full burden of conveying behavior. It communicates a read-only operation and describes the return payload, but does not mention error behavior, permissions, or side effects. This is adequate for a simple get-by-slug tool but not deeply 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?

The description is a single efficient sentence that front-loads the verb and resource, then lists the valuable return fields. There is no filler or redundancy.

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?

With one simple parameter and no output schema, the description lists the key return categories (download URLs, generation prompt, acoustics, character labels), which is enough for an agent to decide on invocation. It does not exhaustively specify response structure, but that is not critical for calling the 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?

The input schema has 100% coverage for the single 'slug' parameter, including an example, so the description adds no necessary parameter information. Baseline 3 applies because the schema already handles parameter semantics fully.

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') with a clear resource ('full metadata for one sound') and a specific identifier ('by slug'). It also enumerates distinctive contents (download URLs, generation prompt, measured acoustics), which makes it easily distinguishable from list/search/generate siblings.

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 when to use the tool: when you have a sound slug and need full metadata. It gives no explicit exclusions or alternative tool names, but the context is clear enough that an agent can infer the appropriate use case.

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
NameRequiredDescriptionDefault
setNoSet id (default ui-crisp). Includes acoustic-drum-kit, animal-calls and dungeon-traps alongside the UI and scenario sets listed in the enum.
formatNoFile 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.

search_soundsAInspect

Free-text search over 4,600+ 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. Exact keyword matches come first, then semantic nearest neighbours; hard constraints are applied before the result limit and a request may validly return no qualified candidate with near-match diagnostics. 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
NameRequiredDescriptionDefault
loopNoRequire (true) or exclude (false) a candidate marked with prepared loop metadata; seam evidence is returned separately.
limitNoMax results (default 20, max 50)
queryYesKeywords or a natural-language description, e.g. 'door slam', 'soft UI confirmation chime', 'coin pickup'
formatNoDelivery format (ogg = Ogg Vorbis); loop=true defaults to WAV when omitted.
categoryNoOptional 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
max_duration_msNoHard maximum delivered duration in milliseconds; format-specific measurement is required.

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 burden, and it excels: it discloses search ordering (exact keyword matches first, then semantic nearest neighbours), constraint application before the result limit, the possibility of no qualified candidate, return details (direct URLs, acoustics, character labels, loop/QC status), and the meaning of score/match fields. This is comprehensive behavioral transparency.

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 dense but every sentence earns its place: purpose, usage, alternatives, search mechanics, constraints, return data, and ranking labels are all covered without redundancy. It is longer than average, but the tool's complexity justifies it. Front-loading the purpose and usage guidelines ensures the agent quickly grasps the core.

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?

The description is complete for a search tool with no output schema: it explains what the return contains (URLs, acoustics, labels, QC status, ranking evidence) and how to interpret the match types (role, exact, partial, semantic). It also covers constraints and edge cases. Nothing an agent needs to call it correctly is missing.

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 description coverage is 100%, so the schema already documents all six parameters. The description adds value by explaining cross-parameter behavior: 'loop=true defaults to WAV when omitted,' 'hard constraints are applied before the result limit,' and 'max_duration_ms' being a hard maximum with format-specific measurement. It also clarifies the ranking semantics tied to the query parameter. This exceeds the baseline 3.

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 verb and resource: 'Free-text search over 4,600+ free CC0 sound effects.' It explicitly differentiates from siblings by naming alternatives and the conditions to choose them: 'Choose get_role_sound for a named event or get_sound_set for multiple events when that fits the task.' This makes the tool's purpose unambiguous and distinct.

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 clearly states when to use this tool: 'Use it for sound descriptions, additional constraints or gaps left by another tool.' It also explains the relationship with siblings: 'these are task branches, not a fixed sequence.' Additionally, it notes that requests may return no qualified candidate with diagnostics, setting expectations for edge cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updates
    • Changedget_role_sound1 field changed
      • changedInput schema / properties / format / enum
        Previous value: -[
-  "wav",
-  "mp3"
-]New value: +[
+  "wav",
+  "mp3",
+  "ogg"
+]
    • Changedget_sound_set1 field changed
      • changedInput schema / properties / format / enum
        Previous value: -[
-  "wav",
-  "mp3"
-]New value: +[
+  "wav",
+  "mp3",
+  "ogg"
+]
    • Changedsearch_sounds2 fields changed
      • changedInput schema / properties / format / description
        Previous value: -"Delivery format; loop=true defaults to WAV when omitted."New value: +"Delivery format (ogg = Ogg Vorbis); loop=true defaults to WAV when omitted."
      • changedInput schema / properties / format / enum
        Previous value: -[
-  "wav",
-  "mp3"
-]New value: +[
+  "wav",
+  "mp3",
+  "ogg"
+]
  2. 1 tool update
    • Changedget_sound_set2 fields changed
      • changedInput schema / properties / set / description
        Previous value: -"Set id (default ui-crisp). Style: ui-crisp | ui-soft | ui-spacious | retro-game. Instrument: acoustic-drum-kit. Scenario: chat-app | saas-app | checkout | learning | puzzle-game | platformer | horror-game | video-editing | smart-device | wellness | ai-coding-tool"New value: +"Set id (default ui-crisp). Includes acoustic-drum-kit, animal-calls and dungeon-traps alongside the UI and scenario sets listed in the enum."
      • changedInput schema / properties / set / enum
        Previous value: -[
-  "ui-crisp",
-  "ui-soft",
-  "ui-spacious",
-  "retro-game",
-  "chat-app",
-  "saas-app",
-  "checkout",
-  "learning",
-  "puzzle-game",
-  "platformer",
-  "horror-game",
-  "video-editing",
-  "smart-device",
-  "wellness",
-  "ai-coding-tool",
-  "acoustic-drum-kit"
-]New value: +[
+  "ui-crisp",
+  "ui-soft",
+  "ui-spacious",
+  "retro-game",
+  "chat-app",
+  "saas-app",
+  "checkout",
+  "learning",
+  "puzzle-game",
+  "platformer",
+  "horror-game",
+  "video-editing",
+  "smart-device",
+  "wellness",
+  "ai-coding-tool",
+  "acoustic-drum-kit",
+  "animal-calls",
+  "dungeon-traps"
+]
  3. 1 tool update
    • Changedget_sound_set2 fields changed
      • changedInput schema / properties / set / description
        Previous value: -"Set id (default ui-crisp). Style: ui-crisp | ui-soft | ui-spacious | retro-game. Scenario: chat-app | saas-app | checkout | learning | puzzle-game | platformer | horror-game | video-editing | smart-device | wellness | ai-coding-tool"New value: +"Set id (default ui-crisp). Style: ui-crisp | ui-soft | ui-spacious | retro-game. Instrument: acoustic-drum-kit. Scenario: chat-app | saas-app | checkout | learning | puzzle-game | platformer | horror-game | video-editing | smart-device | wellness | ai-coding-tool"
      • changedInput schema / properties / set / enum
        Previous value: -[
-  "ui-crisp",
-  "ui-soft",
-  "ui-spacious",
-  "retro-game",
-  "chat-app",
-  "saas-app",
-  "checkout",
-  "learning",
-  "puzzle-game",
-  "platformer",
-  "horror-game",
-  "video-editing",
-  "smart-device",
-  "wellness",
-  "ai-coding-tool"
-]New value: +[
+  "ui-crisp",
+  "ui-soft",
+  "ui-spacious",
+  "retro-game",
+  "chat-app",
+  "saas-app",
+  "checkout",
+  "learning",
+  "puzzle-game",
+  "platformer",
+  "horror-game",
+  "video-editing",
+  "smart-device",
+  "wellness",
+  "ai-coding-tool",
+  "acoustic-drum-kit"
+]
  4. 1 tool update
    • Removedgenerate_sound
  5. 3 tool updates
    • Changedget_role_sound3 fields changed
      • addedInput schema / properties / format
        Added value: +{
+  "enum": [
+    "wav",
+    "mp3"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / loop
        Added value: +{
+  "description": "Require prepared loop metadata; seam evidence is returned separately.",
+  "type": "boolean"
+}
      • addedInput schema / properties / max_duration_ms
        Added value: +{
+  "description": "Hard maximum delivered duration in milliseconds.",
+  "type": "number"
+}
    • Changedget_sound_set1 field changed
      • addedInput schema / properties / format
        Added value: +{
+  "description": "File format for selection and checks (default WAV). Legacy urls remains MP3; download_urls follows this format.",
+  "enum": [
+    "wav",
+    "mp3"
+  ],
+  "type": "string"
+}
    • Changedsearch_sounds3 fields changed
      • addedInput schema / properties / format
        Added value: +{
+  "description": "Delivery format; loop=true defaults to WAV when omitted.",
+  "enum": [
+    "wav",
+    "mp3"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / loop
        Added value: +{
+  "description": "Require (true) or exclude (false) a candidate marked with prepared loop metadata; seam evidence is returned separately.",
+  "type": "boolean"
+}
      • addedInput schema / properties / max_duration_ms
        Added value: +{
+  "description": "Hard maximum delivered duration in milliseconds; format-specific measurement is required.",
+  "type": "number"
+}
  6. 6 tool updates
    • First observedgenerate_sound
    • First observedget_job
    • First observedget_role_sound
    • First observedget_sound
    • First observedget_sound_set
    • First observedsearch_sounds

Related MCP Connectors

Related MCP Servers

  • strongerfx

    smartpage
    F
    license
    Not graded
    quality
    B
    maintenance
    Provides 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.
    -

  • sfx

    gteuscher
    A
    license
    A
    quality
    B
    maintenance
    Enables coding agents to synthesize and play video-game sound effects by translating natural-language descriptions into layered synthesis specs, then rendering normalized WAV files.
    9
    MIT

  • audiomade

    yasib48
    A
    license
    A
    quality
    C
    maintenance
    Generates four game-ready AI sound effect candidates from a text description, lets users audition them, and installs only the selected WAV into Unity, Godot, or generic game projects.
    6
    19 npm
    1
    MIT
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.

Resources