The server renders OpenSCAD (SCAD) source code into PNG preview images and exports STL geometry artifacts for agent-driven CAD workflows.
Render scadCode to a PNG image with render_scad_png, optionally setting width and height (defaults: 800×600).
Control the PNG camera with a named preset (isometric, front, back, left, right, top, bottom) or an explicit {x, y, z} position.
Export scadCode to an STL embedded resource with export_scad_stl, optionally naming the output file via filename.
Support iterative modeling loops: generate/modify SCAD, render PNG previews, critique, and refine across turns.
Produce geometry artifacts for downstream tools, fabrication, simulation, storage, or inspection.
Compare parametric variants or parameter sweeps visually before deciding what to persist or export.
Run over stdio (npx openscad-mcp-server) or HTTP (--http), with GET /health and POST /mcp endpoints.
Use the included OpenSCAD iterative modeling skill to give agents SCAD-to-PNG-to-refinement expertise.
Renders PNG previews and exports STL geometry from OpenSCAD source code, enabling iterative CAD modeling and design validation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@openscad-mcp-server render a cube and sphere union preview"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that renders PNG previews and STL geometry from OpenSCAD (SCAD) source code. It is designed to support iterative, agent-driven CAD workflows, where models can be previewed visually and exported for downstream use (e.g. fabrication, simulation, or inspection).
⚠️ Beta
This MCP server is currently in beta. Performance, APIs, and capabilities may change. Issues and contributions are welcome.
Iterative agent-driven modeling
Agents generate or modify OpenSCAD source, render PNG previews to evaluate shape and proportions, and refine the model across multiple turns.
Geometry artifact generation within MCP contexts
Agents export STL files as concrete geometry artifacts that can be passed to downstream tools, stored, inspected, or handed off to other MCP-enabled systems.
Visual grounding for parametric design
PNG previews provide visual grounding for parametric or programmatic SCAD code, reducing hallucination and enabling agents to reason about spatial changes.
Design validation and comparison
Agents can render multiple variants of a model (e.g. parameter sweeps) and visually compare results before deciding which geometry to persist or export.
Related MCP server: OpenSCAD MCP Server
render_scad_png: Renders a PNG preview image from SCAD source.
Input: scadCode (string), optional width/height (numbers), optional cameraPreset and optional cameraPosition
cameraPreset: one of isometric, front, back, left, right, top, bottom
cameraPosition: { x, y, z }
Output: MCP ImageContent
export_scad_stl: Exports an STL generated from SCAD source.
Input: scadCode (string), optional filename (string)
Output: MCP embedded resource (STL)
This repository also includes an OpenSCAD iterative modeling skill that demonstrates how to use this MCP server to support an iterative SCAD → PNG → critique → refine loop.
Performance: Rendering complex SCAD models can be slow, especially in a WASM environment.
Feature support: Not all OpenSCAD features may be fully supported or may have limitations in the WASM version.
Fonts: Text rendering is not currently supported. Support is planned for a future release.
The published package is intended to run over stdio. Configure it in your MCP client using npx:
{
"mcpServers": {
"openscad": {
"command": "npx",
"args": ["-y", "openscad-mcp-server"]
}
}
}To run it over HTTP instead (e.g. in Docker), pass --http:
MCP_PORT=3000 npx -y openscad-mcp-server --httpThe server exposes GET /health and a stateless streamable HTTP MCP endpoint at POST /mcp.
Agents skills are a simple, open format for giving agents new capabilities and expertise.
The most straightforward to use the OpenSCAD iterative modeling skill is to install it using the skills CLI:
npx skills add fboldo/openscad-mcp-server --skill openscad-iterative-modelingInstall deps: bun install
Stdio (matches how clients run it): bun index.ts --stdio
HTTP (useful for manual testing): bun index.ts (or --http)
Port: MCP_PORT (default 3000)
Endpoints: GET /health, MCP at POST /mcp
MCP Inspector: bun run dev
jhacksman/OpenSCAD-MCP-Server This project provides a different approach relying on generating images from user prompts, followed by 3D reconstruction and even 3D printer discovery. It's a very interesting project, and I recommend checking it out if you are interested in OpenSCAD and MCP servers.
petrijr/openscad-mcp Similar to this project, but it uses a Python-based server and relies on the OpenSCAD CLI for rendering.
MIT — see LICENSE.
Export OpenSCAD (SCAD) source code into an STL and return it as an embedded resource blob.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | The name of the output STL file | |
| scadCode | Yes | The OpenSCAD code to render |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| _meta | No | |
| resource | Yes | |
| annotations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the return transport ('embedded resource blob'), but says nothing about render failure modes for invalid SCAD, expected runtime/cost, or how the resource is referenced. That leaves significant gaps for a rendering tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that states the transform, the target format, and the return mechanism with zero filler. Nothing is padded or repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the tool is simple with only two params. However, the description omits any failure behavior and any routing guidance relative to render_scad_png, leaving it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (scadCode, filename) are already documented in the schema. The description adds no additional parameter meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource: exporting SCAD source into an STL, plus the key detail that it returns an embedded resource blob. It is clearly distinct from the sibling render_scad_png in what it produces, but it never names the sibling, so the differentiation relies on the agent inferring STL-vs-PNG.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no mention of the sibling render_scad_png. An agent must infer from 'STL' that this is for 3D mesh output rather than a raster image, so the usage boundary between the two tools is left unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render OpenSCAD (SCAD) source code into a PNG preview image. Provide the SCAD text in scadCode and optionally set width/height (pixels). Optional camera control is available via cameraPreset (named preset) or cameraPosition ({x,y,z}).
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | The width of the output image in pixels (default: 800) | |
| height | No | The height of the output image in pixels (default: 600) | |
| scadCode | Yes | The OpenSCAD code to render | |
| cameraPreset | No | A named camera preset used when `cameraPosition` is not provided | |
| cameraPosition | No | Camera position as { x,y,z }. Example: { x: 0, y: -25, z: 20 } |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| type | Yes | |
| _meta | No | |
| mimeType | Yes | |
| annotations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the required input and the preview nature of the output, but says nothing about rendering time, failure behavior on invalid SCAD, default camera semantics, or resource limits. This is adequate but leaves meaningful gaps for a compute-heavy render tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the purpose front-loaded and the inputs enumerated immediately after. No filler or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and all five parameters are covered with the required scadCode highlighted. The one gap is error/edge-case behavior, which the description omits entirely despite no annotations covering it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter, including the cameraPreset-vs-cameraPosition precedence. The description restates parameters but adds no syntax or constraint detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Render OpenSCAD (SCAD) source code into a PNG preview image'), which is unambiguous about what the tool produces. It does not name the sibling export_scad_stl, but the PNG-vs-STL distinction is implicit in the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'preview' hints that this is for quick visual output rather than an export artifact, which suggests why one would pick it over export_scad_stl. However, there is no explicit when-to-use guidance, no exclusion of cases better served by the STL export sibling, and no prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.6export_scad_stl1 field changedOutput schema / properties / annotations / properties / lastModified / patternPrevious value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"render_scad_png1 field changedOutput schema / properties / annotations / properties / lastModified / patternPrevious value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"v0.0.0export_scad_stlrender_scad_pngScored across 2 tools
The two tools target clearly different outputs: render_scad_png produces a raster preview image, while export_scad_stl produces a mesh file blob. An agent can trivially tell which to call based on whether it wants a preview or a downloadable geometry file.
Both names follow a strict verb_noun_object pattern (render_scad_png, export_scad_stl), using snake_case with the source format and target artifact made explicit. The convention is predictable and self-documenting.
At two tools the surface is on the thin side, though the server's scope (turning SCAD source into viewable/exportable artifacts) is narrow enough that this is defensible. Each tool clearly earns its place, but there's little room for variation in workflow.
The core lifecycle—preview and export—is fully covered, and the render tool even exposes camera controls. Minor gaps remain: no alternative export formats (3MF, SVG, DXF, OFF) and no way to validate or inspect SCAD code without producing an artifact.
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
Agent-first CAD: editable .kcad.ts source, deterministic review, OpenCASCADE kernel.
Deterministic image rendering for agents: JSON template in, on-brand PNG out.
Cloud Blender for AI agents: build, inspect, render and animate 3D scenes over remote MCP. Keep editable .blend files and export GLB or STL. Make your first 3D asset free: 30 compute minutes/month, no credit card.
