Skip to main content
Glama

Download a sound

download_sound
Idempotent

Get the full-quality file (usually WAV) for one sound, level-matched to the rest of the catalog (one gain, no compression; gain_db says how much) unless you pass variant "original" for the untouched master, as a direct link that needs no header and works for 15 minutes. Fetch it right away with the returned curl command (curl -L -o <file_name> ""). If the link has expired, call download_sound again. If you can't save files and give the person the link instead, also give them page_url, the sound's page on soundza.com: the link stops working after 15 minutes, the page never does. Save each file once and reuse it by sound id: a sound's file never changes. Each different sound counts toward the key's download limits (fetching one again within the week doesn't), and every call counts toward a cap on file fetches, so download only sounds you mean to use. optional_license_file is a ready-made license note. If you're adding sounds to a project folder, such as a game's audio folder, you can save it alongside them: optional_license_file.header followed by optional_license_file.entry, in a file named optional_license_file.filename; for more sounds in the same folder, append just optional_license_file.entry.

Input Schema

NameRequiredDescriptionDefault
idYesThe sound's id, from search_sounds.
variantNo"normalized" (default): level-matched to the catalog. "original": the untouched master.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, it discloses important behavior: links are headerless and expire after 15 minutes, curl usage is expected, repeated calls are needed after expiry, per-key download limits and a file-fetch cap apply, files are immutable by sound id, and license-file fields are provided. These details materially help correct invocation and avoid wasted downloads.

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 information-dense and front-loads the main purpose, but it is a long run-on paragraph with some repetition about the 15-minute expiry and page_url fallback. It would be clearer with shorter sentences or structured 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?

There is no output schema, but the description explains the returned direct link, curl command, page_url fallback, expiry behavior, and license-file fields. For a two-parameter download tool, this is complete enough for an agent to invoke it correctly and handle common failure modes.

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 100%, and the schema already defines id as coming from search_sounds and variant as normalized vs. original. The description adds practical context around variant behavior and file immutability, but it does not add much parameter-specific meaning beyond 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 states a specific verb and resource: get the full-quality file (usually WAV) for one sound. It distinguishes the two variants clearly, normalized vs. original master, so an agent can tell this apart from metadata-oriented siblings like get_sound.

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?

It gives clear usage context: fetch immediately with the returned curl command, call again if the link expired, reuse files by sound id, and only download sounds intended for use. It does not explicitly compare against sibling tools such as get_sound, so it falls short of full when/when-not/alternatives guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.