Skip to main content
Glama

Add sfx

add_sfx

PROJECT-SCOPED: this call acts only on the explicit project_id and returns the project identity with its result. Punctuate a MOMENT with a one-shot sound effect — a whoosh into a real turn, a click on a shown button press, an impact on the payoff. OPTIONAL, never a rule: choose it only when the moment clearly earns a sound (a podcast or talking short carries zero by default and at most 1-2; sounds with no clear on-screen reason make an edit look childish). Each needs a visual partner (something on screen changes within ~50 ms of its hit), never sits as a bright sound (ding, pop, click, shutter) on the onset of a payoff or emphasis word, and never puns on the spoken word (a shutter on 'pictures', a cash register on 'money' with nothing on screen showing it). Analysis, metadata, and deterministic preview AUDIO CHECK are useful evidence; uncertainty is something to judge rather than a reason the tool becomes unavailable. storage_key is 'sound:' for an approved library recording (list_sound_library), or an exact key from list_assets(kind='music') for a sound the user supplied — never invent one, never a web sound. at is an OUTPUT-timeline second (the edited program, not source time). For a library recording at is the moment it HITS — the visual frame its peak belongs on: the tool starts it early by its measured peak (a riser therefore ends on at; typing starts at at), skips into the file when the hit is too close to 0s, and reports where the peak lands and the span it plays — never pre-roll by hand. Any other sound starts at at. This is NOT background music: it plays once and never ducks. offset_s starts inside source audio — use it when an extracted clip contains the requested hit late in a long track. purpose records the nameable visible/editorial event for later final-mix review; do not add anonymous decorative sounds. dur_s (seconds from where it starts playing) stops a long recording (typing) when its on-screen event stops, with a short fade; long library tails (impact_1) already stop at their measured fade point unless dur_s asks for more. gain_db: leave it UNSET for a library recording — the tool measures the voice's short-term loudness at the hit and sets the gain for the sound's role (whoosh/swish ~8 dB under the voice, ding/pop/click/tick/shutter ~10 under, typing 14 under, an impact louder only below 150 Hz) and reports a MIX line; an explicit gain_db wins and is reported the same way. Other sounds default to -6dB. The result's CHECK lines flag a sound with no visual partner, on a payoff word's onset, a literal pun, a reflexive opening whoosh, a level that is inaudible or too hot, and more than 1-2 sounds in a talking short; a bright library sound on a payoff word's onset is NUDGED to a visual partner in the neighbouring speech gap when one is within reach (a pun, or a sound whose action is shown on that frame, is reported and left where it is).

Input Schema

NameRequiredDescriptionDefault
atYes
dur_sNo
gain_dbNo
purposeNo
offset_sNo
project_idYesRequired immutable scope for this call. Copy the id from list_projects/open_project/project_state; the active-project pointer is never used to guess.
storage_keyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / dur_s
      Added value: +{
      +  "type": "number"
      +}
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Goes far beyond the annotations (which only cover safety flags) by disclosing behavior an agent could not otherwise predict: the tool pre-rolls a library recording to land its measured peak on `at`, skips into the file near 0s, auto-measures voice loudness and sets gain by sound role unless gain_db is given, adds a short fade for dur_s, and reports CHECK/MIX lines plus NUDGE behavior on payoff-word onsets. Idempotency and side effects are consistent with the non-readonly annotations.

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?

The opening PROJECT-SCOPED clause and the core purpose are front-loaded, and nearly every sentence carries operational detail. It is nonetheless a dense ~350-word block; a few enforcement clauses (pun, bright-sound-on-payoff rule) are restated in both the setup and the CHECK sentence, which costs some length.

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 a 7-parameter mutation with no output schema, the description covers input semantics, the auto-gain/peak-alignment behavior, and what the result reports (CHECK lines, MIX line, peak position and played span), so an agent can call it and interpret the response without further information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 14% (only project_id is described), so the description carries the burden and does: storage_key's two valid forms ('sound:<id>' vs. list_assets(kind='music') key) with an explicit 'never invent one', `at` as an OUTPUT-timeline seconds value distinct from source time, offset_s as source-internal offset, purpose's review role, dur_s's fade semantics, and gain_db's unset/default behavior.

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 — 'Punctuate a MOMENT with a one-shot sound effect' — and immediately distinguishes itself from the nearest sibling by declaring 'This is NOT background music: it plays once and never ducks,' which separates it from add_music/add_library_music. The examples (whoosh into a turn, click on a button press) make the intent concrete.

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?

Explicitly frames the tool as OPTIONAL and never a rule, gives quantitative guidance ('a podcast or talking short carries zero by default and at most 1-2'), and states the visual-partner precondition, so an agent knows both when and when not to call it. It also directs the agent to list_sound_library / list_assets for the storage_key and names remove_sfx/move_sfx territory implicitly through scoping.

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.