Skip to main content
Glama
Sign In

sounds

by com.sfxmint
OverviewDiscussionsAdmin

get_role_sound

Read-only

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.

Input 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', 'notification'
styleNoOptional. balanced (default) = the family's most typical take; crisp = short, bright, dry; soft = darker, gentler; spacious = reverb, longer tail
formatNoDelivery format the candidate must have (ogg = Ogg Vorbis, only sounds published before 2026-10-14 have it); default MP3 and WAV URLs.
max_duration_msNoHard 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).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / format / description
      Added value: +"Delivery format the candidate must have (ogg = Ogg Vorbis, only sounds published before 2026-10-14 have it); default MP3 and WAV URLs."
  2. Changed1 schema field changed
    • changedInput schema / properties / max_duration_ms / description
      Previous 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)."
  3. Changed1 schema field changed
    • changedInput schema / properties / role / description
      Previous 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'"
  4. Changed1 schema field changed
    • changedInput schema / properties / format / enum
      Previous value: -[
-  "wav",
-  "mp3"
-]New value: +[
+  "wav",
+  "mp3",
+  "ogg"
+]
  5. Changed3 schema 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"
+}
  6. First observed

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

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 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.

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 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.

Usage Guidelines5/5

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.

All sounds toolsInspect
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