Skip to main content
Glama

generate_video_between_frames

Generate the transition between TWO given frames: the video starts at the first image and ends at the second one, Flow invents everything in between.

This is Flow's "Кадры" with both slots filled — a different mechanism from
generate_video_from_image, which only pins the FIRST frame and lets the ending drift.
Use this when the ending matters: a logo that must resolve exactly, a character that
must land in a specific pose, two stills from a storyboard that need connecting.

Both images are raw base64 bytes, no data: URI prefix. The default model
(veo_3_1_interpolation_lite, 10 credits, 8 seconds) is the cheap one — transitions
are something you retry a few times, and defaulting to the 100-credit key would make
every experiment expensive.

beats: how many DISTINCT action phases the prompt describes — "ears flick back",
"tail lashes", "strikes the ball", "ball flies off" are four. Give it and the server
picks the clip length for you (about two phases per second) and says in the reply what
it picked and why. Measured 31.08.2026: the model STRETCHES whatever you describe over
whatever length you ask for, so one phase in four seconds comes out as slow motion, and
the same text at six seconds instead of four loses 15% of its movement. Adjectives are
not phases: "springy cartoon motion" adds nothing. Leave beats out and the length you
passed is used unchanged.

project_id: put the clip into a project made with create_project instead of the
account's default one.
beats: how many DISTINCT action phases the prompt describes. The server then picks
the clip length itself (about two phases per second) and says so in the reply. For a
first+last-frame transition keep it low: the two frames already fix the endpoints, and
asking for more seconds than the action needs only stretches it — measured 31.08.2026,
the same text at six seconds instead of four lost 15% of its movement.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
beatsNo
aspectNoVIDEO_ASPECT_RATIO_LANDSCAPE
promptYes
project_idNo
include_previewNo
video_model_keyNoveo_3_1_interpolation_lite
end_image_base64Yes
start_image_base64Yes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

The description goes well beyond annotations by disclosing the default model, credit cost, retry economics, measured motion-stretching behavior, and the fact that the server picks the clip length and reports its choice in the reply. It also clarifies that images must be raw base64 without a data URI prefix. No contradiction with annotations is present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opener is strong and front-loaded, but the description becomes repetitive: beats is explained twice in nearly identical blocks, including the same measured date and 15% movement-loss detail. Several sentences could be merged or removed, so not every sentence earns its place.

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 8-parameter tool with no output schema, the description provides the key mental model, cost context, retry guidance, input encoding constraints, and even what the server will reply. It is usable for correct invocation, though it does omit behavioral notes for aspect and include_preview; schema defaults help cover the basics.

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?

With 0% schema description coverage, the description compensates substantially: it explains start/end base64 encoding, beats semantics with counting examples, project_id behavior, and the default video_model_key. However, aspect, include_preview, and the non-default enum values for video_model_key are not explained, leaving some parameters underdocumented.

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 the concrete operation: 'Generate the transition between TWO given frames: the video starts at the first image and ends at the second one, Flow invents everything in between.' This is a specific verb + resource with a clear behavior, and it explicitly contrasts with the sibling generate_video_from_image, so an agent can distinguish the two tools.

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?

It gives explicit selection criteria: 'Use this when the ending matters' with concrete examples like logos, poses, and storyboard stills, and directly explains the difference from generate_video_from_image, which lets the ending drift. This leaves little ambiguity about when to choose this tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.