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, notification. Pass the role as plain words: role ids (click, success, purchase-success, dialogue-blip, notification…) and common aliases (button click, ka-ching, jump scare, text blip…) are all accepted. Returns a qualified candidate for that role when one satisfies the requested constraints, with MP3/WAV URLs, 2-3 alternates and the family page for browsing more. Five core game roles include content_check (verified/unverified/rejected), scoped to scene, role, format and exact file SHA256; unverified previews are not certified suitable. Download selected files locally and retain originals. Task-permitted processing requires a recipe, output SHA256, renewed file checks and a listening check; changed bytes do not inherit content review. Other task-permitted sources or local synthesis may be mixed in. Optional style: crisp (short, bright, dry), soft (darker, gentler), spacious (reverb, longer tail), balanced (default: most typical). For multiple events consider get_sound_set; use search_sounds for a description or a gap. These are task branches, not a fixed sequence. Unknown roles return not_found with the full role list; GET https://sfxmint.com/api/v1/roles lists roles with aliases.

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

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so richly: it discloses return contents (URLs, alternates, family page), content-check scoping and certification limits, local download expectations, processing constraints including SHA256 and listening checks, handling of changed bytes, behavior for unknown roles, and a roles-list endpoint.

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

Conciseness4/5

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

The description is long but densely informative and well front-loaded with the primary usage guidance. Some sections, such as the content_check and processing details, add complexity but are relevant to safe and correct invocation. It earns a 4 rather than 5 because the density could make it harder to scan quickly.

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

Completeness5/5

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

Given five parameters, no annotations, and no output schema, the description covers what the tool returns, failure modes, parameter interpretation, alternatives, and important processing constraints. An agent has enough information to select and invoke the tool correctly in most scenarios.

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

Parameters4/5

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

Schema coverage is 80%, so the baseline is 3. The description adds meaningful semantics beyond the schema for the role parameter (accepts aliases, examples, not_found behavior) and the style parameter (defines crisp/soft/spacious/balanced). It does not add much for loop, format, or max_duration, but those are adequately described in the schema.

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

Purpose5/5

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

The description opens with a specific use case—retrieving a sound for a named event or interaction—and lists concrete examples. It clearly distinguishes this tool from siblings by explicitly naming get_sound_set and search_sounds as alternatives for different tasks.

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

Usage Guidelines5/5

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

The description states exactly when to choose this tool ('Choose this when the task calls for a sound for a named event') and when to prefer alternatives ('For multiple events consider get_sound_set; use search_sounds for a description or a gap'). It even notes that these are task branches, not a fixed sequence.

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

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