google-flow-mcp

Overview Schema Source Related Servers Discussions Admin

flow_image_to_video

Generates or reuses an anchor image, then animates it into a short video from a movement prompt, with controls for duration, aspect ratio, resolution, and style.

Instructions

Pipeline: make (or reuse) an anchor image, then animate it with Gemini Omni Flash.

Args: video_prompt: How the scene should move. image_prompt: Prompt for a new anchor image (if image_path is not given). image_path: Existing image to animate. image_model: 'pro' (default here, best detail), 'fast' or 'lite'. duration_seconds: 3-15. aspect_ratio: '16:9' or '9:16'. Overrides preset. resolution: '360p', '720p', '1080p' or '4k'. preset: e.g. 'shorts' or 'youtube-thumbnail'. style: Style preset for the anchor image. negative_prompt: Things to avoid in both steps. confirm_cost: Set true only after the user accepted the cost estimate. output_dir: Override the output folder.

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": {
      "video_prompt": "<video_prompt>"
    },
    "name": "flow_image_to_video"
  }
}

Input Schema

Name	Required	Default
`style`	No
`preset`	No
`image_path`	No
`output_dir`	No
`resolution`	No	720p
`image_model`	No	pro
`aspect_ratio`	No
`confirm_cost`	No
`image_prompt`	No
`video_prompt`	Yes
`negative_prompt`	No
`duration_seconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.3Nov 13, 2026

TDQS

A3.7/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 load and does disclose real behavior: it is a two-stage pipeline, image_model defaults to 'pro' (cost-relevant), duration is bounded 3-15s, aspect_ratio 'overrides preset,' negative_prompt applies to both steps, and confirm_cost must be true only after the user accepts a cost estimate. What is missing is any statement of the return artifact (file path? URL?) or failure behavior when neither image source is usable.

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 one-line pipeline statement is front-loaded and the per-argument list is compact, one line each. Because the schema has no per-property descriptions, the enumerated args earn their place rather than duplicating structured data; a couple of entries ('style: Style preset for the anchor image') are near-tautological.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, no-annotation, no-output-schema tool, the description covers inputs well but leaves the result side blank: nothing says what is produced or where (beyond output_dir being an 'override'), nor how it interacts with flow_estimate_cost before confirm_cost can be set. Empty is the shape of the omission, not of the text.

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 description coverage is 0%, so this list is the only semantic source for 12 parameters, and it mostly delivers: it supplies value sets (image_model pro/fast/lite, resolution 360p-4k, aspect 16:9/9:16), valid ranges (3-15s), and precedence rules (aspect_ratio overrides preset; image_prompt ignored when image_path is given). Weaknesses are the unexplained 'preset' examples ('shorts', 'youtube-thumbnail') and a thin 'style' definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete two-step pipeline: 'make (or reuse) an anchor image, then animate it with Gemini Omni Flash.' That is a specific verb+resource and makes clear this is image-to-video rather than plain text-to-video or editing. It does not explicitly name the sibling it differs from (e.g., flow_generate_video), which keeps it off a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Implicit routing guidance is present: image_prompt is used 'if image_path is not given,' and image_path is 'existing image to animate,' so an agent can infer when to supply which. However, there is no explicit when-to-use vs when-not statement and no named alternative for the case where the user has no anchor image and wants pure text-to-video.

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