io.github.AudialAI/audial-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AUDIAL_API_KEY | Yes | Your Audial API key, required. From https://audialmusic.ai. | |
| AUDIAL_USER_ID | Yes | Your Audial user id, required. From https://audialmusic.ai. | |
| AUDIAL_RESULTS_DIR | No | Directory where Audial results are downloaded. | ~/Audial |
| AUDIAL_API_BASE_URL | No | Audial API base URL. Defaults to the production API. | |
| AUDIAL_JOB_TIMEOUT_S | No | Job timeout in seconds. | 900 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Audial runs hosted audio tools. Give tools full local file paths. Results are written to the user's Audial results folder and returned as file paths; tell the user where they are. Jobs take from a few seconds (analyze) to a few minutes (stem_split, generate_music, sound2vital, sound2serum, text2vox); progress notifications report elapsed time. segment takes about half a minute and returns an analysis_id; audio_features, tag_audio, get_lyrics and generate_samples take it to add to that analysis (given a file, they run segment first). Tags, lyrics and sample packs wait a few minutes after a new analysis while its stems are made. pipeline_status looks up a pipeline (generate_samples on a file) by id. Audial's workers scale to zero, so the first job after an idle period spends extra time starting one: that shows up as a 'Warming up the machine' progress line, worth relaying to the user as the reason for the wait; service_status says in advance which tools are warm. An analysis counts as one run and everything added to it is included; every other job but analyze counts as one run; a failed run does not count. Accounts without a subscription get a small free allowance and then need a subscription: relay the error text if one is returned. No API key is needed: if the user is not signed in, the first tool call opens a sign-in page in their browser and continues once they approve. If a tool instead returns a sign-in link, give the user that link and the code, and retry when they say they have approved it. sound2vital and sound2serum model one isolated sound, so check the input first: a file that is a loop, melody or drum pattern (a tempo or 'loop' in its name is a clue) gives a poor preset even under 20 s, so say so before running it and suggest trimming it to one note. After either tool, relay anything in summary about the match to the user.
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| stem_splitA | Split a track into separate instrument stems, optionally retimed and rekeyed. Use for a full song or mix when the user wants vocals, drums, bass or an instrumental on their own. For tempo and key alone use analyze; for sections use segment. Takes a few minutes and counts as one run. Stems go to a new results folder; the source is unchanged. |
| analyzeA | Analyze a track: BPM, key, loudness and other characteristics. Use this first whenever the user asks for tempo, key or loudness. It is the fastest tool
(seconds), does not count as a run, and changes nothing. The answer is in |
| segmentA | Find song sections, tempo and bars (about half a minute). Use for song structure. Send the mix: no stems needed, and it counts as one run. The result
has the sections (with their phrases) and a tempo map. Beats and bars are not listed one by
one: |
| audio_featuresA | Measure energy, danceability, loudness, mode, key and tatum, for the song and each section. Give the analysis_id from segment: nothing is uploaded and it is included in that analysis's
run. A file_path runs segment first (one run). Needs no stems, so it can run straight after
segment. Energy and danceability run 0-1: energy reflects loudness, rhythmic activity and
low end; danceability, how strong and regular the beat is. Both are measured per section,
so a drop reads higher than its breakdown. Loudness is in LUFS. The values are in
|
| tag_audioA | Tag a track: genre, moods, instruments and artist tags for the mix and each part, plus a written description. Give the analysis_id from segment: nothing is uploaded and it is included in that analysis's
run. A file_path runs segment first (one run). Tags read the track's stems, which Audial
makes automatically after each analysis: right after a new analysis this waits for them (a
few minutes). The tags are in |
| get_lyricsA | Transcribe a track's lyrics as timed lines. Give the analysis_id from segment: nothing is uploaded and it is included in that analysis's
run. A file_path runs segment first (one run). Lyrics read the vocal stem, which Audial makes
automatically after each analysis: right after a new analysis this waits for it (a few
minutes). |
| masterA | Master a mix, optionally matching a reference track. Use for a finished stereo mix, not for separate stems. Pass a reference track when the user names one. Takes a few minutes and counts as one run. The master goes to a new results folder; the source is unchanged. |
| generate_samplesA | Extract a sample pack (one-shots and loops) from a track. Use when the user wants drum hits or loops taken from a finished track. With the
analysis_id from segment, the pack is built from that analysis's sections and the stems
Audial made for it: nothing is uploaded and it is included in the analysis's run (right
after a new analysis it waits a few minutes for the stems). With file_path it runs the
|
| generate_midiA | Transcribe an audio file to MIDI. Use to get notes out of audio. On a full mix, run stem_split first and transcribe the stem you want. Counts as one run. MIDI files go to a new results folder; the source is unchanged. |
| generate_musicA | Generate music with the Audial music model. Text to music, covers, remixes, lego (re-render with one track emphasised), or analysis (understand). Use for new or transformed music, not to edit an existing mix: that is master or stem_split. Takes a few minutes and counts as one run, and audio goes to a new results folder. |
| sound2vitalA | Turn one isolated sound into an editable Audial Synth preset. Not for loops or melodies, which give a poor preset. If the result's summary says the match is weak, tell the user and suggest trimming the input to one note. |
| sound2serumA | Turn one isolated sound into an editable Xfer Serum 2 preset. Not for loops or melodies, which give a poor preset. If the result's summary says the match is weak, tell the user and suggest trimming the input to one note. |
| text2voxA | Synthesize a sung vocal (and MIDI) from lyrics, a melody and a reference voice. Needs both a reference clip of the voice and a melody, as MIDI or audio. lyrics_mode decides how the lyrics are lined up with the melody's notes; "per_note" is the one that gives exact control. See the lyrics_mode and lyrics descriptions. Takes a few minutes and counts as one run. Audio and MIDI go to a new results folder. |
| service_statusA | Which Audial tools have a worker awake right now, and what a cold one will cost. Audial's GPU workers scale to zero. A tool reported |
| pipeline_statusA | Look up an Audial pipeline by id: its state, each step, and the outputs so far. Useful when a generate_samples call on a file, or a segment call with |
| list_resultsA | List previous Audial results in the results folder, newest first. Use when the user asks where an earlier output went. Reads the local folder only: no account needed and nothing is sent anywhere. |
| accountA | Show whether this computer is signed in to Audial, and as whom. Use when a tool reports a credentials problem or the user asks which account is in use. Reads local settings only. |
| sign_inA | Sign in to Audial through the user's browser. Opens an approval page and waits for it. Not needed before other tools: they start the same sign-in when nobody is signed in. |
| sign_outA | Sign out of Audial on this computer and disconnect it from the account. Only when the user asks to sign out or switch accounts. The next job asks them to sign in again. Results already downloaded stay where they are. |
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 19 tools
Most tools have sharply distinct jobs, and descriptions actively redirect between near-neighbors (e.g. 'for tempo and key alone, analyze is quicker' vs segment; sound2vital vs sound2serum differ only by target synth but are explicitly named). The main soft spot is analyze vs audio_features, which both report key/loudness/mode-like data, and audio_features/tag_audio/get_lyrics share the same analysis_id-or-file_path input shape, so an agent must read descriptions carefully to pick correctly.
Names are all lowercase snake_case, but the verb convention is mixed: verb_noun (get_lyrics, list_results, generate_samples, sign_in), bare noun/verb (segment, analyze, master, account), and a 'X2Y' pattern (sound2vital, sound2serum, text2vox). It stays readable, but there is no single predictable pattern an agent can rely on to infer an unlisted operation.
19 tools is on the heavy side, but the domain is genuinely broad (analysis, stems, mastering, MIDI, music generation, presets, vocals) and each processing tool maps to a distinct output artifact. The auth/status cluster (account, sign_in, sign_out, service_status, pipeline_status, list_results) adds some overhead but each serves an operational purpose.
Coverage of the audio lifecycle is strong: cheap analysis, segmentation, features, tags, lyrics, stems, sample packs, mastering, MIDI, generation, presets, vocal synthesis, plus auth, worker status, pipeline polling and local result listing. Gaps are minor but real: no cancel/delete of jobs or results, and no direct fetch of a single saved result by id beyond pipeline_status/list_results.