Skip to main content
Glama

Render a video

video_render

Renders a scene to video.webm (VP9 and Opus), video.wav (its sound) and video.vtt (when it has subtitles); with preview (the default) also video.contact.png, twelve moments on one sheet, and video.preview.gif, 480 pixels wide. A scene can hold: drawn pictures with groups (a character's parts move, turn and fade together) and mirror x, y or both on any layer or group, layer and track blends (multiply for a shadow, a vignette or a night grade; screen and add for a glow or a flare, on a layer or a track alike), closed paths filled nonzero (the default) or evenodd (a self-overlapping star leaves its centre bare);characters who talk (cast, timed lines with their own reading, ducked music, subtitles made from the lines, a mouth that moves on the words, or swaps between closed, open, wide and round drawings (with an idle breath and a listening beat, as a moving mouth has), and eyes that blink); shots with people on paths, action beats (guard, strike, hit, fall, get-up) and gestures on cue (a wave, a point, a nod), a directed character (a figure by seed, dressed by its look, standing in a named gait from the schema, speaking through its cast name, set among forms, props and a ground, filmed by a dolly or an orbit), animals and forms, and a camera that follows, orbits or cranes; music cues with a melody, a lead instrument, tempo changes and fades, that duck under lines and under any sound marked ducks_music; and sounds that move across the ears. Its files together are at most 50 MB, so a long, busy scene renders with preview false. At most 60 seconds, 1920 by 1080 either way up and 30 frames a second. The price is read off the engine's own cost report: units = design renders x megapixels / 45 + frames x megapixels / 200 + shot frames x megapixels / 1.6 + 3 a shot clip, rounded up; at most 600 a job, and video_cost says it first. It runs as a queued job: the answer is 202 with a job id at once, and GET /api/agents/jobs/ (or the MCP tool job) says when it is done and signs its files. A queued call is refused on the free plan with 402: its units buy only calls that answer at once, and queued jobs need a paid plan (a pass or the card plan). Each account may have 4 queued jobs waiting or running (1 running at a time), and may submit 20 videos and 10 minutes of video a day (UTC).

Input Schema

NameRequiredDescriptionDefault
sceneYesA scene document written inline: output (size, frame rate, length), tracks of clips, optional cast and lines, audio and subtitles. Start from video_examples and read video_schema for every key.
previewNoAlso write the contact sheet and a small preview GIF (the default); false for a long, busy scene whose files would pass the size cap.

Output Schema

NameRequiredDescriptionDefault
msNoMilliseconds the run took.
jobYesThe job id; the job tool reads it.
verbNoThe tool that made it.
filesNoFiles made, each with a name, type, size and a signed URL.
unitsNoUnits this call cost.
resultNoThe engine's own answer, a JSON document.
statusNoqueued when the job runs in the background.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": true,
      +  "properties": {
      +    "files": {
      +      "description": "Files made, each with a name, type, size and a signed URL.",
      +      "items": {
      +        "additionalProperties": {},
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "job": {
      +      "description": "The job id; the job tool reads it.",
      +      "type": "string"
      +    },
      +    "ms": {
      +      "description": "Milliseconds the run took.",
      +      "type": "number"
      +    },
      +    "result": {
      +      "description": "The engine's own answer, a JSON document."
      +    },
      +    "status": {
      +      "description": "queued when the job runs in the background.",
      +      "type": "string"
      +    },
      +    "units": {
      +      "description": "Units this call cost.",
      +      "type": "number"
      +    },
      +    "verb": {
      +      "description": "The tool that made it.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "job"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A4/5.0
Behavior5/5

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

Annotations only declare the mutation/idempotency profile; the description adds far more: the queued-job 202-then-poll flow, a precise cost formula, a 600-unit job cap, 402 refusal on the free plan, 4-queued/1-running concurrency, daily 20-video/10-minute quotas, and hard 60s/1920x1080/30fps/50MB limits. This is exactly the behavioral context annotations cannot convey.

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?

A single run-on block laced with semicolons that dumps the entire scene capability surface (characters, mouth swaps, shots, music, blends) which properly belongs in video_schema. The output/limit/pricing facts are front-loaded, but the middle is undifferentiated enumeration that makes the operative constraints hard to locate.

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?

For a complex, quota-limited, asynchronous render tool this covers the full operational picture: what is produced, size/duration/resolution caps, price, queue semantics, plan gating, and polling route. An output schema exists, so the description is not obligated to explain return shapes and rightly does not.

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 100% and both parameters (scene, preview) are already documented in the schema, including the preview default. The description restates the preview purpose and the file-cap rationale but adds no new syntax or format detail for the scene document beyond pointing at video_schema/video_examples. Baseline 3 applies when the schema does the work.

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 concrete verb and resource ('Renders a scene') and enumerates the exact output artifacts (video.webm, video.wav, video.vtt, contact sheet, preview GIF), so an agent knows precisely what is produced. It does not explicitly contrast with the obvious siblings (video_still, video_check, video_cost), so it falls short of the 5 bar.

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 actionable conditions: 'preview false' for long/busy scenes that would exceed the 50 MB cap, and routes the agent to video_cost for the price and to the job/jobs tools for completion status. It never states when to prefer video_still or video_check instead, so the when-not side is missing.

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.

Resources