Skip to main content
Glama

Generate a sound effect

generate_sfx

Generate a sound effect from a description: an impact, a boom, a whoosh, a riser, a swoosh, a click, a pop, a camera shutter, footsteps, a crowd, an ambience. Describe the one sound you want, as a sound designer would; each call makes one sound. Ask for clean, tonal sounds (a soft crystal chime, a soft metal tap, a low swell): words like shimmer, sparkle, static, hiss or electric give white noise. It answers at once with a Job ID and the media is made in the background: start every generation you need, keep working, then call wait_for_jobs with all their Job IDs to get each Asset ID for patch_film. With its Asset ID comes its measured placement and volume: where its loudest point is, so it lands on the action, and the volume that puts it under the music, level with it or on the one hero hit. Uses about 0.76 credits a second: a 3-second hit uses 3 credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
loopYestrue makes a sound that repeats without a seam, for an ambience or a bed under a long scene. false for a hit, a whoosh or a riser.
promptYesThe sound, in plain words: what makes it, how it starts, moves and ends, and that it is clean and tonal. "A soft crystal chime ringing out over 1 s, clean and tonal, no noise or static", "a soft metal tap", "a low swell", "a deep cinematic boom with a long sub-bass tail". Words like shimmer, sparkle, static, hiss or electric give white noise. Up to 1000 characters.
projectIdYesThe project this call runs on without changing the open project. null (or leaving it out) uses the open project. wait_for_jobs takes the projectId of the calls that started the jobs.
durationSecondsYesLength in seconds, 0.5 to 22: a click or a pop 0.5 to 1, a hit or a whoosh 1 to 3, a boom with its tail 3 to 5, a riser as long as the build, an ambience or a bed up to 22.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / prompt / description
      Previous value: -"The sound, in plain words: what makes it, its character, and how it starts and ends. \"A deep cinematic boom, a trailer impact with a long sub-bass rumble tail\", \"a fast airy whoosh, left to right\", \"a soft UI pop\", \"a crowd of thousands cheering in a stadium\". Up to 1000 characters."New value: +"The sound, in plain words: what makes it, how it starts, moves and ends, and that it is clean and tonal. \"A soft crystal chime ringing out over 1 s, clean and tonal, no noise or static\", \"a soft metal tap\", \"a low swell\", \"a deep cinematic boom with a long sub-bass tail\". Words like shimmer, sparkle, static, hiss or electric give white noise. Up to 1000 characters."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare readOnly=false, idempotent=false, openWorld=true, destructive=false; the description goes well past that by disclosing the asynchronous job pattern (returns a Job ID at once, media rendered in the background), the credit cost (about 0.76 credits/second), and that each Asset ID carries measured loudest-point placement and volume. This is exactly the extra behavioral context annotations cannot express, and nothing contradicts destructiveHint=false.

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?

Front-loaded with purpose and concrete sound examples, and the paragraph flows logically into workflow then cost. It is dense but largely earns its length; however, the duration bands and the white-noise word list restate what the schema already carries, which is avoidable redundancy.

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?

With no output schema, the description carries the return-value burden and does so: Job ID immediately, Asset ID later via wait_for_jobs, plus placement and volume metadata and the patch_film handoff. Cost and credit math are also given, leaving no material gap for an agent to call this correctly.

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%, so the schema already documents prompt, loop, projectId and durationSeconds – and much of the description's prompt/duration guidance is duplicative of those field descriptions. The description adds only the marginal constraint that each call produces exactly one sound, so the baseline 3 for schema-driven params is appropriate.

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?

"Generate a sound effect from a description" is a specific verb+resource, immediately distinguishing it from siblings like generate_music, generate_speech and generate_video. The enumeration of target sounds (impact, boom, whoosh, riser, ambience) further pins down the exact output domain, and the async-return model is stated upfront.

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?

Gives explicit when-to-use guidance via loop semantics (true for ambience/bed, false for hit/whoosh/riser) and duration bands per sound type. It also prescribes the workflow: start every generation you need, keep working, then call wait_for_jobs with all Job IDs to obtain each Asset ID for patch_film. That names the sibling handoff explicitly.

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.