JANCTION Render

Overview Schema Source Related Servers Discussions Admin

render_estimate

Read-onlyIdempotent

Estimate GPU seconds, queue wait, wall-clock time, and quota fit before starting a Blender render; check size limits and decide whether to split or run a test.

Instructions

Estimate a render before starting it (no GPU time): GPU seconds, queue wait, the wall-clock time as text (estimate.human, e.g. 'about 3 minutes') and whether it fits the free GPU time left (the welcome credit, or 2 preview GPU-minutes a day after it) and the size limits. Call it before render_final when the time or quota is uncertain, the job is longer than about 24 frames or above 720p, or the user asks how long it takes; tell the user the result. With scene_id the estimate uses measured render times and returns calibration.final_path_measured. If false, treat it as preliminary: run a short contiguous final-path test and estimate again before the full animation. It also says when to split a job.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`kind`	No	'final' (frame_start..frame_end at width x height, samples) or 'preview' (frames like '1-24').	final
`width`	No	Output width in pixels (previews are capped at 1280x720 keeping the aspect ratio; a final frame can have at most 1920x1080 pixels on free time, 3840x2160 on prepaid credit).
`frames`	No	Preview frames: '' = frame 1; '12' = one frame; '1,8,16,24' or '1-24' = up to 4 frames tiled in one labeled image (to judge camera motion and animation; same GPU time as one 720p frame).
`height`	No	Output height in pixels (previews are capped at 1280x720 keeping the aspect ratio; a final frame can have at most 1920x1080 pixels on free time, 3840x2160 on prepaid credit).
`preset`	No	Purpose preset: 'product' (4 studio shots at 0/90/180/270 deg on a plain backdrop; the final gives 4 PNGs at 1440x1440), 'turntable' (one full turn as an MP4, studio light, plain backdrop), 'animation' (the scene's own camera, lights and frame range; the scene is read first when the range is unknown), or '' (none). It fills what you do not pass; environment, orbit_frames, width/height and the frames still win when given.
`cameras`	No	Several camera object names (up to 8) rendered from the same frame in one job: the preview tiles them in one labeled sheet, the final returns one PNG/EXR per camera (camera_files maps names to files). For product shots from fixed angles. Not combinable with orbit, environment='compare' or camera.
`samples`	No	Cycles samples per pixel (preview: up to 32, default 16; final: default 128).
`scene_id`	No	scene_id returned by an earlier call (reuses the uploaded scene without sending it again).
`frame_end`	No	Last frame to render (inclusive); equal to frame_start for a single image. With orbit=True and no frame_end, one full turn is rendered.
`frame_start`	No	First frame to render (inclusive).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.4.119Oct 15, 2026

addedInput schema / properties / cameras

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Several camera object names (up to 8) rendered from the same frame in one job: the preview tiles them in one labeled sheet, the final returns one PNG/EXR per camera (camera_files maps names to files). For product shots from fixed angles. Not combinable with orbit, environment='compare' or camera.",
+  "title": "Cameras"
+}

addedInput schema / properties / frame_end / description

Added value: +"Last frame to render (inclusive); equal to frame_start for a single image. With orbit=True and no frame_end, one full turn is rendered."

addedInput schema / properties / frame_start / description
```
Added value: +"First frame to render (inclusive)."
```

addedInput schema / properties / frames / description

Added value: +"Preview frames: '' = frame 1; '12' = one frame; '1,8,16,24' or '1-24' = up to 4 frames tiled in one labeled image (to judge camera motion and animation; same GPU time as one 720p frame)."

addedInput schema / properties / height / description

Added value: +"Output height in pixels (previews are capped at 1280x720 keeping the aspect ratio; a final frame can have at most 1920x1080 pixels on free time, 3840x2160 on prepaid credit)."

addedInput schema / properties / kind / description

Added value: +"'final' (frame_start..frame_end at width x height, samples) or 'preview' (frames like '1-24')."

addedInput schema / properties / preset

Added value: +{
+  "default": "",
+  "description": "Purpose preset: 'product' (4 studio shots at 0/90/180/270 deg on a plain backdrop; the final gives 4 PNGs at 1440x1440), 'turntable' (one full turn as an MP4, studio light, plain backdrop), 'animation' (the scene's own camera, lights and frame range; the scene is read first when the range is unknown), or '' (none). It fills what you do not pass; environment, orbit_frames, width/height and the frames still win when given.",
+  "title": "Preset",
+  "type": "string"
+}

addedInput schema / properties / samples / description

Added value: +"Cycles samples per pixel (preview: up to 32, default 16; final: default 128)."

addedInput schema / properties / scene_id / description

Added value: +"scene_id returned by an earlier call (reuses the uploaded scene without sending it again)."

addedInput schema / properties / width / description

Added value: +"Output width in pixels (previews are capped at 1280x720 keeping the aspect ratio; a final frame can have at most 1920x1080 pixels on free time, 3840x2160 on prepaid credit)."

First observedv0.2.1Sep 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint true and destructiveHint false. The description adds rich behavioral context: no GPU time consumed, measured vs preliminary estimates, calibration.final_path_measured semantics, splitting advice, and the consequence of a false preliminary flag. This far exceeds what annotations provide.

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?

The description is information-dense and front-loaded with the key outputs. It is a single long paragraph but every sentence carries useful signal. Slightly verbose but appropriate for the complexity of the tool.

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?

Given 10 parameters, no required params, full schema coverage, and an output schema present, the description covers the essential behavioral context: what the estimate returns, when to call it, how to interpret preliminary results, and when to split jobs. Nothing critical is missing.

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 description coverage is 100%, so all 10 parameters are already documented in the schema. The description adds marginal semantic value by explaining what the estimate does with scene_id and what calibration output means, but it doesn't add parameter syntax beyond what the schema already provides. Baseline 3 is appropriate.

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 (Estimate) and resource (a render) and immediately specifies the output signals: GPU seconds, queue wait, human-readable wall-clock text, and quota fit. Clearly distinguishable from render_final, render_preview, and the other siblings.

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?

Explicit when-to-use guidance: 'Call it before render_final when the time or quota is uncertain, the job is longer than about 24 frames or above 720p, or the user asks how long it takes.' It also names the alternative (render_final) and gives concrete thresholds and exclusion conditions.

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

Deploy Server