kernelcad

Get Latest Render

get_latest_render

Read-only

Render a project's current model server-side and return it as an inline image so you can SEE what you built. Prefer open_in_studio for the happy path — it already includes an iso PNG preview in the same publish result when previewDelivered is true. Use this tool for a different view, a contact sheet (view:"all"), or when you only have a slug and are not publishing. Call with that slug to inspect whether the build looks right. CRITICAL — the image is rendered from the MODEL on the server; it does NOT reflect the user's Studio camera, zoom, or screen. NEVER ask the user to rotate, zoom, pan, move the camera, close a slider, or change their view to help you see — you cannot affect their screen and it cannot affect this render. To see a different angle, call this tool again with a different view. By DEFAULT (omit view, or view:"all") it returns a CONTACT SHEET of all six canonical views in one labeled image — a 3×2 grid, top row [iso, front, right], bottom row [back, left, top] — so you can judge the model from every side regardless of its orientation (e.g. to find which side has the doors). Pass a single view (iso/front/back/left/right/top) for one large render of that angle. DETERMINISTIC: the same model + view always returns the same bytes — identical bytes are NOT a stale/lagging snapshot. If you changed the model, push it with open_in_studio FIRST, then re-render to see the change. The image is always current and never a blank capture. Colors and shading match Studio (same palette / base-material color). The slug is the capability: no OAuth for public/unlisted; private projects require the owner signed in. The PNG is base64-inlined as a real image block by default; pass paths_only: true for metadata only. No renderable geometry or a mesh failure → { ok: false, error, hint }, never a blank image.

Input Schema

TableJSON Schema

Name	Required	Description
`slug`	Yes	Project slug from open_in_studio/get_project/a /p/<slug> link. The slug is the capability — public/unlisted projects need no OAuth; private projects require the owner to be signed in.
`view`	No	View to render. Default "all" = a labeled contact sheet of every canonical angle (iso/front/back/left/right/top) — best for judging the whole model. Pass a single view name for one large render of that angle.
`paths_only`	No	Controls PNG delivery. Default false: base64-inline the rendered PNG so clients that cannot fetch a URL over HTTP (e.g. a sandboxed agent) can still see it. Set true to return only metadata (smaller response).

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	No	Whether a render was produced.
`hint`	No	Next-action hint when ok is false.
`view`	No	The view that was rendered (when ok).
`bytes`	No	PNG byte length (when ok).
`error`	No	Error code when ok is false (e.g. "empty_geometry", "mesh_failed").
`width`	No	Rendered image edge in px (when ok).
`height`	No	Rendered image edge in px (when ok).
`image_b64`	No	Base64-encoded PNG bytes, present when inlined (paths_only=false) and under the size cap.
`truncated`	No	Set when inline was requested but the PNG exceeded the size cap.

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedJun 16, 2026

addedInput schema / properties / paths_only

Added value: +{
+  "description": "Controls PNG delivery. Default false: base64-inline the rendered PNG so clients that cannot fetch a URL over HTTP (e.g. a sandboxed agent) can still see it. Set true to return only metadata (smaller response).",
+  "type": "boolean"
+}

addedInput schema / properties / view

Added value: +{
+  "description": "View to render. Default \"all\" = a labeled contact sheet of every canonical angle (iso/front/back/left/right/top) — best for judging the whole model. Pass a single view name for one large render of that angle.",
+  "enum": [
+    "all",
+    "iso",
+    "front",
+    "back",
+    "left",
+    "right",
+    "top"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / bytes

Added value: +{
+  "description": "PNG byte length (when ok).",
+  "type": "number"
+}

removedOutput schema / properties / capturedAt

Removed value: -{
-  "description": "ISO timestamp the render was captured (when ok).",
-  "type": "string"
-}

changedOutput schema / properties / error / description

Previous value: -"Error code when ok is false (e.g. \"no_render\")."New value: +"Error code when ok is false (e.g. \"empty_geometry\", \"mesh_failed\")."

addedOutput schema / properties / height

Added value: +{
+  "description": "Rendered image edge in px (when ok).",
+  "type": "number"
+}

addedOutput schema / properties / image_b64

Added value: +{
+  "description": "Base64-encoded PNG bytes, present when inlined (paths_only=false) and under the size cap.",
+  "type": "string"
+}

changedOutput schema / properties / ok / description

Previous value: -"Whether a render was found."New value: +"Whether a render was produced."

addedOutput schema / properties / truncated

Added value: +{
+  "description": "Set when inline was requested but the PNG exceeded the size cap.",
+  "type": "boolean"
+}

removedOutput schema / properties / url

Removed value: -{
-  "description": "Signed URL for the latest rendered PNG (when ok).",
-  "type": "string"
-}

addedOutput schema / properties / view

Added value: +{
+  "description": "The view that was rendered (when ok).",
+  "type": "string"
+}

addedOutput schema / properties / width

Added value: +{
+  "description": "Rendered image edge in px (when ok).",
+  "type": "number"
+}

Changed1 schema field changedJun 15, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "capturedAt": {
+      "description": "ISO timestamp the render was captured (when ok).",
+      "type": "string"
+    },
+    "error": {
+      "description": "Error code when ok is false (e.g. \"no_render\").",
+      "type": "string"
+    },
+    "hint": {
+      "description": "Next-action hint when ok is false.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "Whether a render was found.",
+      "type": "boolean"
+    },
+    "url": {
+      "description": "Signed URL for the latest rendered PNG (when ok).",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

AddedJun 14, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true and destructiveHint=false; description adds critical behavior: render is from server model not user camera, deterministic bytes are not stale, no OAuth for public/unlisted, private requires owner signed in. Also describes error behavior (never blank image, {ok:false,error,hint}).

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?

Long but every paragraph carries a distinct operational constraint: camera independence, determinism, auth, output mode, error behavior. Front-loaded with purpose and sibling routing before low-level details. No filler.

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?

For a render tool with output schema present, the description covers invocation, view semantics, auth prerequisites, update ordering, and failure mode. No missing operational detail an agent needs to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% but description enriches semantics: explains default 'all' as a labeled 3×2 contact sheet with specific ordering, single view behavior, paths_only tradeoff, and slug-as-capability auth implications. Exceeds schema baseline.

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+resource+output: 'Render a project's current model server-side and return it as an inline image.' Explicitly contrasts with open_in_studio and describes its niche (different view, contact sheet, slug-only). Easily distinguished from 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?

Explicitly says 'Prefer open_in_studio for the happy path' and gives conditions for this tool ('Use this tool for a different view... or when you only have a slug and are not publishing'). Also instructs to push with open_in_studio first after model changes.

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

All kernelcad tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.