Skip to main content
Glama

createVoice

Design a new voice from a character description (such as "deep-voiced warrior" or "cheerful young girl") and have it speak a short line of text, returning a sample of that newly created voice. Both voice_description and text are required, the spoken text is limited to 200 characters or the call returns HTTP 400, and type selects "human" or "non-human" voices. The job result is a single audio result containing a URL. Credits are held when the job is accepted and refunded if it fails or is cancelled. Use this to invent and audition a voice from a description; use createSpeech for text-to-speech that clones a specific voice from an audio sample, and createSpeechPreset for text-to-speech using a named preset voice. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type audio). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).

Credits: This endpoint consumes 1 credits per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestBodyYesPayload for generating a voice sample from a character description

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / requestBody / properties / request_id / description
      Previous value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."
    • changedInput schema / properties / requestBody / properties / text / description
      Previous value: -"Text for the voice to speak (max 20 words)."New value: +"Text for the voice to speak (max 200 characters)."
  2. Changed4 schema fields changed
    • removedInput schema / properties / requestBody / properties / augment_prompt / default
      Removed value: -true
    • changedInput schema / properties / requestBody / properties / augment_prompt / description
      Previous value: -"Augment the prompt behind the scenes. Disable to have more control."New value: +"Augment the prompt behind the scenes. Disable to have more control. Default: true."
    • removedInput schema / properties / requestBody / properties / type / default
      Removed value: -"human"
    • changedInput schema / properties / requestBody / properties / type / description
      Previous value: -"Type of voice to generate."New value: +"Type of voice to generate. Default: \"human\"."
  3. Changed1 schema field changed
    • changedInput schema / properties / requestBody / properties / request_id / description
      Previous value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."
  4. Changed1 schema field changed
    • addedInput schema / properties / requestBody / properties / request_id
      Added value: +{
      +  "description": "Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint.",
      +  "type": "string"
      +}
  5. Added

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are present, so the description carries the full burden, and it delivers: async {id,status} response, polling via getApiJob, final audio result with URL, HTTP 400 on text over 200 characters, credit hold/refund behavior, 1-credit cost, and request_id idempotency. This is rich behavioral disclosure well beyond the input schema.

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 longer than minimal but densely packed; each section contributes purpose, alternatives, constraints, async contract, or credits. It is front-loaded with the main purpose and clearly structured. Minor redundancy and deferral to server instructions prevent a 5.

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 a complex async job with no output schema, the description covers everything needed to invoke correctly: required inputs, initial response, polling route, final audio URL, credit semantics, and sibling selection. The pointer to server instructions for the full job/credit contract is acceptable given the amount already disclosed.

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 adds value by emphasizing voice_description and text are required, translating maxLength into a concrete HTTP 400 failure, explaining type's human/non-human selection, and connecting request_id to listGenerations. It does not mention augment_prompt, but the schema documents it thoroughly.

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?

Opens with a specific verb-resource pair ('Design a new voice from a character description') and adds the 'speak a short line of text, returning a sample' behavior. It explicitly contrasts itself with createSpeech and createSpeechPreset, so an agent can distinguish it from siblings without opening their schemas.

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?

Provides explicit routing: 'Use this to invent and audition a voice from a description; use createSpeech for ... clone ... createSpeechPreset for ... named preset voice.' It also states required fields, the 200-character constraint, type selection, request_id tagging, and async polling, leaving no ambiguity about when to choose it.

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.