Skip to main content
Glama

generate_speech

Generates WAV speech from text with Gemini TTS, letting you design or reuse voices by description, scene, or style for consistent narration.

Instructions

文章を、指定した声(または場面に合う声)で読み上げた音声(WAV)を生成する。

声の決め方(上ほど優先。どれも無ければ既定のプリビルトボイス):

  1. voice_description: どんな声にしたいかを自然文で説明する(ボイスデザイン)。 初回はその説明から声を作成して保存し、2 回目以降は同じ説明なら同じ声を再利用する。 例: "明るく元気な 20 代女性。少し早口でハキハキした声"

  2. voice: プリビルトボイス名(例: Kore, Puck, Zephyr。list_voices / list_models で確認) または design_voice で作った voice_id(voice_...)。 voice と voice_description の両方なら、voice を元に説明どおりに変えた声を作る(リミックス)。

  3. scene: 用途・場面(例: "AWS のイベントでのプレゼン")。場面に合う声と話し方を自動で考える。 プランはキャッシュされ、同じ scene なら何度呼んでも同じ声・話し方になる(スライドごとに 分けて生成しても声が揃う)。voice / voice_description / style を指定した部分はそちらが優先。

Args: text: 読み上げる文章(言語は自動判定)。強調したい語を大文字にする、句読点や「…」で間を作る、 などのタグ(英語表記)を文中に 入れると一瞬の笑い・ため息・間を表現できる。 scene: 音声を使う場面・用途・聞き手(任意)。例: "AWS のイベントでのプレゼン。聴衆はエンジニア数百人"。 voice_description: どんな声にしたいかの説明(年齢・性別・声質・雰囲気など恒常的な特徴)。 voice: プリビルトボイス名、または voice_... の ID。 style: 話し方の指示(任意。感情・速さ・抑揚・声量など、その場の話し方)。 例: "嬉しそうに、ややゆっくり" / "whispered urgently"。本文には混ぜずにここへ書く (本文に書くと読み上げられてしまう)。短い方が効果的。scene より優先。 enhance_text: True なら本文に間・息継ぎのタグ( 等)を自動で入れてから読み上げる (言葉は変えない。変わってしまった場合は元の文章のまま読む)。 out_path: 出力先ファイルパス(.wav)。省略時は GEMINI_TTS_OUT_DIR に自動命名で保存。 gender: 話者の性別(任意。female / male / neutral。声を作るとき・scene のプランに使う)。 language_code: 主言語(任意。例: ja-JP。声を作るとき・scene のプランに使う)。 model: 使用モデル(任意)。gemini-3.8-flash-tts(既定)/ gemini-3.8-flash-lite-tts(速い・安い)。 環境変数 GEMINI_TTS_MODEL 設定時はこの引数は無視。 sample_rate: サンプルレート(24000(既定)/ 16000 / 8000)。 replan: True なら scene のプランをキャッシュせずに考え直す(声も変わる)。 project_id: プロジェクトID上書き(任意。クォータ帰属用)。

Returns: success / out_path / files / duration_sec / voice / voice_source / voice_id / style / scene_plan(scene 指定時: 声の設計・話し方・理由)/ text_used(enhance_text 時)/ model / project_id voice_id(voice_...)を次回 voice に渡すと、同じ声で読み上げられる。

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": {
      "text": "<text>"
    },
    "name": "generate_speech"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYes
modelNo
sceneNo
styleNo
voiceNo
genderNo
replanNo
out_pathNo
project_idNo
sample_rateNo
enhance_textNo
language_codeNo
voice_descriptionNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and largely succeeds: it discloses voice caching and reuse by identical description, scene-plan caching for consistency across chunks, replan as the cache-bypass, GEMINI_TTS_MODEL overriding the model argument, automatic out_path naming via GEMINI_TTS_OUT_DIR, and the enhance_text fallback that re-reads the original text if wording changes. It does not say whether an existing out_path file is overwritten, nor anything about cost/quota beyond the project_id mention.

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 purpose, then a compact priority list, then a per-argument block – the structure makes a 13-parameter tool scannable. It is long, and the closing Returns section partially duplicates the output schema, but no sentence is filler.

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 13-parameter generative tool with an output schema, the description covers input meaning, selection precedence, caching semantics, env-var overrides, and the actionable voice_id round-trip for reusing a generated voice. An agent has enough to call it correctly on the first attempt.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate and does: every one of the 13 parameters gets meaning beyond its title, including tag syntax and punctuation techniques for text, the distinction between persistent voice traits and per-call style (with an explicit warning not to put style in the body text that would be read aloud), accepted sample rates, model defaults, and the purpose of project_id.

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?

The opening sentence states a specific verb and artifact: generate a WAV reading of text in a specified or scene-appropriate voice. It also implicitly scopes itself away from design_voice by pointing at design_voice only as the source of a voice_... ID, so an agent can tell what this tool does and does not do.

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?

The numbered voice-selection priority list (voice_description > voice > scene, with remix behavior when both voice and voice_description are given) is explicit and actionable, and it names list_voices / list_models / design_voice for looking up or creating inputs. It does not say when to prefer this tool over the sibling plan_speech, which is the one remaining routing gap.

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