Skip to main content
Glama
Sign In
OtoMaker

OtoMaker

Official
by og3-lab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

process_audio

Post-processes and exports audio clips via trim, silence cut, mono, normalize, loop crossfade, fades; writes WAV/OGG/FLAC plus JSON sidecar.

Instructions

Post-process and export a clip: trim, trim silence, mono, normalize (peak or LUFS), seamless loop, fades, then write 48 kHz/44.1 kHz WAV, OGG Vorbis or FLAC (+ .json sidecar). The input file is not modified. Steps run in that order. Does not load any model.

Input Schema

NameRequiredDescriptionDefault
loopNoMake a seamless loop by crossfading the tail into the head (output gets shorter by loop_crossfade_ms).
monoNoDownmix to mono (common for positional game SFX).
titleNoOutput file name stem. Default: <input>_proc.
formatNowav = 24-bit PCM; ogg = Ogg Vorbis (Unity/Godot); flac = 24-bit lossless.wav
normalizeNonone = only the safety ceiling; peak = scale so the peak hits peak_ceiling_db; loudness = EBU R128 to target_lufs, two-pass, linear gain when the true-peak limit allows it, otherwise ffmpeg's dynamic mode (reported as loudnorm_mode); the peak ceiling is applied afterwards.none
fade_in_msNo
end_secondsNoTrim: keep until here (default: end).
fade_out_msNo
input_audioYesAbsolute path to an audio file (any format soundfile/ffmpeg reads).
ogg_qualityNoVorbis quality 0.1–1.0 (0.6 ≈ 190 kbps stereo).
sample_rateNo48000 for video; 44100 keeps the model's native rate (no resampling).
target_lufsNoloudness mode: -14 streaming/video, -16 game BGM, -23 broadcast. SFX are usually peak-normalized instead.
trim_silenceNoCut leading/trailing silence (useful for one-shot SFX).
start_secondsNoTrim: keep from here.
peak_ceiling_dbNoPeak ceiling / target in dBFS.
loop_crossfade_msNoLoop crossfade: ~50–200 ms for rhythmic BGM cut on a bar, 500–2000 ms for ambience.
silence_threshold_dbNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.8/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses key non-obvious behavior: the input is not modified, steps execute in a fixed order, no model is loaded, and a .json sidecar is emitted alongside the exported audio. It still does not describe error/overwrite behavior or return values, but the central behavioral traits are covered.

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?

Three tightly packed sentences with the main operation and constraints front-loaded. It avoids repetition and every sentence contributes needed context.

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 17-parameter tool with high schema coverage, it explains the overall pipeline, non-destructive behavior, output formats, and sidecar. The main remaining omission is that, with no output schema, it does not state the return value or exact output location/overwrite semantics.

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 coverage is 82%, so most parameters are already documented in structured form. The description adds useful sequencing context ('Steps run in that order') and summarizes normalize/export choices, but it does not add much per-parameter meaning beyond the schema.

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 ('post-process and export') and resource ('a clip'), and enumerates the transformations and output formats. It distinguishes itself from generation by saying it does not load a model and leaves the input unmodified, though it never names edit_audio or explicitly contrasts with it.

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 use when a clip needs post-processing/export and lists supported operations, but it gives no explicit when-to-use/when-not guidance or named alternatives such as edit_audio versus process_audio. It only weakly signals that this is the final processing/export step.

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

Deploy Server

Other Tools