Tesseract

Make a long video from scenes

make_long_video

A longer video from 1–12 scenes. "continuous" (default, gemini-omni-1.2-flash): each scene continues the shot before it, up to 30 s in all, and a scene is made only when check_job finds the one before it finished — stop checking and nothing more is made or charged. Each continuation re-reads every clip made so far, so it fits about two or three scenes: a short first scene leaves the most room. "clips": every scene its own clip, all at once, on any video model. Returns a job_id; call check_job every 10–20 seconds until done.

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": {
      "scenes": "<scenes>"
    },
    "name": "make_long_video"
  }
}

Input Schema

Name	Required	Description
`mode`	No
`model`	No	clips mode: a video model from list_models.
`scenes`	Yes
`max_usd`	No	The most this may cost, in US dollars: a dearer job is not started.
`rights_ok`	No	With a source video of someone else's: true only when the person says the video and its sound belong to their makers, and the result is for their own use unless they hold the rights.
`first_frame`	No	continuous mode: the picture the first scene starts from. A picture: a public https:// URL, or a data:image/…;base64,… URI (up to 10 MB).
`aspect_ratio`	No
`likeness_consent`	No	Only when the person asked for it themselves, about who is shown: "self" (them), "consented" (an adult who agreed to it) or "made-up" (a made-up person) — and only when nobody shown is under 18 or a public figure, and there is no nudity or sexual content. Needed by the effects that put a person in, talking or lip-synced people, headshots and try-ons.
`reference_images`	No	Gemini Omni: pictures of who or what must look the same in the first scene — not frames.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 10, 2026

addedInput schema / properties / likeness_consent

Added value: +{
+  "description": "Only when the person asked for it themselves, about who is shown: \"self\" (them), \"consented\" (an adult who agreed to it) or \"made-up\" (a made-up person) — and only when nobody shown is under 18 or a public figure, and there is no nudity or sexual content. Needed by the effects that put a person in, talking or lip-synced people, headshots and try-ons.",
+  "enum": [
+    "self",
+    "consented",
+    "made-up"
+  ],
+  "type": "string"
+}

addedInput schema / properties / rights_ok

Added value: +{
+  "description": "With a source video of someone else's: true only when the person says the video and its sound belong to their makers, and the result is for their own use unless they hold the rights.",
+  "type": "boolean"
+}

First observedNov 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well past the annotations with billing semantics ('stop checking and nothing more is made or charged'), an async job model (returns job_id, poll every 10–20 s), and a real capacity limit — continuous mode 'fits about two or three scenes' because each continuation re-reads all prior clips. These are exactly the facts an agent needs before committing money.

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 core statement and the default mode, and every clause carries information — no filler. The cost is density: quoted mode switches inside a single long run-on paragraph make it harder to scan than a bulleted mode split would.

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

Completeness5/5

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

With no output schema and nine parameters, the description still covers what an agent needs: what comes back (job_id), how to advance the job, cost capping behavior, and the hard capacity limit of continuous mode. Remaining gaps are minor field-level details rather than anything that would cause a mis-call.

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 coverage is 67% and the schema already documents most fields (max_usd, rights_ok, likeness_consent, reference_images, durations). The description adds genuine meaning for mode selection and the practical hint that 'a short first scene leaves the most room', but says nothing about aspect_ratio, model defaults, or the prompt field. Meaningful but partial compensation.

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 a specific artifact — a longer video built from 1–12 scenes — and immediately splits it into two named modes with the default identified. That is enough to distinguish it from generate_video (single clip) and from check_job (polling) without opening any schema.

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?

Mode selection is spelled out: 'continuous' for shots that continue each other, 'clips' for independent scenes 'on any video model', with the default stated. It also gives operational guidance — poll check_job every 10–20 seconds, and stopping the polling halts production. It doesn't explicitly say when to prefer this over generate_video, but the multi-scene framing implies it.

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

All Tesseract tools Inspect

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

Need Help?