Skip to main content
Glama

openFlow

by io.github.molkex
OverviewDiscussionsAdmin

generate_video_from_image

Generate a video that starts from a given image (i2v — image-to-video).

Pass exactly one start: start_image_base64 (raw base64 image bytes, no data: URI
prefix) or start_media_id (media_id of one of YOUR finished videos — the clip then
starts from that video's `frame`, "last" by default, taken server-side).
Mutually exclusive with reference-image (r2v) generation.

Chain clips: every finished video carries `last_frame_path` and its media_id, so
clip 2 = generate_video_from_image(prompt="...", start_media_id=<clip 1 media_id>),
clip 3 the same from clip 2's media_id. The chained job runs on the account that
made the source clip.

For "make content that looks like this real photo of a person" specifically,
prefer generate_video_with_reference (r2v) over this — see its docstring for why.
i2v is better suited to "continue visually from this exact frame" (e.g. chaining
clips), not identity preservation across a whole new scene.

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. 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.

voice / voice_style / voice_text: optional narration — same semantics as
generate_video_with_reference. Only works with speech-capable Veo 3.1 i2v models.

Input Schema

NameRequiredDescriptionDefault
seedNo
beatsNo
frameNolast
voiceNo
aspectNoVIDEO_ASPECT_RATIO_LANDSCAPE
promptYes
project_idNo
voice_textNo
voice_styleNo
start_media_idNo
include_previewNo
video_model_keyNoabra_i2v_4s
start_image_base64No

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / frame
      Added value: +{
+  "default": "last",
+  "enum": [
+    "first",
+    "last"
+  ],
+  "title": "Frame",
+  "type": "string"
+}
    • addedInput schema / properties / start_image_base64 / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / start_image_base64 / default
      Added value: +null
    • removedInput schema / properties / start_image_base64 / type
      Removed value: -"string"
    • addedInput schema / properties / start_media_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Start Media Id"
+}
    • changedInput schema / required
      Previous value: -[
-  "prompt",
-  "start_image_base64"
-]New value: +[
+  "prompt"
+]
  2. Changed1 schema field changed
    • addedInput schema / properties / seed
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Seed"
+}
  3. Changed3 schema fields changed
    • addedInput schema / properties / voice
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Voice"
+}
    • addedInput schema / properties / voice_style
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Voice Style"
+}
    • addedInput schema / properties / voice_text
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Voice Text"
+}
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only supply the generic write/openWorld profile, so the description carries the real burden and delivers: the chained job 'runs on the account that made the source clip', start_image_base64/start_media_id are mutually exclusive with r2v, the model 'STRETCHES' described motion over the requested length (with a measured example and a 15% movement loss), and voice only works with speech-capable Veo 3.1 i2v models.

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?

Long but front-loaded: the core rule and the exclusive-argument choice come first, then chaining, then the r2v steer, then beats guidance. Nearly every sentence carries actionable content, though the dated measurement anecdote and the cross-reference to another tool's docstring could be trimmed.

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 13-param generation tool with no output schema, the description supplies return-relevant details anyway (finished videos carry last_frame_path and a media_id, and the server reports the picked length and why). Only the unexplained model/aspect/seed options keep it short of fully self-contained.

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 coverage is 0% across 13 params, so the description must compensate and largely does: it defines start_image_base64's raw-bytes/no-prefix format, start_media_id's origin and server-side frame default, the frame enum's 'last' default, beats semantics, and project_id's purpose. It leaves seed, aspect, include_preview and the video_model_key enum choice unexplained, which is the only real gap.

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?

Opens with a precise verb+resource and an explicit acronym expansion ('Generate a video that starts from a given image (i2v — image-to-video)'), and actively distinguishes itself from siblings generate_video_with_reference (r2v) and, by implication, generate_video_between_frames. An agent can pick this tool without opening any other schema.

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?

Explicitly names the alternative for identity preservation ('prefer generate_video_with_reference'), states the condition where i2v wins ('continue visually from this exact frame', chaining clips), and gives a concrete multi-clip chaining recipe with argument examples. Both when-to-use and when-not-to-use are covered.

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

All openFlow toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources