Skip to main content
Glama
Sign In
mcp-freesound

mcp-freesound

by jumpifequal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Download preview

download_preview
Idempotent

Downloads a Freesound sound's preview audio (MP3 or OGG) to the configured server folder, letting you fetch playable previews without OAuth2.

Instructions

Download the preview audio file (MP3 or OGG) of a Freesound sound to the configured download folder on the server machine. Full-quality originals require OAuth2 and are not supported; previews are free to fetch.

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": {
      "sound_id": "<sound_id>"
    },
    "name": "download_preview"
  }
}

Input Schema

NameRequiredDescriptionDefault
formatNoAudio format.mp3
qualityNoPreview quality.hq
sound_idYesFreesound sound ID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

The annotations already cover safety (destructiveHint=false, idempotentHint=true) and scope (openWorldHint=true), so the description's value is in adding that the file lands in a configured folder on the server rather than being returned to the caller, plus the OAuth2 limitation. It does not state what the tool returns on success (a path? a confirmation?), which is a meaningful gap for a download operation.

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

Conciseness5/5

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

Two sentences, no filler, and the core action plus destination is front-loaded before the OAuth2 caveat. Every sentence carries information an agent would not otherwise have.

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 three-parameter tool with full schema coverage and annotations, the description covers what the tool does, where the output goes, and the key limitation. With no output schema, the absence of any statement about the return value or how to locate the downloaded file is the one remaining hole.

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 description coverage is 100% and both enum parameters carry descriptions, so the schema does the work. The description echoes format (MP3 or OGG) and the quality distinction only indirectly through the preview-versus-original contrast, adding little meaning beyond the structured fields.

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 names a specific verb (download), a specific resource (the preview audio file, MP3 or OGG, of a Freesound sound), and a specific destination (the configured download folder on the server machine). That destination detail alone separates it from every sibling, which are all read-only search/get tools.

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 a clear condition for use and an explicit exclusion: full-quality originals require OAuth2 and are not supported, while previews are free to fetch. What is missing is a pointer to what an agent should do instead when it needs an original, so it stops short of naming an alternative.

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

Deploy Server

Other Tools