Tomorrow Lives Engines

Render a shot

raster_render

Renders a shot (a camera through the engine's world: forms from the sculptor, people and animals from the rig, open country, primitives, under the game's own sky, sun, shadow and haze) at t seconds as shot.png. width and height (both or neither) set the size, else the shot's own; at most 1920 by 1080 either way up. Costs 3 units plus 1 for each 1.6 megapixels: 4 at 1280x720, 5 at 1920x1080. A shot can draw a world of ours, named by id and never by a path (copperside and low-quarter): a zone subject {"kind": "zone", "world": "copperside", "zone": "city", "cut": [x, z, radius], "crowd": false} draws a street (copperside's start zone is city), and a terrain subject with the same world key draws its country. A street draws its crowd by default, which is most of its price: a still in a world costs 5 units more, one that draws the crowd 26.2 more again. 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).

Input Schema

Name	Required	Description
`t`	No	The moment to draw, in seconds from the shot's start, for a shot with motion.
`shot`	Yes	A shot document written inline: a camera, the sun and air, and subjects. raster_schema lists every key.
`width`	No	Output width in pixels, 16 to 1920; overrides the shot's own.
`height`	No	Output height in pixels, 16 to 1920; overrides the shot's own.

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.

Changed4 schema fields changedOct 14, 2026

addedInput schema / properties / height / description

Added value: +"Output height in pixels, 16 to 1920; overrides the shot's own."

addedInput schema / properties / t / description

Added value: +"The moment to draw, in seconds from the shot's start, for a shot with motion."

addedInput schema / properties / width / description

Added value: +"Output width in pixels, 16 to 1920; overrides the shot's own."

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?

Annotations only declare write/openWorld/idempotent=false; the description adds substantial behavior beyond them — exact cost model (3 units + 1 per 1.6MP; 5 more for a still, 26.2 more for a crowd), asynchronous queued-job semantics (202 + job id, poll via GET /api/agents/jobs/<job>), and plan-gating with 402.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Front-loaded with the core action, but the body is a dense, single-paragraph wall of text mixing cost, subjects, and job semantics. Every fact is relevant yet the packing hurts scannability; some pricing restatement could be tightened.

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?

An output schema exists, so return-format explanation is unnecessary, and the description still covers cost, async job polling, and plan gating. For a complex nested-subject tool it is nearly complete, though linking raster_schema for the shot document is only referenced from the schema rather than the description.

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 100% (baseline 3), but the description meaningfully enriches the otherwise opaque 'shot' object with concrete subject examples (zone vs terrain, world key, cut, crowd) and clarifies the width/height pairing rule and the effective 1920x1080 cap beyond the schema's per-field maxima.

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 specific verb and resource: 'Renders a shot ... as shot.png', and enumerates what the shot draws (forms, rig, country, sky/sun/shadow/haze). This clearly distinguishes it from siblings like raster_check, raster_schema, and the video_* render tools.

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 strong context for use: it explains the world/zone subject forms, the default crowd, and the paid-plan requirement with 402 on the free plan. It stops short of naming alternatives (e.g. when to prefer raster_check first), so it is clear context without explicit exclusions.

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?