Skip to main content
Glama

normalize_audio

Sets dialogue gain so the edit's loudest peak reaches a target dB level, keeping takes balanced or leveling each clip separately.

Instructions

Set dialogue gain so the loudest peak of the edit sits at target_peak_db (default −2 dB). One shared gain by default so takes stay balanced; per_clip=True levels each clip separately. Measures only the parts used in the edit. Music/connected audio is left alone unless listed in refs.

Input Schema

NameRequiredDescriptionDefault
refsNo
per_clipNo
target_peak_dbNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does well: it discloses that gain is shared across takes by default, that only edit-used portions are measured, and that music/connected audio is excluded unless listed in refs. Missing are reversibility/undo and permission notes, but the scoping disclosure is substantive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four dense sentences, each adding a distinct fact — gain target, shared-vs-per-clip behavior, measurement scope, and exclusion rule. The controlling behavior is front-loaded with no filler.

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?

For a 3-parameter mutation tool with no annotations and no output schema, the description covers what is affected, what is measured, and what is skipped. It leaves open what is returned and whether the change is undoable, which an agent would benefit from knowing.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate, and it does: target_peak_db gains a unit/default (−2 dB), per_clip gains a semantic contrast (each clip separately vs shared gain), and refs gains meaning (list music/connected audio to include). Only refs' exact format (clip references vs names) remains unclear.

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 and resource: sets dialogue gain so the loudest peak sits at target_peak_db. This clearly distinguishes it from measure_loudness (reads) and set_volume (manual value). It does not explicitly name siblings, so a 4 rather than a 5.

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?

The description implies usage through parameter behavior (shared gain keeps takes balanced; per_clip=True levels each clip) and scoping (music/connected audio left alone unless in refs). It never says when to prefer this over measure_loudness or set_volume, so guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.