Skip to main content
Glama

Text to speech (TTS): natural voices, audio file

ai_speech
Read-only

Turn up to 300 characters of text into natural, human-sounding speech as an MP3 (base64), in English (40 voices) or Spanish (10 voices), with Deepgram Aura-2. Pick a voice by name or leave the default. Use for voice replies, narration, audio notes, accessibility and phone or chat bots. Example: text=Your payment was received. Thank you!. Price $0.01/call via x402 USDC or a card key (/credits); failed calls free. Reads or computes only and changes nothing; each call is charged, so repeats are not free.

Input Schema

NameRequiredDescriptionDefault
langNoLanguage: en or es (default en)
textYesText to speak, up to 300 characters
voiceNoVoice name. English: amalthea, andromeda, apollo, arcas, aries, asteria, athena, atlas, aurora, callista, cora, cordelia, delia, draco, electra, harmonia, helena, hera, hermes, hyperion, iris, janus, juno, jupiter, luna, mars, minerva, neptune, odysseus, ophelia, orion, orpheus, pandora, phoebe, pluto, saturn, thalia, theia, vesta, zeus. Spanish: sirio, nestor, carina, celeste, alvaro, diana, aquila, selena, estrella, javier. Default: luna (en), aquila (es)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / lang / description
      Previous value: -"Language: en, es, fr, zh, ja or ko (default en)"New value: +"Language: en or es (default en)"
    • changedInput schema / properties / lang / enum
      Previous value: -[
      -  "en",
      -  "es",
      -  "fr",
      -  "zh",
      -  "ja",
      -  "ko"
      -]New value: +[
      +  "en",
      +  "es"
      +]
    • changedInput schema / properties / text / description
      Previous value: -"Text to speak, up to 1,000 characters"New value: +"Text to speak, up to 300 characters"
    • addedInput schema / properties / voice
      Added value: +{
      +  "description": "Voice name. English: amalthea, andromeda, apollo, arcas, aries, asteria, athena, atlas, aurora, callista, cora, cordelia, delia, draco, electra, harmonia, helena, hera, hermes, hyperion, iris, janus, juno, jupiter, luna, mars, minerva, neptune, odysseus, ophelia, orion, orpheus, pandora, phoebe, pluto, saturn, thalia, theia, vesta, zeus. Spanish: sirio, nestor, carina, celeste, alvaro, diana, aquila, selena, estrella, javier. Default: luna (en), aquila (es)",
      +  "type": "string"
      +}
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the billing model ($0.01/call via x402 USDC or card key, failed calls free) and warning that repeats are not free, which explains the idempotentHint=false signal. It also confirms the read-only, side-effect-free nature and names the exact output format.

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 capability, limits, and cost are front-loaded in a tight three-sentence block with no filler, and the example is compact. The final sentence runs long by chaining side-effect, billing, and retry caveats together, but each clause carries information.

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 simple three-parameter tool with no output schema, the description covers input constraints, output format (MP3 base64), pricing, and safety. Minor gaps remain around response size limits and error behavior beyond 'failed calls free'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already enumerates every language and voice name plus defaults, so the description only restates the 300-character limit and the 'pick a voice by name or leave the default' behavior. It adds no usage nuance (e.g. when to prefer one voice or language) beyond the structured data.

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 concrete verb and resource ('turn text into natural, human-sounding speech as an MP3 (base64)') and pins down the provider, languages, voice counts, and character limit. An agent can immediately tell this is the text-to-speech tool rather than a transcription or chat sibling.

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 explicit positive use cases (voice replies, narration, audio notes, accessibility, phone/chat bots) and an inline example call. It never states when not to use it or names an alternative such as transcribe for the reverse direction, so routing against siblings is left to inference.

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