Skip to main content
Glama

gemini_music_generate

Generate music from a text prompt specifying mood, genre, instruments, or lyrics. Outputs an MP3 via Lyria models; single-turn, so include the full brief and a wait budget for long runs.

Instructions

Generate music from a text prompt (mood, genre, instruments, structure, or lyrics inline) via a Lyria model: lyria-3-clip-preview (30s instrumental clip, default, cheapest), lyria-3.5 (full-length song with vocals) or lyria-3-pro-preview (longer-form). Output is MP3, written to disk (or returned inline). Single-turn: a track cannot be refined by a follow-up call, so put the whole brief in the prompt. Runs long — give it a max_wait_ms budget (or async: true + gemini_get_result on a local install), or raise timeout_ms. Needs a funded account. Local file inputs are confirmed first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asyncNoReturn a job_id immediately instead of the result, so a long generation cannot hit the host tools/call timeout (-32001); poll gemini_get_result. On the hosted connector prefer max_wait_ms — the executor only lives while a request is open, so async is served there as a bounded wait.
modelNoLyria model (default: lyria-3-clip-preview — 30s, $0.04). lyria-3.5 and lyria-3-pro-preview run minutes-long at $0.08.
imagesNoOptional reference image path(s) to condition the music
inlineNoReturn base64 audio inline instead of writing to disk. A 30s track is ~1.9MB of base64 — the default hands back a path instead
promptYesDescription of the music: mood, genre, instruments, tempo, structure, or lyrics
filenameNoBase filename for the output audio (extension stripped; default: slugified prompt)
backgroundNoRun the generation on Google's side and poll it, so a killed job can be recovered by gemini_get_result. Off by default — see gemini_video_generate
images_urlNoReference images as public https URLs — the server downloads them, so no image bytes cross the conversation. Preferred over images_base64, which costs ~14k tokens per photo. Max 15MB each, Content-Type image/*.
output_dirNoDirectory to write audio to (default: $GEMINI_OUTPUT_DIR or cwd)
timeout_msNoUpstream timeout in ms for this call (default $GEMINI_TIMEOUT_MS, else 60000 — 120000 at 4K, which runs past 60s)
max_wait_msNoWait up to this many ms in-band, then hand back { job_id, status: "running" } to poll with gemini_get_result (e.g. 20000 for multi-image sets). Keeps fast results inline and slow ones off the host timeout (-32001). Ignored when async is set.
confirmTokenNoONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.
images_base64NoReference images as base64 strings or data URIs. Last resort — about 14k tokens per photo; prefer images_url or images_file_uris. The server uploads each one and reports a file_uri under image_inputs: pass that to images_file_uris next time instead of re-sending the bytes.
from_clipboardNoUse the image currently on the macOS clipboard as a reference
idempotency_keyNoRepeat calls with this key return the recorded result (reused: true) instead of billing a new generation. Set it when retrying after a host timeout (-32001).
images_file_urisNoReference images as Files API references ("files/<id>" or the full uri) from gemini_upload_file. Upload once and reuse across calls with no bytes in the conversation; retained ~48h, after which the reference stops resolving.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.3.0
    • removedInput schema / properties / confirm
      Removed value: -{
      -  "description": "Must be true to proceed. Without this, the tool returns a preview.",
      -  "type": "boolean"
      -}
    • addedInput schema / properties / confirmToken
      Added value: +{
      +  "description": "ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 \"confirmation-required\" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.",
      +  "type": "string"
      +}
  2. Changed1 schema field changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Changed13 schema fields changedv1.14.0
    • changedInput schema / properties / async / description
      Previous value: -"Run in the background and return a job_id immediately instead of the image, so a long (Pro/4K) generation cannot hit the host tools/call timeout (-32001). Poll gemini_get_result with the job_id to fetch the result. PREFER `max_wait_ms` on the hosted connector: it runs where the executor is only guaranteed to stay alive while the request is open, so this option is served there as a bounded wait rather than an immediate hand-off."New value: +"Return a job_id immediately instead of the result, so a long generation cannot hit the host tools/call timeout (-32001); poll gemini_get_result. On the hosted connector prefer max_wait_ms — the executor only lives while a request is open, so async is served there as a bounded wait."
    • removedInput schema / properties / audio_format
      Removed value: -{
      -  "description": "Output format (default mp3). wav is lyria-3-pro-preview-only.",
      -  "enum": [
      -    "mp3",
      -    "wav"
      -  ],
      -  "type": "string"
      -}
    • removedInput schema / properties / continue_last
      Removed value: -{
      -  "description": "Continue from the most recent music interaction this server created (explicit previous_interaction_id wins)",
      -  "type": "boolean"
      -}
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Opaque idempotency key: a repeat call with the same key returns the recorded result (reused: true) instead of billing a new generation. Set it when retrying after a host timeout (-32001) to avoid a duplicate charge."New value: +"Repeat calls with this key return the recorded result (reused: true) instead of billing a new generation. Set it when retrying after a host timeout (-32001)."
    • changedInput schema / properties / images_base64 / description
      Previous value: -"Reference images as base64 strings or data URIs. Last resort: prefer images_url or images_file_uris, which keep image bytes out of the conversation"New value: +"Reference images as base64 strings or data URIs. Last resort — about 14k tokens per photo; prefer images_url or images_file_uris. The server uploads each one and reports a file_uri under image_inputs: pass that to images_file_uris next time instead of re-sending the bytes."
    • changedInput schema / properties / images_file_uris / description
      Previous value: -"Reference images by Gemini Files API reference (\"files/<id>\", or the full uri) from gemini_upload_file or POST /upload. Upload once, then reference it across as many calls as you like — no bytes are re-sent and none enter the conversation. Files are retained ~48h, after which the reference stops resolving."New value: +"Reference images as Files API references (\"files/<id>\" or the full uri) from gemini_upload_file. Upload once and reuse across calls with no bytes in the conversation; retained ~48h, after which the reference stops resolving."
    • changedInput schema / properties / images_url / description
      Previous value: -"Reference images as public https URLs — the SERVER downloads them, so no image bytes travel through the conversation. Preferred over images_base64, which costs ~14k tokens per photo and breaks if a file read was truncated. Max 15MB each; must be a directly-linked image (Content-Type image/*)."New value: +"Reference images as public https URLs — the server downloads them, so no image bytes cross the conversation. Preferred over images_base64, which costs ~14k tokens per photo. Max 15MB each, Content-Type image/*."
    • changedInput schema / properties / inline / description
      Previous value: -"Return base64 audio inline instead of writing to disk"New value: +"Return base64 audio inline instead of writing to disk. A 30s track is ~1.9MB of base64 — the default hands back a path instead"
    • changedInput schema / properties / max_wait_ms / description
      Previous value: -"Wait up to this many ms for the result; if generation is still running when the budget expires, return { job_id, status: \"running\" } immediately instead (poll gemini_get_result). Keeps fast results in-band while a slow batch can never trip the host tools/call timeout (-32001) — e.g. 20000 for multi-image sets. Ignored when async is set."New value: +"Wait up to this many ms in-band, then hand back { job_id, status: \"running\" } to poll with gemini_get_result (e.g. 20000 for multi-image sets). Keeps fast results inline and slow ones off the host timeout (-32001). Ignored when async is set."
    • changedInput schema / properties / model / description
      Previous value: -"Lyria model (default: lyria-3-clip-preview). Pro is longer-form and supports WAV."New value: +"Lyria model (default: lyria-3-clip-preview — 30s, $0.04). lyria-3.5 and lyria-3-pro-preview run minutes-long at $0.08."
    • changedInput schema / properties / model / enum
      Previous value: -[
      -  "lyria-3-clip-preview",
      -  "lyria-3-pro-preview"
      -]New value: +[
      +  "lyria-3-clip-preview",
      +  "lyria-3.5",
      +  "lyria-3-pro-preview"
      +]
    • removedInput schema / properties / previous_interaction_id
      Removed value: -{
      -  "description": "Interaction id to continue from",
      -  "type": "string"
      -}
    • changedInput schema / properties / timeout_ms / description
      Previous value: -"Upstream request timeout in ms for this call (default: $GEMINI_TIMEOUT_MS, else 60000 — or 120000 when image_size is 4K, which routinely runs past 60s)"New value: +"Upstream timeout in ms for this call (default $GEMINI_TIMEOUT_MS, else 60000 — 120000 at 4K, which runs past 60s)"
  4. Changed1 schema field changedv1.10.0
    • addedInput schema / properties / background
      Added value: +{
      +  "description": "Run the generation on Google's side and poll it, so a killed job can be recovered by gemini_get_result. Off by default — see gemini_video_generate",
      +  "type": "boolean"
      +}
  5. Changed2 schema fields changedv1.7.0
    • changedInput schema / properties / async / description
      Previous value: -"Run in the background and return a job_id immediately instead of the image, so a long (Pro/4K) generation cannot hit the host tools/call timeout (-32001). Poll gemini_get_result with the job_id to fetch the result (jobs are per-process and expire ~10 min after completion)."New value: +"Run in the background and return a job_id immediately instead of the image, so a long (Pro/4K) generation cannot hit the host tools/call timeout (-32001). Poll gemini_get_result with the job_id to fetch the result. PREFER `max_wait_ms` on the hosted connector: it runs where the executor is only guaranteed to stay alive while the request is open, so this option is served there as a bounded wait rather than an immediate hand-off."
    • addedInput schema / properties / max_wait_ms
      Added value: +{
      +  "description": "Wait up to this many ms for the result; if generation is still running when the budget expires, return { job_id, status: \"running\" } immediately instead (poll gemini_get_result). Keeps fast results in-band while a slow batch can never trip the host tools/call timeout (-32001) — e.g. 20000 for multi-image sets. Ignored when async is set.",
      +  "exclusiveMinimum": 0,
      +  "maximum": 600000,
      +  "type": "integer"
      +}
  6. First observedv1.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the minimal annotations, the description discloses that calls run long, may time out, write to disk or return inline, cannot be refined, can require a two-step confirmation fallback, and may need idempotency_key for retries. It also surfaces cost/speed differences between models. This goes well beyond what annotations provide.

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?

The description is dense and front-loaded with the core action, model options, and output behavior before caveats. It is long, but the tool is complex; some model details are repeated from the schema and the long paragraph could be tightened, so it is not a perfect 5, but every sentence carries operational value.

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 16-parameter tool with no output schema, the description covers the critical operational context: runtime behavior, timeout/async handling, confirmation flow, retry/idempotency, file output vs inline, account prerequisite, and model selection. Nothing essential for an agent to call this tool correctly is missing.

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 100%, so the baseline is 3 and the schema carries the heavy lifting. The description adds meaningful extras beyond the schema: MP3 output format, 'full-length song with vocals' for lyria-3.5, 'longer-form' for pro, the single-turn prompt expectation, and the max_wait/async strategy. This justifies moving above baseline without overstating.

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 description names a specific action ('Generate music from a text prompt'), a concrete resource (Lyria model), and the output format (MP3). It differentiates from siblings by explicitly naming music generation and model variants, so an agent can distinguish it from gemini_image_generate and gemini_video_generate 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 Guidelines5/5

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

The description gives strong usage direction: it explains single-turn behavior, instructs putting the whole brief in the prompt, directs hosted vs local installs to max_wait_ms vs async + gemini_get_result, references gemini_video_generate for background polling, and warns about funded-account requirements. This is explicit when/how guidance with named alternatives.

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