JANCTION Render

Overview Schema Source Related Servers Discussions Admin

scene_info

Idempotent

Inspect Blender scenes without rendering: list cameras, frame range, fps, resolution, objects, lights, materials, animation, and missing linked files; reuse the scene_id for renders.

Instructions

Read a Blender scene without rendering (a few seconds, no GPU time): cameras and the active one, frame range and fps, resolution, objects by type, lights, materials, whether it is animated, and missing linked files that would render pink. Use it for a .blend you did not write, or to check what a bpy script built. Returns scene_id; pass it to render_preview and render_final instead of sending the scene again.

Input Schema

TableJSON Schema

Name	Required	Description
`assets`	No	Extra files sent with the scene: local paths (textures, glTF .bin), https links, or 'polyhaven:<id>' CC0 assets from asset_search. A .blend finds them through relative paths (same folder); a script through os.environ['JR_ASSETS_DIR'] or the jr_assets helpers.
`blender`	No	Blender version: '' (default: a .blend opens with the version it was saved in, other scenes with 5.0) or '5.0' / '5.2' (also '4.5', '4.2', '3.6'; a script that stops on Blender 5 because of an older API is rendered again on those automatically) to choose.
`scene_id`	No	scene_id returned by an earlier call (reuses the uploaded scene without sending it again).
`scene_url`	No	https link to a .blend, a .py script or a 3D file (.glb/.gltf/.fbx/.usd/.obj/.stl/.ply/.abc); the service fetches it (e.g. the sample https://render.janction.jp/samples/cube_scene.py, or a 12-hour /upload link). A .gltf or .obj also brings its .bin / .mtl / textures from the same folder.
`scene_path`	No	Local path to the scene: a .blend file, a bpy .py script, or a 3D file (.glb/.gltf/.fbx/.usd/.obj/.stl/.ply/.abc, imported into an empty scene). Uploaded once; reuse the returned scene_id afterwards.
`scene_script`	No	The scene as bpy Python code (text). No file and no local Blender needed; the service runs it in Blender 5.0 (5.2 with blender='5.2'). Blender 5.0 API notes: materials are node-based, so set a colour on the Principled BSDF (mat.node_tree.nodes['Principled BSDF'].inputs['Base Color'].default_value = (r, g, b, 1)); mat.diffuse_color only affects the viewport; do not set Material.use_nodes. Animate with obj.keyframe_insert() (action.fcurves no longer exists; set bpy.context.preferences.edit.keyframe_new_interpolation_type = 'LINEAR' first for constant speed). Build the scene, camera and frame range only; leave resolution, samples and denoising to the service. Helpers: `import jr_assets`, then jr_assets.frame_camera(margin=1.1) points the camera at every object and fits them in the frame; jr_assets.import_model('<id>'), jr_assets.material('<id>') and jr_assets.world_hdri('<id>') use Poly Haven assets passed in assets.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.4.120Oct 15, 2026

changedInput schema / properties / blender / description

Previous value: -"Blender version: '' (default: a .blend opens with the version it was saved in, other scenes with 5.0) or '5.0' / '5.2' to choose."New value: +"Blender version: '' (default: a .blend opens with the version it was saved in, other scenes with 5.0) or '5.0' / '5.2' (also '4.5', '4.2', '3.6'; a script that stops on Blender 5 because of an older API is rendered again on those automatically) to choose."

Changed6 schema fields changedv0.4.119Oct 15, 2026

addedInput schema / properties / assets / description

Added value: +"Extra files sent with the scene: local paths (textures, glTF .bin), https links, or 'polyhaven:<id>' CC0 assets from asset_search. A .blend finds them through relative paths (same folder); a script through os.environ['JR_ASSETS_DIR'] or the jr_assets helpers."

addedInput schema / properties / blender / description

Added value: +"Blender version: '' (default: a .blend opens with the version it was saved in, other scenes with 5.0) or '5.0' / '5.2' to choose."

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 / scene_path / description

Added value: +"Local path to the scene: a .blend file, a bpy .py script, or a 3D file (.glb/.gltf/.fbx/.usd/.obj/.stl/.ply/.abc, imported into an empty scene). Uploaded once; reuse the returned scene_id afterwards."

addedInput schema / properties / scene_script / description

Added value: +"The scene as bpy Python code (text). No file and no local Blender needed; the service runs it in Blender 5.0 (5.2 with blender='5.2'). Blender 5.0 API notes: materials are node-based, so set a colour on the Principled BSDF (mat.node_tree.nodes['Principled BSDF'].inputs['Base Color'].default_value = (r, g, b, 1)); mat.diffuse_color only affects the viewport; do not set Material.use_nodes. Animate with obj.keyframe_insert() (action.fcurves no longer exists; set bpy.context.preferences.edit.keyframe_new_interpolation_type = 'LINEAR' first for constant speed). Build the scene, camera and frame range only; leave resolution, samples and denoising to the service. Helpers: `import jr_assets`, then jr_assets.frame_camera(margin=1.1) points the camera at every object and fits them in the frame; jr_assets.import_model('<id>'), jr_assets.material('<id>') and jr_assets.world_hdri('<id>') use Poly Haven assets passed in assets."

addedInput schema / properties / scene_url

Added value: +{
+  "default": "",
+  "description": "https link to a .blend, a .py script or a 3D file (.glb/.gltf/.fbx/.usd/.obj/.stl/.ply/.abc); the service fetches it (e.g. the sample https://render.janction.jp/samples/cube_scene.py, or a 12-hour /upload link). A .gltf or .obj also brings its .bin / .mtl / textures from the same folder.",
+  "title": "Scene Url",
+  "type": "string"
+}

Changed2 schema fields changedv0.2.2Oct 1, 2026

addedInput schema / properties / assets

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Assets"
+}

addedInput schema / properties / blender

Added value: +{
+  "default": "",
+  "title": "Blender",
+  "type": "string"
+}

First observedv0.2.1Sep 30, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare idempotentHint=true and destructiveHint=false; the description adds genuinely useful cost/behavior context ('a few seconds, no GPU time') and clarifies that this is a non-rendering inspection step, which reconciles the readOnlyHint=false annotation with what the agent sees. It does not cover auth requirements, quotas, or failure modes, so 4 rather than 5.

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

Conciseness5/5

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

Three sentences, front-loaded with the verb and the no-render constraint, then the payload list, then the routing rule. Every clause carries information; nothing is padded or repeated.

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 values need no explanation, and the description still sketches what is inspected. Combined with the scene_id hand-off instruction, an agent has everything needed to call it and chain it into rendering, though it says nothing about what happens when the scene fails to load or has unresolvable assets.

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% and the per-parameter text is unusually detailed (Blender API notes, asset resolution rules, jr_assets helpers), so the schema does the heavy lifting and baseline is 3. The description only restates the scene_id reuse rule that the schema already documents, adding no new parameter-level meaning.

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 ('Read a Blender scene') and enumerates exactly what is returned: cameras, frame range, fps, resolution, objects, lights, materials, animation state, missing linked files. That enumeration distinguishes it cleanly from render_preview/render_final, which produce images rather than metadata.

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 conditions ('a .blend you did not write', 'check what a bpy script built') and an explicit alternative/sequencing rule: pass the returned scene_id to render_preview and render_final instead of re-uploading. Nothing about tool selection is left to inference.

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

Deploy Server