Skip to main content
Glama

openFlow

by io.github.molkex
OverviewDiscussionsAdmin

generate_video

Generate a video from a text prompt via Google Flow (Veo models).

video_model_key options: abra_t2v_4s (default, 7 credits), veo_3_1_t2v_lite
(10cr, visibly cleaner), veo_3_1_t2v (100cr, "Quality" tier), veo_3_1_t2v_fast (20cr).

project_id: put the clip into a project made with create_project instead of the
account's default one — one project per end client keeps their work separate.

Video generation routinely takes 1-3+ minutes, so this almost always returns
a job_id rather than a finished result — call check_job with it, waiting a
few seconds between checks, until status is 'done' or 'failed'.
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.

seed (all video tools): the result always reports the seed it used. Same seed + same
prompt + same inputs = the same clip, so a good take can be re-made. A fixed seed does
NOT keep the composition when the prompt changes — use edit_video for that.
idempotency_key: optional, any string unique to this logical request (e.g. a uuid).
  Repeating a call with the same key within 24h returns the SAME job instead of a
  new one — use it when you may retry after a timeout or a busy error.

Input Schema

NameRequiredDescriptionDefault
seedNo
beatsNo
voiceNo
aspectNoVIDEO_ASPECT_RATIO_LANDSCAPE
promptYes
project_idNo
voice_textNo
voice_styleNo
idempotency_keyNo
include_previewNo
video_model_keyNoabra_t2v_4s

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / idempotency_key
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Idempotency Key"
+}
  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.3/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the 1-3+ minute runtime and job_id-then-check_job polling loop, credit costs per model tier, seed reproducibility semantics and its limitation, and 24h idempotency dedup. These are exactly the operational facts an agent cannot get from readOnlyHint/openWorldHint.

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, then organized around parameters with clear labels. It is long, but nearly every sentence carries non-obvious operational guidance (beats physics, seed caveat, polling cadence); the cost annotations in the model list are the only mildly redundant portion.

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 long-running, credit-spending mutation with no output schema, it covers the critical missing pieces: async job lifecycle, cost tiers, dedup, and reproducibility. The main gap is the audio/voice parameter family, which an agent would have to guess at.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and there are 11 parameters, so the description must carry the load. It gives rich semantics for video_model_key, project_id, beats, seed and idempotency_key, but leaves voice, voice_text, voice_style, aspect and include_preview entirely unexplained, and it documents only 4 of the 11 model keys (the 6s/8s/10s/360p variants go unmentioned). Substantial added value, but under half the surface covered.

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+resource ('Generate a video from a text prompt via Google Flow (Veo models)'), which implicitly separates it from the image/frame/reference-based video siblings. It never names those alternatives explicitly, so an agent must infer that this is the text-only path, but the resource qualifier is enough to disambiguate.

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 covers when to use (text prompt), how to attach output to a project ('one project per end client'), when to set beats vs leave it out, when to use idempotency_key ('when you may retry after a timeout or a busy error'), and it routes the agent to edit_video instead of a fixed seed when the prompt changes. Alternatives and exclusions are both present.

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