Tomorrow Lives Engines

Render a print design

art_render

Renders a design to a PNG with its DPI written in. Without width it renders the canvas at full print size (a shirt-front is 4500 x 5400). width renders a draft that many pixels wide. A render 1200 pixels wide or less costs 1 unit; anything wider costs 5. preview_width adds a small preview, and preview_on sets the shirt colour behind it. Returns print.png (and print.preview.png) as signed URLs.

Input Schema

Name	Required	Description
`width`	No	Output width in pixels. Omit it to render the canvas at full print size; a width above the draft limit is a full-size print and costs more.
`design`	Yes	The print design document, written inline as JSON. Start from art_starter and check it with art_check.
`preview_on`	No	Background colour for the preview as #rrggbb, so a design with transparency can be judged on a shirt colour.
`preview_width`	No	Width in pixels of the small preview image written beside the print.

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.

Changed5 schema fields changedOct 14, 2026

addedInput schema / properties / design / description

Added value: +"The print design document, written inline as JSON. Start from art_starter and check it with art_check."

addedInput schema / properties / preview_on / description

Added value: +"Background colour for the preview as #rrggbb, so a design with transparency can be judged on a shirt colour."

addedInput schema / properties / preview_width / description

Added value: +"Width in pixels of the small preview image written beside the print."

addedInput schema / properties / width / description

Added value: +"Output width in pixels. Omit it to render the canvas at full print size; a width above the draft limit is a full-size print and costs more."

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

A3.8/5.0

Behavior4/5

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

Annotations only declare the safety profile (not read-only, not idempotent, non-destructive), so the description earns credit for disclosing the cost model (1 unit at <=1200px, 5 units wider), the default canvas size (4500x5400 shirt front), and the returned signed URLs. It does not say whether rendering is synchronous or job-backed, which would matter given the sibling job/cancel_job tools.

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?

Four dense sentences, front-loaded with the core action and the default-size behavior, with no filler. The closing sentence about return artifacts is slightly redundant given an output schema exists, which keeps it from a perfect score.

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 4-parameter tool with a nested design document and an output schema, the description covers sizing, cost, preview behaviour, and output artifacts. The remaining gap is the rendering lifecycle (sync vs async, how it relates to the job tools) and any prerequisite that the design be validated first.

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%, so baseline is 3, and the description adds meaning beyond the schema: the concrete 4500x5400 full-print canvas, the 1200-pixel cost boundary, and the fact that preview_on paints the shirt colour behind a transparent design. This is genuine added value rather than restatement.

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 and resource ('Renders a design to a PNG') and adds the distinguishing detail that DPI is written in. It is immediately clear what artifact comes out, though it never contrasts itself with near-name siblings like raster_render or video_render, so an agent must infer which renderer applies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the width-omitted vs width-supplied behavior, which is useful operational guidance, but that guidance is really about a parameter rather than about when to choose this tool over alternatives. No when-not conditions or named alternative tools appear.

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?