Connecting Blender Cloud Rendering to AI Agents: The 5-Second MCP Timeout Trap and How to Fix It

AI Agents can't truly get work done with code alone — they need to be able to operate external tools. Running a Blender render through an Agent is a textbook example: it needs to upload the scene, estimate the time, submit the job, poll the status, and download the finished output. JANCTION Render has packaged this entire workflow as an MCP Server that both the OpenAI Agents SDK and LangChain can call directly. But before you get it running for the first time, almost everyone hits the same error.

A failure triggered by a 5-second timeout

When you use the OpenAI Agents SDK's MCPServerStreamableHttp to connect to the rendering service, the default tool call timeout is 5 seconds (client_session_timeout_seconds=5). The problem is that the rendering tool only returns a result after the image is actually generated, and queue time doesn't count toward the response.

The official benchmark data illustrates this clearly: calling render_preview on a sample scene with four lighting presets, under the default 5-second timeout, throws McpError: Timed out while waiting for response to ClientRequest. Waited 5.0 seconds. after exactly 5.1 seconds. Once you change the timeout to 120 seconds, the same task returns in 7.3 seconds, consuming 4.03 GPU-seconds.

What's more insidious: if the scene uses only one preset, the return time falls between 4.7 and 5.0 seconds — right at the edge of the default timeout. This means everything looks fine during quick tests, and then fails immediately once you switch to a real scene. Explicitly setting the timeout is not an optimization — it's mandatory.

MCP (Model Context Protocol) is a protocol proposed and open-sourced by Anthropic in late 2024, designed to establish a unified calling contract between LLM applications and external tools and data sources. It abstracts tools, resources, and prompt templates into standard primitives, transported over JSON-RPC, so the same Server can be reused across different frameworks.

MCP supports multiple transport layers: stdio for local processes, and streamable_http for remote HTTP services with streaming responses and session management. Because MCP follows a request-response model, the client waits for the server's return after sending tools/call, with no progress push in between — so when a tool's execution exceeds the client's configured timeout threshold, the connection is deemed failed and throws McpError. This is precisely the root cause of the 5-second default timeout trap in this article — the protocol itself has no "background execution" semantics, so long-running tasks can only be handled through a combination of timeout settings and job id polling.

OpenAI Agents SDK integration

The server endpoint is a remote MCP Server: https://render.janction.jp/mcp. Authentication uses a Bearer Token, obtained by calling curl -s -X POST https://render.janction.jp/v1/keys — no registration required.

The only key change in the connection code is one line — set client_session_timeout_seconds to 120:

async with MCPServerStreamableHttp(name="janction-render", client_session_timeout_seconds=120,
                                   params={"url": "https://render.janction.jp/mcp",
                                           "headers": {"Authorization": "Bearer jr_..."}}) as render:
    agent = Agent(name="3D artist", instructions="Render Blender scenes with janction-render.", mcp_servers=[render])
    result = await Runner.run(agent, "Render a preview of https://render.janction.jp/samples/cube_scene.py")

The Agent will see 12 available tools, and a typical call chain is scene_info → render_preview → render_estimate → render_final → render_status → render_download. There's an easily overlooked design here: long renders don't require a longer timeout. Short video tasks return a link directly in a single call, while long tasks return a job id, then use render_download(job_id, wait_seconds=45) to wait up to 45 seconds per call. 120 seconds is enough to cover all tools.

MCPServerStreamableHttp is the MCP client wrapper provided by the OpenAI Agents SDK. Its client_session_timeout_seconds parameter controls the maximum time the underlying MCP session waits for a single request response, not the total runtime of the entire Agent. It's important to distinguish: the Agent's Runner.run has its own run-level timeout (typically long or infinite by default), while each tool call is separately constrained by the MCP session timeout. The two operate at different levels and don't override each other.

So even if you increase client_session_timeout_seconds, it won't slow down fast tools — it merely relaxes the "wait ceiling" and only takes effect when a request actually takes time. Conversely, if you only adjust the run-level timeout and ignore the session timeout, tool calls will still be cut off at the 5-second mark. Understanding this layer relationship is the key to diagnosing all MCP timeout issues.

LangChain integration

Using langchain-mcp-adapters (0.3.2), the same server acts as an entry in MultiServerMCPClient. The transport layer name is streamable_http:

