Skip to main content
Glama

Search for sound effects

search_sfx
Read-only

Sound effects from Cardboard's library, ranked by how well each fits query within category. Each has its length, when it suits, a volume, and the link download_media takes to bring it into a project. Free.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many results (default 10, at most 20)
queryNoThe sound, like "punch impact" or "whoosh"
categoryNotyping (keyboard, mouse), camera (shutter, film, vinyl), impact (hit, punch, boom), ui (alerts, dings), transition (whoosh, riser), misc (foley, footsteps)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: results are relevance-ranked, each result carries length, suitability, volume, and a download link, and the library is 'Free' — meaningful since there is no output schema. It stops short of saying result count or what happens on zero matches.

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?

Two sentences, front-loaded with what is returned and how it is ranked. 'Free.' is a clipped fragment but carries genuine cost information; 'when it suits' is slightly vague phrasing.

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?

With no output schema, the description compensates by enumerating the shape of each result (length, suitability, volume, download link), which is exactly what an agent needs to plan the downstream call. Only minor gaps remain: no result cap mentioned in prose (schema covers it) and no empty-result behavior.

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%, including a fully enumerated category with per-value meanings, so the schema does the heavy lifting. The description adds how `query` and `category` interact in ranking, but says nothing about `limit` beyond what the schema already declares.

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

Purpose4/5

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

States a specific verb (search) and resource (sound effects from Cardboard's library) and explains the ranking model — relevance to `query` constrained by `category`. That alone distinguishes it from generate_sfx and search_music by resource type, though the description never names those siblings explicitly.

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

Usage Guidelines3/5

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

Usage is only implied: the phrase about 'the link download_media takes to bring it into a project' sketches the search-then-download flow. There is no explicit when-to-use guidance versus generate_sfx or download_media, and no note on when to omit `query` or `category`.

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.

Resources