OtoMaker
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HF_HOME | No | Hugging Face cache for the model downloads. | %USERPROFILE%\.cache\huggingface |
| OTOMAKER_HOME | No | Data folder: the runtime and outputs go here. | the OtoMaker folder; %LOCALAPPDATA%\OtoMaker when installed with uvx |
| OTOMAKER_FFMPEG | No | Full path to ffmpeg.exe. | ffmpeg on PATH |
| OTOMAKER_BACKEND | No | Backend to use: sa3-tflite (CPU) or sa3-comfy (ComfyUI). | sa3-tflite |
| OTOMAKER_FALLBACK | No | Backend for a generate_audio call when ComfyUI cannot be reached, e.g. sa3-tflite. | off |
| OTOMAKER_SA3_MODEL | No | Model to use: sm-music, sm-sfx (up to 120 s) or medium (up to 380 s). | sm-music |
| OTOMAKER_COMFY_FREE | No | Set to 1 to let unload_models and the idle unload send /free to ComfyUI. | 0 |
| OTOMAKER_COMFY_HOST | No | Address of ComfyUI for the sa3-comfy backend. | 127.0.0.1:8188 |
| OTOMAKER_OUTPUT_DIR | No | Where audio files are written. | <data folder>\outputs |
| OTOMAKER_SA3_DECODER | No | TFLite decoder: same-s or same-l. | the upstream pairing |
| OTOMAKER_SA3_THREADS | No | CPU threads for the TFLite runtime. | physical cores, at most 10 |
| OTOMAKER_SA3_PRECISION | No | TFLite precision: w8a8 or fp32. | w8a8 |
| OTOMAKER_SA3_TFLITE_DIR | No | The optimized\tflite folder of the Stable Audio 3 runtime. | <data folder>\stable-audio-3\optimized\tflite |
| OTOMAKER_IDLE_UNLOAD_MIN | No | Free the models after this many idle minutes (0 = never). | 10 |
| OTOMAKER_SA3_AUTO_DOWNLOAD | No | Set to 1 to let the runtime download missing model files on first use. | 0 |
| OTOMAKER_COMFY_LENGTH_SUFFIX | No | Set to 1 to append 'Length: N seconds' to the prompt for ComfyUI; 0 sends the prompt as is. | 1 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generate_audioA | Generate BGM, instrument loops/stems or sound effects from text with Stable Audio 3 (runs locally). Returns one WAV path per candidate. |
| edit_audioB | Edit existing audio with Stable Audio 3: variation (audio-to-audio), inpainting a time range, or continuation/extension. Returns one WAV path per candidate. |
| process_audioA | 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. |
| unload_modelsA | Free the memory held by the loaded models now (they reload on the next call). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
The four tools target clearly distinct stages: text-to-audio generation, model-based editing of existing audio, deterministic post-processing/export, and memory cleanup. Generate vs. edit could superficially overlap, but descriptions explicitly separate text-conditioned creation from audio-to-audio variation, inpainting, and continuation.
All tools follow a consistent snake_case verb_noun pattern: generate_audio, edit_audio, process_audio, unload_models. The only variation is the noun (audio vs. models), which accurately reflects the operation.
Four tools is well-scoped for an audio generation/editing/export server. Each tool maps to a necessary lifecycle stage, and there is no redundant surface area.
The surface covers the core lifecycle: generate audio, edit it, post-process/export it, and unload models. Minor gaps exist around explicit model loading/status or audio metadata inspection, but these are not essential given the returned WAV paths and automatic model reload behavior.