Skip to main content
Glama
hedging8563

TokenLab MCP Server

by hedging8563
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Create speech

create_speech

Convert text into spoken audio with Text-to-Speech, supporting multiple voices, models, and formats. Ideal for voiceovers, accessibility, or audio content.

Instructions

Generates audio from the input text (Text-to-Speech).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputYesText to synthesize.
modelNoTTS model. Query GET /v1/models?recommended_for=tts for the current shortlist.tts-1
speedNoSpeech speed for model families that support it.
voiceNoVoice selector for OpenAI-compatible, Gemini, xAI, and MiniMax-compatible speech models. Some MiniM…
promptNoOptional speaking style prompt for Gemini TTS models.
voice_idNoVoice selector for MiniMax-compatible speech models.
temperatureNoSampling temperature for Gemini-compatible TTS models.
instructionsNoOptional style or delivery instructions for OpenAI-compatible TTS models that support them.
language_codeNoOptional language code for Gemini, xAI, and compatible TTS models.
stream_formatNoTokenLab delivery format. stream_format=sse is not supported for tts-1 or tts-1-hd.audio
response_formatNoAudio format. Common values include mp3, opus, aac, flac, wav, and pcm. Supported values vary by mo…
X-TokenLab-Delivery-PolicyNoPer-request Delivery policy. Overrides the API key and Workspace defaults. Auto tries TokenLab Veri…

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.6.26
    • changedInput schema / properties / language_code / description
      Previous value: -"Optional language code for Gemini, xAI, and compatible TTS routes."New value: +"Optional language code for Gemini, xAI, and compatible TTS models."
    • changedInput schema / properties / temperature / description
      Previous value: -"Sampling temperature for Gemini-compatible TTS routes."New value: +"Sampling temperature for Gemini-compatible TTS models."
    • changedInput schema / properties / voice / description
      Previous value: -"Voice selector for OpenAI-compatible, Gemini, xAI, and MiniMax-compatible routes. Some MiniMax rout…"New value: +"Voice selector for OpenAI-compatible, Gemini, xAI, and MiniMax-compatible speech models. Some MiniM…"
    • changedInput schema / properties / voice_id / description
      Previous value: -"Provider-native voice selector for MiniMax-compatible speech models."New value: +"Voice selector for MiniMax-compatible speech models."
  2. Changed3 schema fields changedv0.6.24
    • addedInput schema / properties / X-TokenLab-Delivery-Policy
      Added value: +{
+  "description": "Per-request Delivery policy. Overrides the API key and Workspace defaults. Auto tries TokenLab Veri…",
+  "enum": [
+    "auto",
+    "verified",
+    "official"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / response_format / description
      Previous value: -"Audio format. Common values include mp3, opus, aac, flac, wav, and pcm. Supported values vary by model family."New value: +"Audio format. Common values include mp3, opus, aac, flac, wav, and pcm. Supported values vary by mo…"
    • changedInput schema / properties / voice / description
      Previous value: -"Voice selector for OpenAI-compatible, Gemini, xAI, and MiniMax-compatible routes. Some MiniMax routes also accept voice_id."New value: +"Voice selector for OpenAI-compatible, Gemini, xAI, and MiniMax-compatible routes. Some MiniMax rout…"
  3. Changed1 schema field changedv0.6.4
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  4. Addedv0.3.1

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true), so the safety bar is low. But the description adds nothing behavioral: it does not mention that output is non-deterministic across calls, that it consumes paid TTS quota, or how streaming/large inputs behave — notable gaps for a generation tool whose annotations flag openWorld and non-idempotency.

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?

One short, front-loaded sentence with zero filler — the purpose is stated immediately. It is arguably under-specified rather than padded, so it scores well on conciseness but is not an exemplar of a complete-yet-tight definition.

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

Completeness2/5

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

For a 12-parameter tool spanning multiple TTS model families with mutually exclusive voice/voice_id/prompt/instructions fields and no output schema, a single generic sentence is far too thin. It gives the agent no help choosing a model family or reconciling the overlapping voice-selection parameters.

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 description coverage is 100%, so the schema already documents all 12 parameters (voice, model, speed, stream_format, response_format, etc.). The description adds no syntax, defaults, or format guidance beyond the schema, which is the expected baseline 3 when structured fields carry the load.

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?

States a specific verb and resource ('Generates audio from the input text') and even parenthesizes the canonical operation name (Text-to-Speech), so an agent knows exactly what this produces. It does not, however, distinguish itself from audio-producing siblings like create_music, translate_audio, or transcribe_audio, so the differentiation is left to the reader.

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

Usage Guidelines2/5

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

There is no guidance on when to use this versus alternatives (create_music for music, translate_audio for speech translation), no prerequisites, and no mention of model/voice selection workflow despite model being a core choice. The agent must infer all of this from the name alone.

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

Deploy Server

Other Tools