client = MultiServerMCPClient({"janction-render": {"url": "https://render.janction.jp/mcp", "transport": "streamable_http",
                                                   "headers": {"Authorization": "Bearer jr_..."}}})
tools = await client.get_tools()

The retrieved tool list includes render_preview, render_final, render_status, render_download, and more. The overall integration logic is consistent with the OpenAI Agents SDK, differing only in the framework-level wrapper.

A pure Python approach without an Agent framework

If the rendering logic is determined by your own code and you just need the finished output, the Python client is much shorter. After pip install janction-render, the first call automatically creates a free key and stores it in ~/.janction-render.json:

from janction_render.client import Client

c = Client()
scene = c.upload("scene.py")  # supports bpy scripts, .blend .glb .fbx .usd .obj
job = c.submit(scene["scene_id"], kind="final", frame_start=1, frame_end=48, output="mp4")
job = c.wait(job["job_id"], timeout=1800)
print(job["status"], c.download(job["job_id"], "out", only="mp4"))

For service-oriented rather than script-oriented scenarios, you can pass a notify_url (must be https) to POST /v1/jobs and receive a single JSON POST callback when the task completes, eliminating polling. Also send an Idempotency-Key request header to avoid accidentally starting a second task during retries.

Cost structure and Agent budget control

Each new key comes with 500 yen of GPU time (5000 GPU-seconds), valid for 14 days, with no card binding required. After that, preview tasks are free up to 2 GPU-minutes per day, and other GPU time is billed at 0.1 yen per GPU-second. An official benchmark shows that a 24-frame 720p MP4 at 64 samples consumes about 58 GPU-seconds, roughly 6 yen.

When the quota is exhausted, tasks are rejected before running — the HTTP API returns 402 with a top-up link, and the MCP tool result includes the same link for manual opening. Each key also has per-task and per-day spending caps, which is a necessary guardrail for scenarios where Agents spend money autonomously.

GPU-second is a common billing unit for GPU-intensive services like rendering and training, referring to the total time a task actually occupies the GPU. It differs from wall-clock time: when multiple tasks run in parallel, wall-clock time overlaps, but each task's GPU-seconds accumulate independently. For example, a task that occupies a full GPU for 10 seconds consumes 10 GPU-seconds; if it occupies only half the GPU's compute for 10 seconds, it counts as 5 GPU-seconds.

"4.03 GPU-seconds" in the article means exactly this — the 7.3 seconds of wall-clock time from submission to return includes queueing, scheduling, and I/O overhead, while only the 4.03 seconds of actual GPU work is billed. This billing model is friendly to Agent scenarios: queue waiting doesn't burn money, but it also means you can't reduce costs by "queuing more." Understanding the distinction between GPU-seconds and wall-clock time is a prerequisite for estimating Agent rendering costs and setting budget guardrails.

Key takeaways

The real value of this case isn't the rendering service itself, but the general trap it exposes when LLM Agents call external tools: framework default timeouts are designed for interactive calls, while real tool execution times are often unpredictable. Any MCP tool involving time-consuming tasks like rendering, compilation, or data processing should have its timeout explicitly configured at integration time. At the same time, handling long tasks with a job id plus polling download is more robust than simply extending the timeout — it neither occupies the Agent's session time nor makes failure retries harder.

One-line Summary

When integrating the JANCTION Render MCP Server, the default 5-second tool timeout is the biggest trap — you must explicitly set it to 120 seconds.

Paragraph Summary

Using Blender rendering with AI Agents as an example, the article reveals a general trap when LLM Agents call external tools: the OpenAI Agents SDK's MCPServerStreamableHttp defaults to only 5 seconds of tool timeout, while rendering tasks return in 4.7 to 7.3 seconds — so quick tests pass, but real scenarios always fail. The author presents three integration approaches: OpenAI Agents SDK, LangChain (streamable_http transport), and a pure Python client, all with the timeout explicitly set to 120 seconds. Long tasks are handled via job id plus render_download polling, rather than simply extending the timeout. On cost: new keys come with 500 yen of GPU time (5000 GPU-seconds, valid 14 days), then billed at 0.1 yen per GPU-second, with notify_url callbacks and Idempotency-Key deduplication support. The core conclusion: framework default timeouts are designed for interactive calls, and any MCP tool involving time-consuming tasks should have its timeout explicitly configured.