gemini-tts-mcp

Overview Schema Source Related Servers Discussions Admin

design_voice

Create a reusable voice from a natural-language description and save a preview WAV sample, so you can generate speech with it later using its voice_id.

Instructions

どんな声にしたいかを自然文で説明して、新しい声を作る（ボイスデザイン）。試聴用サンプルも保存する。

作った声は voice_id（voice_...）でプロジェクトに保存され、generate_speech の voice に渡して何度でも使える（generate_speech に同じ条件の voice_description を渡した場合もこの声が使われる）。呼ぶたびに新しい声を作るので、気に入るまで説明を変えて試せる。

Args: description: 声の説明（年齢・性別・声質・話し方の雰囲気・なまりなど、恒常的な特徴を 1〜2 文で）。例: "穏やかで落ち着いた 40 代男性のナレーター。低めで温かみのある声" 例: "A crisp, energetic sports announcer in her 30s with a slight Midwestern accent." display_name: 声の表示名（任意。省略時は説明文の先頭）。 gender: 性別（任意。female / male / neutral）。 language_code: 主に話す言語（任意。BCP-47。例: ja-JP, en-US）。 pitch: 声の高さ（任意。low / medium / high）。 accent: なまり・アクセント（任意。例: "Kansai", "British"）。 base_voice: リミックス元の声（任意）。プリビルト名（例: Puck）または voice_... を指定すると、 description は「その声からどう変えるか」の指示として扱われる。 model: 使用モデル（任意。gemini-3.8-flash-tts / gemini-3.8-flash-lite-tts）。 sample_out_path: 試聴サンプル（WAV）の保存先（任意）。省略時は GEMINI_TTS_OUT_DIR。 project_id: プロジェクトID上書き（任意）。

Returns: voice_id / display_name / sample（試聴サンプルの保存先）/ model / expire_time

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "description": "<description>"
    },
    "name": "design_voice"
  }
}

Input Schema

Name	Required	Description	Default
`model`	No
`pitch`	No
`accent`	No
`gender`	No
`base_voice`	No
`project_id`	No
`description`	Yes
`display_name`	No
`language_code`	No
`sample_out_path`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 12, 2026

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description carries the full burden and does disclose the key traits: every call creates a brand-new persistent voice (non-idempotent), a WAV sample is written to disk (default from GEMINI_TTS_OUT_DIR), and base_voice turns description into a modification instruction. However, it never explains expire_time despite returning it, nor says whether voices can be cleaned up or what auth/limits apply.

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

Conciseness5/5

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

Front-loaded summary, then a per-parameter Args block, then a short Returns line – the structure matches how an agent needs to read it. Every sentence conveys operational information; the two worked examples for description are justified because they anchor the required free-text format.

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 10-parameter, annotation-free creation tool, the description covers behavior, persistence, iteration, file side effects, and all parameters; the output schema already documents return fields. Remaining gap is what expire_time implies for voice lifetime, which affects whether an agent should treat a generated voice as durable.

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 0%, yet the Args section documents all ten parameters: field meanings, enum-like values for gender (female/male/neutral) and pitch (low/medium/high), the BCP-47 form for language_code, the two model names, example strings for description, and the fallback for sample_out_path/display_name. Only model and project_id remain thin, lacking guidance on defaults or when to override.

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 ('自然文で説明して、新しい声を作る（ボイスデザイン）') and immediately distinguishes itself from the speech-synthesis sibling by explaining that the resulting voice_id is fed into generate_speech. An agent can tell this is voice creation, not utterance synthesis, without opening the schema.

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 a clear iteration context ('呼ぶたびに新しい声を作るので、気に入るまで説明を変えて試せる') and the downstream reuse path via generate_speech. It does not say when NOT to use it (e.g. to reuse an existing voice, list_voices / generate_speech with an existing voice_id), so routing away from it is left implicit.

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

Deploy Server