3D New Era AI

Overview Schema Source Related Servers Discussions Admin

Render a photo

render_photo

Read-only

Generate photorealistic images of 3D home designs with realistic lighting, sun position, and materials. Returns PNG; supports draft, good, or best quality and estimate or cancel options.

Instructions

Realistic photo (path traced: sun from compass location and time, lamps, glass). cam=i stored view, or view=visitor/aerial (yaw,pitch). quality draft (~10 s) | good | best; hour = local solar time (e.g. 9, 15.5, 20); w/h small. Returns PNG. One runs at a time, on at most half the cores (4): threads lowers that, max_s stops it past a deadline, estimate=true answers the budget and the work (pixels, rays, triangles, memory) without rendering, cancel=true stops the one running (sessions shows it).

Input Schema

TableJSON Schema

Name	Required	Description
`h`	No	Height px (default 360, 64..1200)
`w`	No	Width px (default 480, 64..1600)
`cam`	No	Stored point of view index
`yaw`	No	Aerial turn, degrees (default 60)
`hour`	No	Local solar hour, 0–24
`view`	No	Default `aerial`
`max_s`	No	Seconds it may take; past them it stops, and nothing is returned
`pitch`	No	Aerial height angle, degrees (default 40)
`cancel`	No	Stop the photo being rendered now (`sessions` shows it)
`quality`	No	Default `draft`
`threads`	No	Threads it may use, under the budget (half the cores, at most 4)
`estimate`	No	Answer the budget and what the photo would take, without rendering

Output Schema

TableJSON Schema

Name	Required	Description	Default
`text`	No
`work`	No
`budget`	No
`measured`	No
`mimeType`	No
`memory_mb`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedv3.0.0Sep 30, 2026

addedInput schema / properties / cancel

Added value: +{
+  "description": "Stop the photo being rendered now (`sessions` shows it)",
+  "type": "boolean"
+}

addedInput schema / properties / estimate

Added value: +{
+  "description": "Answer the budget and what the photo would take, without rendering",
+  "type": "boolean"
+}

addedInput schema / properties / max_s

Added value: +{
+  "description": "Seconds it may take; past them it stops, and nothing is returned",
+  "type": "number"
+}

changedInput schema / properties / quality / description

Previous value: -"`draft` (default), `good`, `best`"New value: +"Default `draft`"

addedInput schema / properties / quality / enum

Added value: +[
+  "draft",
+  "good",
+  "best"
+]

addedInput schema / properties / threads

Added value: +{
+  "description": "Threads it may use, under the budget (half the cores, at most 4)",
+  "type": "integer"
+}

changedInput schema / properties / view / description

Previous value: -"`aerial` (default) or `visitor`"New value: +"Default `aerial`"

addedInput schema / properties / view / enum

Added value: +[
+  "aerial",
+  "visitor"
+]

addedOutput schema / properties / budget
```
Added value: +{
+  "type": "object"
+}
```
addedOutput schema / properties / measured
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / memory_mb
```
Added value: +{
+  "type": "number"
+}
```

removedOutput schema / properties / mimeType / description

Removed value: -"Type of the image in the content (image/png)"

addedOutput schema / properties / text
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / work
```
Added value: +{
+  "type": "object"
+}
```
removedOutput schema / required
```
Removed value: -[
-  "mimeType"
-]
```

First observedv0.1.0Sep 24, 2026

TDQS

A4/5.0

Behavior5/5

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

Goes well past the annotations (readOnlyHint/openWorldHint) to disclose real behavioral traits: one render at a time, capped at half the cores (4), threads lowers that, max_s cancels past a deadline returning nothing, cancel=true stops the running job and sessions shows it. This is unusually rich operational context.

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?

Dense but front-loaded on the core purpose, with each clause carrying information about parameters, quality, hour semantics, and concurrency. The heavy parenthetical/punctuation packing makes it slightly harder to parse but nothing is filler.

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 12-parameter tool with an output schema (so return format need not be re-explained beyond the 'Returns PNG' note) and full schema coverage, the description covers rendering semantics, budget control, and cancellation adequately. Only explicit alternative-routing to sibling render tools is missing.

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 already 100%, so baseline is 3; the description adds meaning beyond it by defining cam as 'i stored view' and hour as local solar time with concrete examples (9, 15.5, 20), plus the view=visitor/aerial yaw/pitch relationship. Small omissions like w/h remain, but it adds genuine value.

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+resource and scope: a path-traced realistic photo with sun position from compass/time, lamps, glass. It is clearly distinguishable from render_plan and render_3d by the word 'Realistic photo' and the path-tracing detail, though it never names those siblings.

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?

Usage is implied rather than stated: quality tiers, hour as local solar time, and estimate=true to check the budget before rendering all hint at when to use it. But there is no explicit 'use this instead of render_3d/render_plan when...' routing, and no stated prerequisites.

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