google-flow-mcp

Overview Schema Source Related Servers Discussions Admin

flow_storyboard_render

Render storyboard shots into video using keyframes and reference ingredients, with draft, standard, and high quality options plus background job progress.

Instructions

Render storyboard shots to video (keyframe = first frame, ingredients = references).

Shots render in parallel as background jobs. The call waits up to wait_seconds and then returns; unfinished shots keep rendering, and flow_project shows their progress. A standard/high render is a new generation from the same keyframe, so motion can differ from the draft while the look stays the same.

Args: shots: Shot numbers. Default: every shot without a take at this quality. quality: 'draft' (360p, cheapest, for checking motion), 'standard' (720p) or 'high' (1080p). confirm_cost: Set true only after the user accepted the cost estimate. wait_seconds: How long to wait before returning (default 150). project_name: Project to use (default: active project).

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": "flow_storyboard_render"
  }
}

Input Schema

Name	Required	Default
`shots`	No
`quality`	No	draft
`confirm_cost`	No
`project_name`	No
`wait_seconds`	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 supplied, the description carries the full burden and does well: it discloses that shots render in parallel as background jobs, that the call returns after wait_seconds while unfinished shots keep rendering, that progress is visible via flow_project, and that standard/high renders are fresh generations whose motion may differ from the draft. It stops short of describing failure behavior, whether a draft must exist first, or cost magnitude.

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 and the two most consequential behavioral facts (parallel background jobs, call returns early) before any parameter detail. The Args block is slightly list-like but every line adds information not present in the schema; nothing is padding.

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, no-output-schema mutation-style tool, the description covers what an agent needs to call it correctly: async timing, cost confirmation, quality tradeoffs, and defaults. The main remaining gap is the shape of the immediate return value (e.g. whether job identifiers come back), which matters when the call returns before completion.

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%, yet the description fully compensates: 'shots' is given a non-obvious default ('every shot without a take at this quality'), the 'quality' parameter is expanded with resolutions and cost/purpose tradeoffs despite having no enum in the schema, and confirm_cost, wait_seconds (default 150) and project_name (default active project) are each explained in terms of behavior, not just type.

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 ('Render storyboard shots to video') and immediately disambiguates the domain terms by defining keyframe as the first frame and ingredients as references. An agent can tell this apart from flow_generate_video or flow_image_to_video because it operates on storyboard shots rather than ad-hoc inputs.

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 concrete operating conditions: the default shot set is 'every shot without a take at this quality', quality selection is framed by intent ('draft ... for checking motion'), and confirm_cost is gated on the user having accepted a cost estimate. It also routes progress-checking to flow_project. It does not explicitly state when to prefer this over the sibling video-generation tools, which keeps it from a 5.

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