Skip to main content
Glama

Text to speech (Qwen-TTS)

text_to_speech

Synthesize speech from text via Qwen-TTS using a short refer_audio sample (http(s) URL). Pass text (<= 5000) + refer_audio (+ recommended refer_audio_text) to start, or job_id to poll. voiceId library voices are not exposed this wave. Cost: 2 credits per call. Compliance: Use only on material you own or are explicitly licensed/authorized to generate or remix. Do not generate or redistribute copyrighted music, voice likenesses, or trademarked audio without permission. Output URLs have a limited TTL and must not be abused for bulk scraping or redistribution. Calls are rate-limited/metered by mcp-credit-gateway and require a valid sk_live_ key. (仅处理自有或已获授权素材;禁止滥用生成/二创他人受版权保护的音乐或声音;输出有 TTL;调用限频。)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "text_to_speech"
  }
}

Input Schema

NameRequiredDescriptionDefault
textNoText to synthesize (<= 5000 chars). Required to start; omit when polling with `job_id` only.
speedNoOptional speaking speed (0.5–2).
job_idNoExisting Qwen-TTS job id. Polling never creates a new upstream job.
languageNoOptional language hint (default Auto upstream).
refer_audioNoPublic http(s) reference voice sample URL (<= 2048 chars). Required with `text` to start (preferred over voiceId). Use a short sample of a voice you own/are authorized to use.
wait_secondsNoHow long to wait for a result, 0–55 seconds (default 30).
idempotency_keyNoOptional caller correlation key. Billing is handled by mcp-credit-gateway.
refer_audio_textNoTranscript of the reference audio (strongly recommended, <= 2000 chars).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing cost (2 credits per call), credit-gateway rate limiting and required `sk_live_` key, a limited TTL on output URLs, and licensing/compliance constraints on source material. These are exactly the operational facts an agent needs and are not recoverable from the readOnlyHint/openWorldHint flags alone.

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?

Front-loaded with the synthesis action and the start-vs-poll decision before cost and compliance detail. The trailing Chinese parenthetical largely restates the English compliance sentence, which is redundant, but the overall structure remains scannable.

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 8-parameter, open-world generation tool with no output schema, the description covers invocation modes, auth, billing, rate limits, output URL lifetime, and compliance. An agent has everything required to call it correctly without guessing.

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 already 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema cannot express: the text+refer_audio pairing is what starts a job, `job_id`-only is the poll path, and `refer_audio` is preferred over an unexposed voiceId. That clarifies how the zero-required-parameter schema is meant to be combined.

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 specific verb and resource ("Synthesize speech from text via Qwen-TTS") plus the required input modality (a short `refer_audio` sample URL). It also carves out scope against the voice-library path ("voiceId library voices are not exposed this wave"), so an agent can distinguish it from siblings like clone_voice_tts or text_to_sound_effect.

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 branching guidance: pass `text` + `refer_audio` (+ recommended `refer_audio_text`) to start, or pass `job_id` to poll, and notes polling never creates a new upstream job. It does not, however, tell the agent when to prefer this over sibling tools such as text_to_sound_effect or clone_voice_tts, so the alternative-selection guidance is partial.

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.