Gomo Sounds

Audio download link

save_sound

Only when the user asked for the file or chose to bring the sounds only through the conversation; never to put files into their project before that. Link to download an audio file FROM YOUR ACCOUNT (audio URL from find_sounds/get_entity): show it to the user, who opens it in the browser (it works without logging in, for 24 hours). Explore sounds belong to other accounts and do NOT come out through here: tell the user to open /explore on the site and download there (free, with an account) or generate their own. An event with more than one sound (e.g. 3 sword hits) must be played by picking one of its files at random each time, never only the first: write the playback code that way and tell the user.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "audio_url": "<audio_url>"
    },
    "name": "save_sound"
  }
}

Input Schema

Name	Required	Description	Default
`audio_url`	Yes
`file_name`	No	Name of the downloaded file, e.g. Attack - Golem

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With only a title annotation, the description discloses key behaviors: the link works without logging in for 24 hours; explore sounds are excluded; and for events with multiple sounds, playback should pick a random file. It does not cover error handling or permissions, but the disclosure is strong for the annotation coverage provided.

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 usage conditions but is somewhat rambling and contains run-on sentences (e.g., the first sentence). It includes relevant information, but the multi-sound event instruction and the explore sound alternative could be more tightly integrated, making the overall structure less crisp than optimal.

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?

For a 2-param tool with no output schema and minimal annotations, the description covers when to use, what the tool does, the behavior of the download link, an alternative for explore sounds, and how to handle multi-sound events. It is nearly complete, missing only edge-case error handling or validation details.

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?

Schema coverage is 50%: audio_url has no schema description, and the description compensates by specifying its source ('audio URL from find_sounds/get_entity'). However, it adds no meaning beyond the schema for file_name (which already has a description and example), leaving the other half of the parameter set unexpanded.

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 specific verb+resource: 'Link to download an audio file FROM YOUR ACCOUNT' and clarifies it is for sounds from find_sounds/get_entity, not for saving to the project. It distinguishes from explore sounds, which 'do NOT come out through here'.

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?

Explicit when-to-use: 'Only when the user asked for the file or chose to bring the sounds only through the conversation'; explicit when-not: 'never to put files into their project before that'. It also provides an alternative for explore sounds (open /explore) and guidance for multi-sound events (pick a random file each time).

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

All Gomo Sounds tools Inspect

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

Need Help?