Sceneplane

Create render

render_create

Render a still PNG from a revision through the active camera. engine=cycles_cpu (default) is photoreal and slow; engine=lit_preview uses the scene materials, lights and world in EEVEE for cheaper look development; its shading can differ, especially for transmission. Use it to judge a material or a light rig, and use Cycles for final appearance or transmission checks. engine=preview_fast (Workbench) ignores materials and lighting entirely and only answers questions about shape and layout. Big renders fan out across parallel containers automatically (horizontal strips, stitched server-side); shards=1 forces one instance. The speedup is bounded by your maxConcurrentJobs — strips beyond it would render one after another and pay a container boot each, so the fan-out width is CLAMPED to that policy and the response tells you when it was reduced. Renders above the approval threshold require an approval round-trip. Cycles renders of 16+ samples are DENOISED with OpenImageDenoise and use adaptive sampling, so the sample count is a ceiling rather than a bill and modest counts look far cleaner than they otherwise would; override with the render_settings.update denoise flag. hideObjectIds/hideNamePattern omit objects from THIS RENDER ONLY, with no revision and nothing to undo — that is how you isolate a suspect ("render it without the crystal") in one job instead of bisecting by guesswork. LIGHTS ARE OBJECTS and can be hidden the same way, so hiding all but one is how you find which light is blowing out a highlight — the standard lighting-debug move, and it needs no separate parameter. Returns a durable job handle; the finished PNG is an immutable artifact. purpose=draft preserves existing behavior. purpose=final requires validationJobId from a completed successful deep scene_validate of the exact resolved project revision before any render is queued. Wait for validation, read the full report with job_report, repair/revalidate if needed, then pass that proof. This never starts validation automatically.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`width`	No
`engine`	No	cycles_cpu = photoreal final. lit_preview = EEVEE, honours materials/lights/world for look development. preview_fast = Workbench, shape only, ignores all shading. EEVEE transmission depends on the scene settings and does not establish Cycles equivalence. Use cycles_cpu when judging glass or seeing through a surface.	cycles_cpu
`height`	No
`shards`	No	Parallel fan-out width. 0 (default) decides from render cost; 1 forces a single instance; 2-8 requests that many strips. Any value here is CLAMPED to maxConcurrentJobs: strips past your concurrency cannot overlap, so they would render one after another and add a container boot each, which is slower than shards=1. The response reports the reduction when it happens.
`purpose`	No		draft
`samples`	No
`cameraId`	No
`projectId`	Yes	Stable project ID returned by project_create or projects_list.
`revisionId`	No	"HEAD" (default) uses the project's current head	HEAD
`hideObjectIds`	No
`idempotencyKey`	Yes	Stable caller-chosen key for safe retries of this same request.
`hideNamePattern`	No
`validationJobId`	No	Required for purpose=final: completed passing deep-validation job for this exact project/revision. Known profiles are accepted; the response states that profile and its coverage.
`transparentBackground`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With all four annotations false, the description carries the full behavioral burden and delivers abundantly: fan-out clamping to maxConcurrentJobs, the approval round-trip threshold, OpenImageDenoise with adaptive sampling making samples a ceiling, render-only object hiding with 'no revision and nothing to undo,' the durable job handle and immutable PNG, and the validation precondition for purpose=final. The non-destructive hiding claim aligns with destructiveHint=false; no contradiction exists.

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?

Well front-loaded: the one-sentence purpose leads, then organized blocks cover engine selection, fan-out, approval, denoising, hiding, and validation. It is long, and the shards/engine content partially duplicates the schema's parameter descriptions, but each paragraph adds operational context the schema lacks, so the length is largely earned.

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 14-parameter mutation tool with no output schema and neutral annotations, the description covers engine trade-offs, concurrency behavior, approval gating, validation prerequisites, the durable job-handle return value, and the non-destructive hiding idiom. Nothing an agent needs to call this correctly 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 only 43%, and the description compensates for the highest-risk parameters: purpose (draft vs final validation gating), hideObjectIds/hideNamePattern (render-only, no undo, with a concrete debugging example), samples (denoise ceiling behavior), and engine (use-case framing beyond the enum). A few low-risk parameters like transparentBackground and cameraId are left to self-evident schema fields, so it falls just short of a perfect 5.

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?

The opening sentence 'Render a still PNG from a revision through the active camera' names the verb, resource, output format, and camera path in one clause. The word 'still' cleanly differentiates it from siblings render_animation and render_turntable without needing to name them.

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

Usage Guidelines5/5

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

Gives explicit when-to-use guidance per engine: 'Use it to judge a material or a light rig, and use Cycles for final appearance or transmission checks,' and states preview_fast 'only answers questions about shape and layout.' It also spells out the full purpose=final workflow: wait for validation, read the job_report, repair/revalidate, then pass the proof — including the exclusion that render_create 'never starts validation automatically.'

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

All Sceneplane 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?