Skip to main content
Glama

Clone voice TTS (Qwen-TTS)

clone_voice_tts

Clone a voice from clone_audio_url and speak text via Qwen-TTS. Requires authorization_confirmed=true (own voice or written authorization). Pass text + clone_audio_url (+ recommended clone_audio_text) to start, or job_id to poll. Cost: 3 credits per call. VOICE AUTHORIZATION: Voice cloning is allowed ONLY for your own voice or a voice you have explicit written authorization to clone. Unauthorized cloning of another person's voice is prohibited. Calls are rate-limited/metered. (声音克隆仅限本人音色或已获书面授权的音色;禁止未授权克隆他人声音;调用限频。) Also: 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": "clone_voice_tts"
  }
}

Input Schema

NameRequiredDescriptionDefault
textNoText to speak in the cloned voice (<= 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).
wait_secondsNoHow long to wait for a result, 0–55 seconds (default 30).
clone_audio_urlNoPublic http(s) URL of the voice sample to clone (<= 2048 chars). Must be YOUR own voice or a voice you have explicit written authorization to clone.
idempotency_keyNoOptional caller correlation key. Billing is handled by mcp-credit-gateway.
clone_audio_textNoTranscript of the clone sample (strongly recommended, <= 2000 chars).
authorization_confirmedNoMust be true when starting a clone job: confirms the sample is your own voice or you have written authorization.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior4/5

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

Beyond the annotations it discloses cost (3 credits per call), the required `authorization_confirmed=true` gate, rate limiting/metering, an `sk_live_` key requirement, and output URL TTL limits — none of which are in the structured fields. The signal is diluted by duplicating the same policy text twice in two languages, but the substantive disclosures are there.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first two sentences are well front-loaded, but the remainder is heavy boilerplate: two overlapping authorization/licensing paragraphs, each repeated bilingually in Chinese, stating substantially the same restrictions. A large share of the text does not earn its place.

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

Completeness3/5

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

For a 9-parameter tool with no output schema, the description covers the start/poll workflow, cost, and authorization but never states what a successful call returns beyond implying output URLs exist. An agent cannot tell the result shape or what polling returns when the job is still pending.

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%, so every parameter is already documented in the input schema. The description only restates the recommended/required status of `clone_audio_text` and `authorization_confirmed`, adding no format or syntax detail beyond the schema.

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?

The opening sentence gives a specific verb and resource: clone a voice from `clone_audio_url` and speak `text` via Qwen-TTS. That is enough to distinguish it from `text_to_speech`, though the sibling is never named, so the differentiation is left to inference.

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?

It clearly branches the two call modes: start with `text` + `clone_audio_url` (+ recommended `clone_audio_text`), or poll with `job_id`. What is missing is any explicit guidance about when to prefer this over `text_to_speech` or what to do when authorization is unavailable.

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.