Skip to main content
Glama

kernelcad

by com.kernelcad
OverviewDiscussionsAdmin

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. error "mesh_timeout" means the model took too long to build for a preview; the source is not wrong (it still exports) — do not rewrite it to fix the render.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesProject 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.
viewNoView 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_onlyNoControls 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
NameRequiredDescriptionDefault
okNoWhether a render was produced.
hintNoNext-action hint when ok is false.
viewNoThe view that was rendered (when ok).
bytesNoPNG byte length (when ok).
errorNoError code when ok is false (e.g. "empty_geometry", "mesh_failed", "mesh_timeout").
widthNoRendered image edge in px (when ok).
heightNoRendered image edge in px (when ok).
image_b64NoBase64-encoded PNG bytes, present when inlined (paths_only=false) and under the size cap.
truncatedNoSet when inline was requested but the PNG exceeded the size cap.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / error / description
      Previous value: -"Error code when ok is false (e.g. \"empty_geometry\", \"mesh_failed\")."New value: +"Error code when ok is false (e.g. \"empty_geometry\", \"mesh_failed\", \"mesh_timeout\")."
  2. Changed12 schema fields changed
    • 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"
+}
  3. Changed1 schema field changed
    • 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"
+}
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly/destructive/openWorld; the description adds substantial context beyond them — determinism of output bytes, that the image reflects the server model and NOT the user's Studio camera, auth rules by visibility, the mesh_timeout error semantics, and the never-blank guarantee. This is exactly the behavioral disclosure the structured fields cannot carry.

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

Conciseness4/5

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

Purpose is front-loaded in the first sentence and the structure moves from purpose to routing to gotchas. It is quite long, and the determinism/camera points are reiterated, but nearly every sentence defends against a distinct real failure mode rather than padding.

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?

Even with an output schema present, it covers the operational facts an agent needs: default view behavior, auth-by-visibility, error shapes, and the push-then-render workflow. Nothing required to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely extends the schema: it details the default contact-sheet behavior including the 3x2 grid layout and row ordering, which the enum description only summarizes, and clarifies the paths_only delivery tradeoff. This adds meaning beyond the parameter descriptions.

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?

The first sentence states a specific verb+resource+outcome: 'Render a project's current model server-side and return it as an inline image.' It also explicitly distinguishes itself from open_in_studio and implicitly from render_preview by naming the conditions under which this tool, not those siblings, is correct.

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?

Explicit when-to-use is given: prefer open_in_studio for the happy path, use this for a different view, a contact sheet, or when you only have a slug and are not publishing. The when-not and the alternative are both named, leaving nothing to inference.

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

All kernelcad toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources