Skip to main content
Glama

Generate Audio

generate_audio

Generate spoken audio from text: narration, a voiceover, a read-aloud script, or a multi-voice dialogue. Pass text (up to 3000 chars) — the words to be spoken. To speak in one of YOUR saved voices, pass voice with the voice NAME (or id): users speak plain language and never know ids, so resolve the name yourself (the voice tool, action "list", shows every saved voice) and never ask the user for an id. Reference voices, trained clones and preset voices are all routed correctly by kind. To match a voice instantly from a clip instead, pass reference_audio_url (a short clip) or up to 3 reference_audio_urls and address them as @Audio1, @Audio2, @Audio3 in the text for dialogue. Alternatively pass image_url to voice a scene from a picture (cannot combine with reference audio). Pass delivery to direct HOW it should sound in plain English — the voice (gender, age, accent, emotion, tone, speed), the mic and room, and any background sound or music — e.g. "soft, warm and a little flirty, unhurried, close clear mic, no echo"; it works with any saved voice (trained clones included), with clips, or with no voice. To fix the length of a sentence, put a time window in front of it inside text, e.g. [5.5s:8.0s] before the sentence. Optional speech_rate (-50..100), pitch (-12..12), loudness (-50..100). Before writing a delivery line, a multi-voice scene or timed lines, call load_workflow_playbook with id playbook/audio-prompting: it holds the prompt order, the voice description fields, the @Audio tagging rules, timing control and the limits. Returns a playable audio_url, duration_seconds, and generation_id (also saved to your library). A longer line (roughly 20 seconds of speech or more) may instead return status "rendering" with a request_id: the take is still being made and is not lost — call get_audio_status with that request_id every 15 seconds until audio_url comes back, and never re-run the same line. To find an earlier take, call list_my_audio.

Input Schema

