Skip to main content
Glama
kvoltmer

Audionaut MCP Server

by kvoltmer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Export audio

export_audio

Render an Audionaut project or selected region to WAV, FLAC, AIFF, OGG, or MP3 offline without an audio device; the output file extension selects the format.

Instructions

Renders the project offline to an audio file (no audio device needed). The output's extension picks the format: .wav (8/16/24/32 bit), .flac (lossless and compressed, 16/24 bit, at most 8 channels per file), .aiff (8/16/24 bit), .ogg (Ogg Vorbis, lossy, at most 8 channels) or .mp3 (lossy, mono or stereo, at most 48 kHz). Lossy formats take bitrate_kbps instead of bit_depth. Pass region to bounce a single region instead - always dry, without any clip's gains or fades. Reports progress in 5% steps when the call carries a progressToken.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
trackNoTrack id, to disambiguate same-named regions
outputYesOutput path ending in .wav, .flac, .aiff, .ogg or .mp3 - the format follows the extension
regionNoBounce this region instead of the whole project
projectYesPath to the .audium project package (absolute paths recommended)
channelsNoOutput channel count (default 2)
bit_depthNoBit depth (default 24; not for .ogg/.mp3)
multi_monoNoWrite one mono file per channel instead
sample_rateNoSample rate in Hz (default 44100)
bitrate_kbpsNoBit rate for .ogg (64, 80, 96, 112, 128, 160, 192, 224, 256, 320, 500) or .mp3 (96, 128, 160, 192, 256, 320); default 192
start_secondsNoExport start position
length_secondsNoExport length (default: whole project)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.6.4
    • changedInput schema / properties / bit_depth / description
      Previous value: -"Bit depth (default 24)"New value: +"Bit depth (default 24; not for .ogg/.mp3)"
    • addedInput schema / properties / bitrate_kbps
      Added value: +{
+  "description": "Bit rate for .ogg (64, 80, 96, 112, 128, 160, 192, 224, 256, 320, 500) or .mp3 (96, 128, 160, 192, 256, 320); default 192",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}
    • changedInput schema / properties / output / description
      Previous value: -"Output .wav path"New value: +"Output path ending in .wav, .flac, .aiff, .ogg or .mp3 - the format follows the extension"
  2. First observedv0.2.0

TDQS

A4.3/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 burden and does so well: it discloses offline rendering, format-follows-extension behavior, per-format constraints (bit depths, channel caps, sample-rate limit), and the notable quirk that region bounces are dry without clip gains or fades. It omits overwrite/existing-file behavior and error handling, keeping it below a 5.

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-loads the core action in the first clause, then layers format rules and the region caveat. The format enumeration is lengthy but each entry carries a real constraint, so it is dense rather than wasteful.

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 an 11-parameter tool with no annotations and no output schema, the description covers format logic, conditional parameters, region semantics, and progress reporting. It is nearly complete; only failure/overwrite behavior for the output path is missing.

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 100%, so the baseline is 3, but the description adds genuine cross-parameter meaning the schema cannot express: lossy formats take bitrate_kbps 'instead of' bit_depth, channel limits per format, and the dry-bounce semantics of region. This is real added value beyond the field-level descriptions.

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 ('Renders the project offline to an audio file') with a clarifying scope constraint ('no audio device needed'). The purpose is unambiguous against siblings like import_audio or assemble, which do not export.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear conditional for the region path ('Pass region to bounce a single region instead') and explains format selection via extension. However, it never states when-not to use the tool or names an alternative sibling, so it falls short of explicit routing guidance.

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