google-flow-mcp

Overview Schema Source Related Servers Discussions Admin

flow_generate_music

Generate 30-second music clips or full songs from a text prompt and attach the track to a project as background music for films.

Instructions

Generate music with Lyria: a 30-second clip (about $0.04) or a full song (about $0.08).

Describe genre, mood, tempo and instruments. In a project the track becomes the film's background music (looped and faded out by flow_assemble).

Args: prompt: e.g. 'warm lo-fi piano with soft vinyl crackle, 80 bpm, hopeful'. kind: 'clip' (30 s) or 'song' (a couple of minutes, can include lyrics). instrumental: Ask for no vocals (default true; best for background music). attach: Store it as the active project's music. project_name: Project to use (default: active project, if any).

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": {
      "prompt": "<prompt>"
    },
    "name": "flow_generate_music"
  }
}

Input Schema

Name	Required	Default
`kind`	No	clip
`attach`	No
`prompt`	Yes
`instrumental`	No
`project_name`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.3Nov 13, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the burden well: it discloses per-call cost (~$0.04 / ~$0.08), durations, that songs can include lyrics, default settings, and the side effect that 'attach' stores the track as the active project's music. It does not mention latency/asynchrony, failure modes, or whether generation is resumable, which are the remaining behavioral gaps.

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 core sentence, then a compact Args list; every line adds meaning. There is minor redundancy where Args restates defaults already present in the schema, but nothing is filler and the cost note is appropriately early.

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 five-parameter generative tool with no annotations and no output schema, the definition is nearly sufficient: cost, defaults, side effects and prompt format are all covered. What is missing is what the call returns when 'attach' is false (an asset handle, URL, or job id), which an agent needs to chain the result.

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 coverage is 0% and the description fully compensates: every one of the five parameters is explained, including the 'clip' vs 'song' enum values with their durations, the semantics of 'instrumental' (no vocals) and its default, what 'attach' actually does, and the 'project_name' default to the active project. The prompt example supplies concrete format guidance the schema lacks.

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 ('Generate music with Lyria') and immediately scopes the two output forms (30-second clip vs full song). It is trivially distinguishable from siblings like flow_generate_image, flow_generate_video and flow_generate_narration, all of which target different media.

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 practical selection context: which 'kind' to pick, that 'instrumental' is best for background music, and that in a project the result is picked up and looped/faded by flow_assemble. It stops short of explicit when-not-to-use guidance or naming a sibling to prefer for an adjacent need, so it is strong context rather than a full routing rule.

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