Skip to main content
Glama

Generate Sound

lab_sfx

Generate or CLEAN UP a SOUND track other than music — sound effects, ambience/atmosphere, dialog, a voiceover, FOLEY scored to an existing clip, or the repair kinds that take an EXISTING recording apart instead of inventing one: denoise (take the noise out), split (separate it into stems), isolation (keep the voice, drop the rest). All of it goes through the same audio pipeline as lab_generate_music. ASYNCHRONOUS: the call returns immediately with a row whose audio_url is null and metadata.status is 'pending'. Nothing is playable yet. Poll lab_list_audio (matching audio_type) until that row's status is 'completed' and audio_url is set; a failed row refunds its credits and carries metadata.error. The backend picks the provider for the chosen art on its own — there is no tool parameter here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
artYesKind of track — sfx (a single sound effect), ambience (a continuous atmosphere/soundscape), dialog (a spoken line), voiceover (narration), foley (sound derived FROM an existing clip and synced to what happens in it — needs `video_id`, ignores `duration_seconds`, and takes its length from the source). The repair kinds work on a recording you already have and need exactly one source (`audio_id`, `video_id` or `audio_url`), never a prompt: denoise (take out hiss, hum and room noise), split (separate the recording into stems — one audio row per stem), isolation (keep only the voice, drop room, noise and music). Their length follows the source, so `duration_seconds` is ignored. Not 'music' — that stays lab_generate_music, it binds a different stem
stemsNoSPLIT ONLY: which parts to separate out. Left out, you get the voice and the rest of the recording, each part as its own audio row. Asking for a subset drops what you leave out — there is no combined everything-but-the-voice file, that would be a mixdown the provider never made.
promptNoWhat the sound should be. For sfx/ambience: name the source and character of the sound. For dialog/voiceover: the line or text to speak. Required for every art EXCEPT foley — foley watches the clip, so leaving it empty means 'take what you see', and a prompt merely steers it
audio_idNoREPAIR KINDS ONLY, and the best of the three ways to name a source: an existing audio row of this project (from lab_list_audio), which has an owner and an address that belongs to us. Chain it — denoise a row, then split the result. The row must already carry an audio_url; a pending one has no file yet.
get_costNo`true` reports the price and your balance WITHOUT generating anything and without spending quota. Not drawn from the lab_list_models catalog (that covers image/video models only) — audio pricing follows the provider FilmLab picks for `art`, and each kind is billed by its own unit: per run, per second, or per character. For the spoken kinds the price follows the length of your text, which the cost endpoint cannot take: the answer then names the provider and your balance and reports `cost_generations` as null rather than inventing a number — the real amount comes back with the call.
video_idNoThe clip to work from. For FOLEY it is required to RUN one; for the repair kinds it is one of the three ways to name a source, and the backend extracts the audio track from it. From lab_list_assets or the row an animate call returned; the clip must belong to this project. The backend measures its length and rejects sources it will not process, before anything is charged. A price question (`get_cost: true`) does NOT need it — the price follows a length, not a particular clip.
audio_urlNoREPAIR KINDS ONLY, and the last resort: a bare address of a sound file. It carries no owner, so nothing can be checked against the project — prefer `audio_id` or `video_id`. A provider address is copied into our own storage first, and if that fails the call is refused rather than stored with a deadline.
scene_refNoOptional scene label, stored on the row. Useful to tell several tracks of one project apart
project_idYesProject id (from lab_list_projects) — positive integer as string
duration_secondsNoDesired length in seconds. The backend clamps this to what the chosen provider actually supports for this `art` — dialog/voiceover ignore it entirely, the length follows the text, and foley ignores it too, its length follows the clip. The repair kinds ignore it as well: you clean up a file, not a stretch of it. One exception, and only for asking: in a `get_cost` query on foley or a repair kind, naming it prices THAT length instead of the ceiling. There is no lab_list_models entry for audio: the provider isn't a choice you make here, it's picked automatically per `art`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Discloses behavior well beyond the annotations (readOnlyHint=false, destructiveHint=false): the call is asynchronous and returns a row with null `audio_url` and status 'pending', nothing is playable yet, a failed row refunds credits and carries metadata.error, and the provider is auto-selected per `art` with no `tool` parameter. That async/flush/refund profile is exactly what an agent needs and cannot get from the structured fields.

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, then scope, then the async contract — a sensible order, and every sentence carries information. It is dense and leans on all-caps emphasis for keywords, which costs a little readability, but there is no filler.

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?

For an async, credit-spending generator with ten parameters and no output schema, it covers everything needed to call correctly: the eight art kinds and their source requirements, the async lifecycle and polling tool, the refund path, and the fact that return rows carry status/audio_url/metadata.error. Nothing material is missing.

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 all ten parameters in detail, and the description largely restates that (art kinds, the source-selection rules, duration handling). It adds only a small amount beyond the schema — chiefly that no `tool`/provider parameter exists here. Baseline 3 is appropriate when the schema carries the load.

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?

States a specific verb and resource ('Generate or CLEAN UP a SOUND track') and immediately scopes it against the sibling it could be confused with: 'other than music', then names lab_generate_music explicitly. It also enumerates the eight `art` kinds, so an agent knows exactly what this tool covers without opening the schema.

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 routing: music goes to lab_generate_music, the repair kinds (denoise/split/isolation) take an existing recording rather than a prompt, and foley requires `video_id`. It also prescribes the follow-up procedure — poll lab_list_audio matching `audio_type` until status is 'completed'. When-to-use, when-not, and the alternative tool are all stated.

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