Skip to main content
Glama

audio_generate

Generate spoken audio from written text for voiceovers, narration, ad reads, or character lines. Create one or multiple clips per request using your selected voice.

Instructions

For a user's voiceover request, load the generating-audio skill BEFORE calling this — it picks the right model and voice and prepares the script for reading aloud (this tool does none of that, and calling it raw gives a flat, mispronounced read). Turn written text into spoken audio: voiceovers, narration, ad reads, character lines, or any script read aloud. Pass requests: ONE object per clip (wrap even a single clip — { requests: [ { text } ] }); add more objects (up to 10) to generate DIFFERENT lines in one call — a single approval covers the batch. Each result carries the spoken audio plus a local file path, or a structured error with a hint. This generates speech and nothing else: no sound effects, music, or ambience, no re-voicing an existing recording, and no dubbing a video. If the user asks for one of those, say so plainly rather than substituting a different tool. Every request needs a voice — the voice_id of a row from list_voices. There is no default voice. Models differ in expressiveness, language coverage, speed, price, and per-request character limit — call list_audio_models to compare them. Set dry_run=true to preview the exact requests without generating (no credits spent).Each entry in results is one of three things: finished media; a {status:"pending", ...} job handle to rejoin with job_status; or a failure carrying ok: false and an error. A failed entry is terminal — report its error and never poll or re-submit it. Read every entry rather than the top-level counters alone.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNoIf true, return the requests that would be sent (keys masked), make no API call.
requestsYesOne object per audio clip (wrap even a single clip); add more objects to generate different lines in one call (up to 10).
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: there is no default voice, raw calls produce flat/mispronounced audio, dry_run previews without spending credits, results can be finished media, pending jobs, or terminal failures, and failed entries should not be polled. It also clarifies what the tool does NOT do, such as dubbing or sound effects.

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?

The description is long but tightly packed with actionable information. It is front-loaded with a critical prerequisite warning, and each subsequent section covers a distinct aspect (purpose, request format, result handling, exclusions, voice/model requirements). It could improve by placing the core purpose statement first, but overall no sentence is wasted.

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?

Despite lacking an output schema, the description fully explains return values (audio, path, structured errors, pending job handles), error handling (terminal failures, rejoin via job_status), and external dependencies (list_voices, list_audio_models). It also covers the batch approval and dry_run semantics, making the tool self-sufficient for correct invocation.

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 description coverage is 100%, so the baseline is 3. The description adds value by explaining the requests array structure (wrap single clip, up to 10), emphasizing the required voice field, and clarifying the dry_run behavior—information that goes beyond the schema's per-property descriptions. The added context is meaningful but not extensive enough to warrant a 5.

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?

The description clearly states the tool converts written text to spoken audio, enumerating use cases (voiceovers, narration, ad reads, character lines), and explicitly excludes other audio tasks (sound effects, re-voicing, dubbing), which distinguishes it from sibling tools like video_generate and image_generate.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance (voiceover requests) and prerequisites (load the generating-audio skill, call list_voices, call list_audio_models). It also gives clear when-not-to-use instructions, naming alternatives and telling the agent to decline non-speech requests rather than substitute another tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SupercmoHQ/superCMO-skills'

If you have feedback or need assistance with the MCP directory API, please join our Discord server