io.github.AudialAI/audial-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Sing lyrics in a reference voice

text2vox

Synthesize a sung vocal and matching MIDI from lyrics, a melody, and a reference voice clip, with per-note lyric alignment for precise control over how words map to notes.

Instructions

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.

Input Schema

Name	Required	Description	Default
`seed`	No	Seed for reproducible output.
`lyrics`	Yes	Lyrics to sing. With lyrics_mode 'per_note' this is pipe-delimited, one token per MIDI note, e.g. 'amazing\|-\|-\|grace\|-\|how\|sweet\|the\|sound'; otherwise it is ordinary text.
`midi_file`	No	MIDI melody (.mid). Give this or melody_audio_file.
`nfe_steps`	No	Synthesis steps; more is slower and cleaner.
`lyrics_mode`	No	How the lyrics line up with the melody. 'auto' (default): ordinary text, one word per MIDI note, aligned for you (word_timestamps_file helps). '1to1': the text is passed to the synthesizer untouched. 'per_note': exact control -- the lyrics are pipe-delimited with one token per MIDI note, in order. In per_note mode a token is either a syllable sung on that note ('grace') or a HOLD, which keeps the previous syllable going through this note: write a hold as '-' (preferred), '+', or an empty token (a double pipe). So 'amazing\|-\|-\|grace\|-\|how\|sweet\|the\|sound' sings 'amazing' across notes 1-3 and 'grace' across notes 4-5, and needs a MIDI file with exactly 9 notes. There is no rest token: a note that should be silent must not be in the MIDI. The token count has to equal the note count and the first token has to be a syllable, never a hold.	auto
`pitch_shift`	No	Semitones to shift the melody.
`cfg_strength`	No	Guidance strength.
`strict_pitch`	No	Force exact pitch to the melody.
`no_pitch_bends`	No	Disable pitch bends.
`reference_file`	Yes	Short clip of the reference voice (timbre).
`reference_text`	No	Transcript of the reference clip, if known.
`bend_smoothing_ms`	No	Pitch-bend smoothing window in ms.
`leading_silence_s`	No	Silence before the first note, seconds.
`melody_audio_file`	No	Audio whose melody is transcribed and followed, if no MIDI.
`word_timestamps_file`	No	Optional JSON word timings.

Output Schema

Name	Required	Description	Default
`tool`	Yes
`files`	Yes
`summary`	Yes
`metadata`	Yes
`output_dir`	Yes
`execution_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.5.0Oct 31, 2026

changedInput schema / properties / lyrics / description

Previous value: -"Lyrics to sing."New value: +"Lyrics to sing. With lyrics_mode 'per_note' this is pipe-delimited, one token per MIDI note, e.g. 'amazing|-|-|grace|-|how|sweet|the|sound'; otherwise it is ordinary text."

changedInput schema / properties / lyrics_mode / description

Previous value: -"auto (default) or an explicit lyric alignment mode."New value: +"How the lyrics line up with the melody. 'auto' (default): ordinary text, one word per MIDI note, aligned for you (word_timestamps_file helps). '1to1': the text is passed to the synthesizer untouched. 'per_note': exact control -- the lyrics are pipe-delimited with one token per MIDI note, in order. In per_note mode a token is either a syllable sung on that note ('grace') or a HOLD, which keeps the previous syllable going through this note: write a hold as '-' (preferred), '+', or an empty token (a double pipe). So 'amazing|-|-|grace|-|how|sweet|the|sound' sings 'amazing' across notes 1-3 and 'grace' across notes 4-5, and needs a MIDI file with exactly 9 notes. There is no rest token: a note that should be silent must not be in the MIDI. The token count has to equal the note count and the first token has to be a syllable, never a hold."

First observedv0.1.1Sep 29, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations only declare the generic non-read-only, open-world, non-idempotent profile; the description adds real operational context: a few minutes of latency, that it consumes one run, and that outputs land in a new results folder. It does not address whether re-running with the same seed is safe or what auth is needed, which keeps 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?

Four short sentences, front-loaded with the core action, then requirements, then mode guidance, then cost/output. Slight duplication of the schema's lyrics_mode guidance, but nothing is wasted.

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 15-parameter tool with an output schema and annotations, the description covers the essentials an agent needs: required inputs, melody source alternatives, mode selection, latency/cost, and where results go. Optional tuning parameters are left entirely to the schema, which is acceptable given full coverage.

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 baseline is 3; the description earns above that by prioritizing lyrics_mode values ('per_note' is the one that gives exact control) and cross-referencing the detailed schema entries. It stops short of covering the many synthesis knobs (nfe_steps, cfg_strength, strict_pitch), which remain schema-only.

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 ('Synthesize a sung vocal (and MIDI)') plus the three required inputs (lyrics, melody, reference voice). That combination is distinctive enough to separate it from generate_music and generate_samples without opening any schema.

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?

Gives concrete prerequisites ('Needs both a reference clip of the voice and a melody, as MIDI or audio') and steers mode choice toward 'per_note' for exact control. However, it never names an alternative sibling or states when NOT to use this tool, leaving routing to inference.

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