Get full metadata for one sound by slug, including download URLs, generation prompt and measured acoustics (attack/tail/brightness + character labels).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Sound slug, e.g. 'impact-punch-01' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It conveys a read-only retrieval operation through 'Get' and is transparent about what is returned, including download URLs and acoustics. It stops short of detailing error behavior (e.g., 404 for unknown slug) or side effects, but for a simple getter the verb plus return details provide substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that leads with the primary action and then appends the key response contents. Every phrase earns its place; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no output schema, the description is complete: it states the lookup key, the resource, and the return contents. The sibling context (generate_sound, search_sounds, get_job) plus the schema example cover the remaining usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 'slug' with an example at 100% coverage, so the baseline is 3. The description adds only that the tool looks up 'by slug', which is consistent with the schema but does not add meaning beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('full metadata for one sound'), and the lookup key ('by slug'). It also enumerates the metadata contents (download URLs, generation prompt, measured acoustics), which distinguishes it from siblings like search_sounds or generate_sound by making clear this is a single-item metadata retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have a slug and need full metadata for one sound, call this tool. However, it does not explicitly discuss when not to use it or how it compares to search_sounds (e.g., use search_sounds to find slugs) or get_job. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct role: generating, checking generation status, fetching metadata by slug, and searching. No overlap or ambiguity between them.
All tool names follow a clear verb_noun pattern (generate_sound, get_job, get_sound, search_sounds). Consistent snake_case and predictable resource-based naming.
Four tools cover the core workflow of a sound-generation/search service without excess. The count feels well-scoped and every tool earns its place.
The surface covers searching existing sounds, generating new ones, checking job status, and retrieving full metadata. No obvious gaps for the stated purpose; missing operations like deletion are not applicable in this domain.