Skip to main content
Glama
pzfreo

build123d-mcp

by pzfreo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

render_view

Read-only

Render a build123d model to PNG, SVG, or DXF to visually verify appearance. Auto-detects 2D vs 3D and supports directions, quality, clipping, and labels.

Instructions

Render model. Auto-detects 3D vs 2D: solids use VTK; flat drawings use the 2D pipeline. Renders confirm appearance, not geometry. format: png, svg, dxf, or both. direction accepts top, bottom, front, rear, side, left, right, or iso. quality: preview, standard, or high; a timed-out standard/high PNG automatically retries once as a coarse preview. azimuth/elevation apply after the preset. objects selects comma-separated registered names. clip_plane: x/y/z. save_to writes the result. mode: auto/2d/3d. label_objects and highlights add PNG labels; colors controls object/layer colours.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoauto
colorsNo
formatNopng
azimuthNo
clip_atNo
objectsNo
qualityNostandard
save_toNo
directionNoiso
elevationNo
clip_planeNo
highlightsNo
label_objectsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.19
  2. Removedv0.3.17
  3. Changed2 schema fields changedv0.3.16
    • addedInput schema / properties / highlights
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Highlights"
+}
    • addedInput schema / properties / label_objects
      Added value: +{
+  "default": false,
+  "title": "Label Objects",
+  "type": "boolean"
+}
  4. First observedv0.3.10

TDQS

A3.8/5.0
Behavior4/5

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

Beyond the readOnlyHint annotation, the description discloses meaningful behavior: 3D/2D auto-detection via VTK vs 2D pipeline, timeout retry that downgrades to a coarse preview, azimuth/elevation applying after the preset, and PNG-only label/highlight behavior. These add real value that annotations do not convey.

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?

Dense but efficient: the purpose is front-loaded and every clause adds operative detail about a parameter or behavior. It is a long single paragraph rather than structured bullets, but there is minimal waste given the high parameter count it must document.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter tool with no enums, no output schema, and zero schema coverage, the description documents nearly every parameter with accepted values and discloses key behaviors (retry, auto-detection, PNG-only labels). The only gaps are clip_at semantics and explicit return-value description, which 'save_to writes the result' partially covers.

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?

With 0% schema coverage, the description carries the full burden and compensates strongly: it documents allowed values for format (png, svg, dxf, or both), direction (top, bottom, front, rear, side, left, right, or iso), quality (preview/standard/high with retry), mode (auto/2d/3d), clip_plane (x/y/z), and object selection. However, clip_at is never mentioned, leaving one parameter undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Render model'), and clarifies the purpose is to 'confirm appearance, not geometry', which distinguishes it from measurement or analysis tools. However, it does not explicitly differentiate from sibling render_drawing, so differentiation is implied rather than named.

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

Usage Guidelines3/5

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

The phrase 'Renders confirm appearance, not geometry' implies the intended use case (visual appearance verification rather than dimensional checking), and the auto-detect behavior hints at when it applies. But there is no explicit when-to-use/when-not-to-use guidance or naming of alternatives like export or render_drawing.

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

Deploy Server

Other Tools