NameRequiredDescriptionDefault
textYesThe words to speak / narrate / perform. Max 3000 chars. For dialogue, address voices as @Audio1, @Audio2, @Audio3. Optional per-sentence timing: put [start:end] seconds in front of a sentence, e.g. [5.5s:8.0s].
pitchNoOptional. Pitch, -12 to 12. 0 is normal.
voiceNoOptional. A saved voice — pass its NAME (or id); it is resolved and routed by kind automatically. Omit for a natural default voice.
formatNoOptional output format. Default mp3.
deliveryNoOptional. How it should SOUND, in plain English: the voice (gender, age, accent, emotion, tone, speed), mic and room, background sound or music — e.g. "young woman, warm Latin accent, soft, a little flirty, unhurried, clear close mic, no echo". Not the words themselves.
loudnessNoOptional. Loudness, -50 (quieter) to 100 (louder). 0 is normal.
image_urlNoOptional. Voice a scene from a picture. Cannot be combined with reference audio.
timestampsNoOptional. true returns sentences: [{start, end, text, words: [{start, end, text}]}] in seconds. For a two-voice scene the on-camera person's lines become speak_spans for sync3_lip_sync_video: when you wrote a time window like [3.6s:6.6s] in front of each line, use THOSE windows for her lines (the provider keeps them and they are exact); use sentences and words only for lines you did not time, and check every span holds only her words, because the provider can glue short lines into one sentence.
speech_rateNoOptional. Speaking speed, -50 (slower) to 100 (faster). 0 is normal.
reference_audio_urlNoOptional. A short clip URL to instantly match that voice.
reference_audio_urlsNoOptional. Up to 3 reference clip URLs for multi-voice dialogue.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / delivery / description
      Previous value: -"Optional. How it should SOUND, in plain English: the voice (gender, age, accent, emotion, tone, speed), mic and room, background sound or music — e.g. \"young woman, warm Latin accent, soft, a little flirty, unhurried, clear close mic, no echo\". Under 400 chars. Not the words themselves."New value: +"Optional. How it should SOUND, in plain English: the voice (gender, age, accent, emotion, tone, speed), mic and room, background sound or music — e.g. \"young woman, warm Latin accent, soft, a little flirty, unhurried, clear close mic, no echo\". Not the words themselves."
  2. Changed1 schema field changed
    • changedInput schema / properties / timestamps / description
      Previous value: -"Optional. true returns sentences: [{start, end, text}] in seconds for every spoken sentence. Use it for a two-voice scene: the sentences the on-camera person speaks become speak_spans for sync3_lip_sync_video, so one dialogue drives the lips and plays underneath."New value: +"Optional. true returns sentences: [{start, end, text, words: [{start, end, text}]}] in seconds. For a two-voice scene the on-camera person's lines become speak_spans for sync3_lip_sync_video: when you wrote a time window like [3.6s:6.6s] in front of each line, use THOSE windows for her lines (the provider keeps them and they are exact); use sentences and words only for lines you did not time, and check every span holds only her words, because the provider can glue short lines into one sentence."
  3. Changed1 schema field changed
    • addedInput schema / properties / timestamps
      Added value: +{
      +  "description": "Optional. true returns sentences: [{start, end, text}] in seconds for every spoken sentence. Use it for a two-voice scene: the sentences the on-camera person speaks become speak_spans for sync3_lip_sync_video, so one dialogue drives the lips and plays underneath.",
      +  "type": "boolean"
      +}
  4. Changed2 schema fields changed
    • addedInput schema / properties / delivery
      Added value: +{
      +  "description": "Optional. How it should SOUND, in plain English: the voice (gender, age, accent, emotion, tone, speed), mic and room, background sound or music — e.g. \"young woman, warm Latin accent, soft, a little flirty, unhurried, clear close mic, no echo\". Under 400 chars. Not the words themselves.",
      +  "type": "string"
      +}
    • changedInput schema / properties / text / description
      Previous value: -"The words to speak / narrate / perform. Max 2048 chars. For dialogue, address voices as @Audio1, @Audio2, @Audio3."New value: +"The words to speak / narrate / perform. Max 3000 chars. For dialogue, address voices as @Audio1, @Audio2, @Audio3. Optional per-sentence timing: put [start:end] seconds in front of a sentence, e.g. [5.5s:8.0s]."
  5. Changed2 schema fields changed
    • addedInput schema / properties / loudness
      Added value: +{
      +  "description": "Optional. Loudness, -50 (quieter) to 100 (louder). 0 is normal.",
      +  "type": "number"
      +}
    • changedInput schema / properties / voice / description
      Previous value: -"Optional. A saved voice id to speak in. Omit for a natural default voice."New value: +"Optional. A saved voice — pass its NAME (or id); it is resolved and routed by kind automatically. Omit for a natural default voice."
  6. Added

TDQS

A4.2/5.0
Behavior5/5

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

Goes well beyond the annotations: states the 3000-char cap, the ~20-second threshold at which the call returns status 'rendering' with a request_id, the 15-second polling cadence via get_audio_status, and the instruction never to re-run the same line. It also states that voice names must be resolved by the agent rather than asked of the user, which is behavioral policy the schema does not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence is well front-loaded, but the remainder is a single dense paragraph mixing voice resolution, reference audio, delivery, timing, numeric params, playbook, return values, and async polling. It is information-rich but unscannable, and several details repeat the schema descriptions verbatim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-param generative tool with no output schema, it covers what is returned (audio_url, duration_seconds, generation_id), the async exception path, and where to find earlier takes via list_my_audio. Nothing essential to a correct call is absent.

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 semantics: how @Audio1/@Audio2/@Audio3 map to reference_audio_urls, the [5.5s:8.0s] timing syntax placed inside text, and what 'delivery' should contain in plain English. Some of this duplicates schema text, which keeps it from a 5.

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?

Opens with a specific verb and resource plus concrete use cases (narration, voiceover, read-aloud, multi-voice dialogue), which is more than a restatement of the name. It does not, however, distinguish itself from close siblings like generate_speech and generate_dialogue, which an agent will see in the same list.

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 real routing guidance: use voice-by-name for saved voices, reference_audio_url for instant matching, image_url for scene voicing (explicitly cannot combine with reference audio), and it directs the agent to load_workflow_playbook before writing delivery lines or multi-voice scenes. Missing is any statement of when to pick this over generate_speech or generate_dialogue.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources