Tomorrow Lives Engines

Render a video still

video_still

Renders one frame of a scene at t seconds as a PNG at the scene's size: the way to look at a moment (just after a transition, mid-reveal, the last frame) before rendering the whole video. Costs 1 unit, plus a shot's price when the scene has shots (3 plus 1 for each 1.6 megapixels). 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). Returns still.png.

Input Schema

Name	Required	Description	Default
`t`	Yes	The moment to draw, in seconds from the scene's start.
`scene`	Yes	A 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.

Output Schema

Name	Required	Description
`ms`	No	Milliseconds the run took.
`job`	Yes	The job id; the job tool reads it.
`verb`	No	The tool that made it.
`files`	No	Files made, each with a name, type, size and a signed URL.
`units`	No	Units this call cost.
`result`	No	The engine's own answer, a JSON document.
`status`	No	queued when the job runs in the background.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

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"
+}

First observedOct 14, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: exact cost (1 unit plus a shot's price formula), the queued-job contract (202 + job id, poll via GET /api/agents/jobs/<job> or the job tool), and the free-plan 402 refusal with the reason. These are behavioral traits the 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.

Conciseness4/5

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

Front-loaded with the purpose before cost, async semantics, and plan gating. Dense and mostly waste-free, though the cost and plan passages are packed into a single long run-on sentence.

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, paid, asynchronous tool it covers cost, job lifecycle, polling path, and plan eligibility, and an output schema exists so return-value detail is unnecessary. An agent has everything needed to invoke and follow up correctly.

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%, so t and scene are already documented in the schema; the description only restates 't seconds' and 'the scene's size.' Baseline 3 applies when the schema does the heavy lifting.

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?

States a precise verb+resource+output: renders one frame at t seconds as a PNG at the scene's size. It is clearly distinguished from the whole-video sibling by contrasting 'one frame of a scene' with rendering 'the whole video.'

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 concrete moments for which it is the right tool (just after a transition, mid-reveal, the last frame) and positions it as a pre-check before the full render, implicitly pointing at video_render and naming the job tool for polling. No explicit 'when-not' beyond the plan restriction.

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

All Tomorrow Lives Engines 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?