Skip to main content
Glama

sounds

by com.sfxmint
OverviewDiscussionsAdmin

get_role_sound

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.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / format / enum
      Previous value: -[
-  "wav",
-  "mp3"
-]New value: +[
+  "wav",
+  "mp3",
+  "ogg"
+]
  2. 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"
+}
  3. First observed

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.

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