google-flow-mcp

Overview Schema Source Related Servers Discussions Admin

flow_edit_video

Edit videos by prompt to add or remove objects, restyle, or relight. Supply one source: storyboard shot, local MP4, or prior interaction ID.

Instructions

Edit a video with a short instruction: add or remove an object, restyle, relight.

Keep the prompt short ('Make the jacket red', 'Add light snowfall', 'Make this anime'). Give ONE source: a storyboard shot (the edit becomes a new take), a local video of 15 s or less, or a previous_interaction_id from an earlier video result.

Args: prompt: The change to make. shot: Storyboard shot number to edit (uses its selected take). video_path: Local MP4 to edit. previous_interaction_id: interaction_id from an earlier video tool result. resolution: '360p', '720p', '1080p' or '4k' (default: same as the shot's take, else 720p). keep_rest: Add 'Keep everything else the same.' (recommended). confirm_cost: Set true only after the user accepted the cost estimate. project_name: Project to use when shot is given (default: active project).

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_edit_video"
  }
}

Input Schema

Name	Required	Description	Default
`shot`	No
`prompt`	Yes
`keep_rest`	No
`resolution`	No
`video_path`	No
`confirm_cost`	No
`project_name`	No
`previous_interaction_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.3Nov 13, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations at all, the description carries the full burden and does well: it discloses that editing a shot produces a new take, that resolution defaults to the shot's take otherwise 720p, the 15 s input cap, and the cost-confirmation gate. It omits what happens on conflicting sources, credit/rate-limit behavior, and the shape of the result beyond implying an interaction_id is returned.

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 one-line purpose, then prompt-style guidance, then the source constraint, then a scannable Args list. The three quoted example prompts are slightly redundant with the style advice but still instructive rather than filler.

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 an eight-parameter mutation tool with no annotations and no output schema, the description covers sources, defaults, and the cost gate adequately. What is missing is return-value expectation and behavior when multiple source parameters are passed simultaneously.

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 document everything, and it does: every one of the eight parameters is explained, including allowed resolution values and its fallback default, the exact text keep_rest appends, the project_name default, and the two mutually exclusive source parameters.

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?

States a specific verb and resource ('Edit a video') and enumerates concrete edit classes (add/remove an object, restyle, relight). It is clearly distinguishable from the image and extend siblings by the 'video' resource and the source-type constraint, though it never names a sibling explicitly.

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 strong conditional rules: exactly ONE source must be supplied, the acceptable source types (storyboard shot, local video of 15 s or less, previous_interaction_id), and that confirm_cost should be set only after the user accepted the estimate. It does not state when to prefer this over flow_extend_video or flow_edit_image.

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