Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
JANCTION_RENDER_SERVERYesThe URL of the JANCTION Render server. The public endpoint is https://render.janction.jp.
JANCTION_RENDER_API_KEYNoSet to pin a specific API key; otherwise a temporary API key is issued automatically on first use and cached in ~/.janction-render.json.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
scene_infoA

Read a Blender scene WITHOUT rendering: cameras (and which is active), frame range and fps, resolution, engine, objects by type, lights, materials, whether it is animated, and any linked files that are missing (textures etc. that would render pink). Takes a few seconds, no GPU.

Give the scene as scene_path (.blend or .py file), scene_script (bpy Python code as text, no file needed), or scene_id from a previous call. Call this first for a .blend you did not write yourself, or after writing a bpy script to check what it produced. Use the camera names and frame range in render_preview / render_final. Returns scene_id to reuse in the next calls.

render_previewA

Render a fast, cheap preview of a Blender scene on a JANCTION GPU and show the image.

Use this when the user is making 3DCG with Blender and wants to see how it looks, but has no GPU or local rendering is slow. Give the scene as scene_path (a .blend file OR a bpy Python script), scene_script (bpy code as text; no file and no local Blender needed), or scene_id from a previous call. frames: '' = frame 1; '12' = one frame; '1,8,16,24' or '1-24' = up to 4 frames tiled in ONE image (2x2, each tile labeled with its frame number) so you can judge camera motion and animation. Same GPU cost as one 720p frame. Quality is deliberately low (up to 1280x720, few samples, denoised). Look at the returned image, fix the scene, preview again; when it looks right, ask the user and call render_final. Returns scene_id (reuse it without re-uploading), job_id, saved PNG paths, Blender warnings (e.g. missing textures), GPU seconds, and the expiry time (24h after last use).

render_estimateA

Estimate how long a render will take BEFORE starting it (no GPU time used): GPU seconds, queue wait, wall-clock time as a human-readable string ('about 3 minutes'), and whether it fits today's free quota and the size limits. kind is 'final' (frame_start..frame_end at width x height, samples) or 'preview' (frames like '1-24'). Pass scene_id when you have one: the estimate then uses this scene's own measured render times. Tell the user the result before calling render_final.

render_finalA

Render the final frames (or a video) of a Blender scene on JANCTION GPUs.

Call this after the user approved a preview. Pass scene_id from render_preview (or scene_path / scene_script to upload a new .blend / bpy script). frame_start..frame_end are inclusive; several frames are split across GPUs and joined into output.mp4 (output='mp4', fps), a single frame gives a PNG (output='png'; 'auto' picks). Returns job_id and a time estimate right away; the render runs in the background: poll with render_status, then fetch with render_download. Inputs and results are deleted 24 hours after last use, so download them.

render_statusA

Check a JANCTION render job: status (queued/running/done/failed/canceled), frames done, how many chunks are queued ahead, the ETA (eta.human = remaining time including queue wait), artifacts ready, Blender warnings, and the error plus log tail if it failed. Use render_download once status is done.

render_downloadA

Download a JANCTION render job's files (PNG frames, sheet.png and/or output.mp4) to out_dir (default ~/janction-render/). wait_seconds > 0 first waits up to that long for the job to finish. Returns the local file paths.

render_cancelC

Cancel a queued or running JANCTION render job. GPU time after the cancel is not used.

billingA

Check the account's quota or credit. During the free beta it returns today's GPU-time usage, the daily quota and when it resets (no charges). Once paid plans start: with topup_yen = 0 it confirms any payment the user just made and returns the balance (yen), the price per GPU second and free previews left; with topup_yen > 0 (minimum 500) it returns a Stripe checkout URL to show to the user. Renders are charged by GPU seconds and only for frames that actually rendered.

render_infoA

Show the JANCTION Render connection: server URL, whether GPU workers are online, queue length, and this key's usage. Call this if renders seem stuck or before the first render.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 9 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: scene inspection (scene_info), preview rendering (render_preview), estimation (render_estimate), final rendering (render_final), job lifecycle (render_status/download/cancel), account (billing), and service health (render_info). The only superficially similar names (scene_info vs render_info) target entirely different domains—Blender scene contents vs JANCTION connection—and descriptions make the boundary explicit.

Naming Consistency4/5

Almost all tools use a consistent snake_case, mostly render_* prefix pattern (render_preview, render_final, render_status, render_download, render_cancel, render_info). Minor deviations: scene_info uses a different prefix and billing is a lone noun with no action suffix, but the overall style remains uniform and readable.

Tool Count5/5

Nine tools is well-scoped for a cloud Blender rendering service. Each tool maps to a concrete step in the render workflow (inspect, estimate, preview, final, poll, download, cancel, billing, service status) with no redundant or filler tools.

Completeness4/5

The lifecycle is essentially complete: scene inspection, preview, cost/time estimation, final render, job status, download, cancel, billing, and connection health are all covered. Minor gaps exist—there is no tool to list or retrieve past render jobs/history, and no explicit cleanup management beyond automatic 24h expiry—but core workflows are fully served.

Maintenance

ActivityMaintained
ResponsivenessNo issues