Rendering a 50 MB .blend at 1080p from Cursor over MCP: every tool call, measured

I work on JANCTION Render at JasmyLab, so read this as the operator's own run. The numbers are from the production service on 2026-11-02 and nothing is rounded up.

The question I wanted to answer: when an agent in Cursor (or Claude Code, or Codex) renders a real Cycles scene through an MCP server, what does it actually get back at each step, how long does it take, and what does it cost? Not a cube. A 49.7 MB .blend with 386 meshes, 46 packed textures, three lights and a 200-frame animation at 30 fps.

Site: https://render.janction.jp

Setup in Cursor

One click on the "Add to Cursor" button at https://render.janction.jp/cursor-blender, or by hand in ~/.cursor/mcp.json:

{ "mcpServers": { "janction-render": { "url": "https://render.janction.jp/mcp" } } }

Settings → Tools & MCP lists janction-render with 13 tools. The first tool call opens an OAuth page that creates a free key. There is no sign-up form and no card.

One honest note on the run below: I made the calls through the same server from a terminal agent (the janction-render stdio package, pip install janction-render), because the stdio package can send a local .blend directly. Cursor's remote MCP takes an https URL or a bpy script; to send a local file from Cursor, drop it at https://render.janction.jp/upload for a 12-hour link, or let the agent run the CLI. The tools and the responses are the same.

Step 1: read the scene (no GPU)

scene_info(scene_path="toyroom.blend")

Back in a few seconds: Blender 5.2.2, Cycles, frames 1–200 at 30 fps, 1920x1080, 160 samples in the file, active camera Camera.002, 386 meshes, 53 curves, 3 lights, 69 materials, 46 of 48 images packed, missing_files: [], and a scene_id to reuse so the 50 MB is uploaded once.

The agent now knows the frame range and fps without opening Blender, which matters for the final call later.

Step 2: a free preview of four frames

render_preview(scene_id=..., frames="1,67,134,200")

7.67 GPU-seconds, finished in 10 seconds of wall time, cost: free. The verdict from the built-in critic was ok (score 100): "no problems found in exposure, framing or lighting; looks ready for a final render". The response also carried a final_estimate for the whole animation: about 3,224 GPU-seconds for 200 frames at 1080p and 128 samples.

Previews are the step that makes the MCP loop work. The agent sees the image, reads the verdict, fixes the scene if needed, and only then spends money.

Step 3: the estimate, and where it was wrong

render_estimate(scene_id=..., frame_start=1, frame_end=24, width=1920, height=1080, samples=128)

It answered 72 GPU-seconds, about 8 JPY, with confidence: low and a warning: this scene has no completed final-path measurement; run a short contiguous final test, then estimate again.

That warning was right. The 72 seconds came from my key's recent finals (small scenes), not from this scene. The preview-based final_estimate from step 2 (3,224 GPU-seconds for 200 frames, about 16 GPU-seconds a frame) was much closer to what happened next. I have filed that as a bug: when a scene has no final yet, the preview measurement should win over the key's history.

Step 4: 24 contiguous frames on the final path

render_final(scene_id=..., frame_start=1, frame_end=24, width=1920, height=1080,
             samples=128, output="mp4", fps=30, max_yen=30)

Measured:

• 446.6 GPU-seconds for 24 frames, so 18.6 GPU-seconds a frame at 1080p and 128 samples with denoising
• 135 seconds of wall time, because the job was split into 4 chunks across 4 workers
• 24 of 24 frames present, 0 black frames (checked with ffmpeg), MP4 at 1920x1080 and 30 fps
• list price at 0.1 JPY per GPU-second: about 45 JPY

max_yen is the ceiling the agent passes so a wrong estimate cannot turn into a surprise. The service holds that much and charges only the GPU time used.

Step 5: estimate again, now with a measurement

The same render_estimate for frames 1–200 after the test: 4,231 GPU-seconds, about 20 minutes of wall time on 4 workers, about 424 JPY, basis: scene, confidence: high, calibration.final_path_measured: true.

That is the number the agent should show the user before the full render. In this run I stopped here; the 200-frame version of this scene is already on the site as an example.

What it costs, in plain terms

• Reading the scene and the 4-frame preview: 0 JPY (previews stay free up to 2 GPU-minutes a day after the welcome credit)
• 24 frames at 1080p: 446.6 GPU-seconds, about 45 JPY at list price
• The full 200 frames: about 424 JPY, estimated from the test

A new key starts with 100 JPY of GPU time with no card (14 days), and 400 JPY more after saving a card that is not charged. After that it is 0.1 JPY per GPU-second from prepaid credit. Current numbers: https://render.janction.jp/pricing

What to tell your agent

The order that worked: scene_info → render_preview → render_final for a short contiguous test → render_estimate → ask the user → render_final for the whole range. Skipping the test gives you an estimate that can be off by several times, as step 3 shows.

The MCP server, CLI and client are open source: https://github.com/JasmyLab-JANCTION/janction-render

Docs for agents: https://render.janction.jp/llms.txt