Skip to main content
Glama

Render a part to images

render_part
DestructiveIdempotent

Render STL parts and optimization regions to PNG views for visual inspection before and after runs, including load arrows, without a display or GL.

Instructions

Render a part to PNG images so you can look at it. No display or GL is needed (CONTRACTS.md section 15).

A look before the first run and after each run finds a wrong region or load fast.

Input: stl_paths (STL files; roles: one role for all or one per file, from part, design, fixed, load, keep-out; default part; an item may be a comma list), or run_dir (renders result/final.stl and the region STLs that run.json names; missing region files are listed in the facts), or yaml_path (a problem YAML, before a run: the region STLs and the interface shapes. Fixed, load and union shapes are solid. The design space, keep-out regions and cut shapes are ghosts. A face is its cut zone, clipped to the grid box. Look at it before a run: it shows what a cut takes). With none of them, the last run is used. A YAML render also draws the force arrows (one for each force of each load case, a color for each case, along the force, ending where it acts): you can show it to the user to check the directions before the run. The answer is a JSON text and, when inline is true, the montage as one image. With inline false the answer is the text only; the PNG files are on disk and a client that can open files reads them. A 4-view render of an 85,000-triangle part takes about 2 to 4 s; the first call with an empty numba cache adds under 1 s. Later renders overwrite PNGs with the same names; out_dir picks another folder. out_dir: default /renders, or renders beside the first STL. max_triangles: refuse meshes with more triangles than this (default: no limit; the facts give a memory estimate, about 450 MB plus 450 MB per million triangles). Reply keys: resource topopt://replies/render_part (the meaning of each key). The facts of each mesh have watertight and winding_consistent. loads: false draws no force arrow in a YAML render (default: arrows). A moment and a pressure get no arrow, and the facts say so. The arrow length is a share of the part size: it does not show the force size. views: names from iso, front, back, right, left, top, bottom (default iso, front, right, top); NAME:dx,dy,dz gives your own direction from the part to the camera, z up (name: letters, digits, _, -). section: "x=30" (or "x>=30") keeps x >= 30; "x<=30" keeps x <= 30; the axis is x, y or z, in mm. regions: how the non-part meshes are drawn. ghost (default with a part): design and keep-out as faint ghosts, fixed and load as strong ghosts, so the part stays visible. solid (default without a part). off: the part only. size: one tile in pixels, WxH (default 640x480). The montage is at most 1568 px on the long edge. All tiles have one scale; a scale bar shows it. In views, one item may be "fl:-0.5,-1,0.25". A text like "iso,fl:-0.5,-1,0.25,top" in one item is read as three views. Cut faces are flat orange. With a section and no views, the views are: cut (straight at the cut face from the removed side), iso-cut, and two side views of the kept part. The facts give cut_face_visible_px for each view; they say if a mesh could not be cut (for example, it is not a closed solid), and the render is made anyway.

Colors: part grey-blue, design space light blue, fixed dark blue, load red, keep-out brown, cut face orange; for a YAML also union shape green and cut shape (a ghost) pink-red. Back faces are magenta: they show a flipped or open surface. The same input gives the same PNG bytes.

Input Schema

NameRequiredDescriptionDefault
sizeNo
loadsNo
rolesNo
viewsNo
inlineNo
out_dirNo
regionsNo
run_dirNo
sectionNo
stl_pathsNo
yaml_pathNo
max_trianglesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare destructive, idempotent, and non-read-only behavior, and the description explains why: later renders overwrite PNGs with the same names, out_dir redirects output, and same input yields same PNG bytes. It also adds timing, memory estimates, inline-vs-disk output behavior, and facts about mesh validity, going well beyond the annotations.

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?

The description is long but dense and front-loads purpose and usage before parameter details. Some sentences pack multiple concepts, such as view syntax and section-cut behavior, which slightly hurts readability, but the length is justified by 12 undocumented parameters and complex output behavior.

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?

Covers input modes, parameter formats, defaults, return shape, PNG overwrite behavior, view and section semantics, color conventions, performance limits, and mesh failure facts. With no output schema and zero schema descriptions, this is complete enough for an agent to call 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 description coverage is 0%, but the description explains all 12 parameters in prose: stl_paths/run_dir/yaml_path input precedence, roles, views syntax, section syntax, regions modes, size, max_triangles, loads, inline, and out_dir defaults. This fully compensates for the missing schema 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?

States a specific verb and resource: 'Render a part to PNG images so you can look at it,' and adds that no display or GL is needed. It distinguishes the tool from run/verify siblings by framing it as visual inspection before and after a run.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit timing guidance: 'A look before the first run and after each run finds a wrong region or load fast,' and notes YAML renders can be shown to the user to check force directions before a run. It does not explicitly name sibling alternatives to use instead for numeric or status checks, so it stops short of full routing guidance.

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