Renders PNG previews and exports STL geometry from OpenSCAD source code, enabling iterative CAD modeling and design validation.
Click on "Install 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"]
}
}
}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
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 provided, the description must disclose behavioral traits, but it only mentions the return format as an 'embedded resource blob'. It does not discuss prerequisites (e.g., OpenSCAD installed), error cases, or any side effects, leaving significant behavioral ambiguity for a tool with no annotation support.
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?
The description is a single, front-loaded sentence that directly states the tool's function and return format. Every word is purposeful and there is no redundant information or filler.
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?
For a simple two-parameter tool with a complete schema and output schema available, the description covers the core functionality and return format. It might benefit from a note about the filename being optional or the rendering process, but these are not essential given the schema and output schema richness, making the description reasonably 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?
The input schema has 100% coverage with descriptions for both parameters, so the baseline is 3. The description adds minimal semantic value beyond the schema; it implies scadCode usage by mentioning 'OpenSCAD (SCAD) source code' but does not clarify filename defaults or behavior, which the schema already documents.
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 uses a specific verb 'Export' and identifies both the input (OpenSCAD source) and output (STL), clearly distinguishing this from the sibling tool render_scad_png which produces PNG images. The intent is unambiguous.
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 description implies usage when an STL file is needed from OpenSCAD code, but it does not explicitly mention the sibling tool or provide when-not-to-use guidance. It gives a clear context but lacks exclusions or alternative tool references, putting it at the implied usage level.
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?
No annotations are provided, so the description must carry the behavioral burden. It discloses that the tool renders to PNG and supports camera control, but does not mention error handling, execution characteristics, or the relationship between cameraPreset and cameraPosition when both are provided. It adds some value over the schema but leaves gaps.
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?
The description is two sentences, with the main purpose front-loaded in the first sentence and parameter usage summarized efficiently in the second. No unnecessary words or repetition of schema details.
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?
With 5 parameters including an enum and nested object, the description covers all key inputs (scadCode, width/height, camera options) and states the output as PNG. Since an output schema exists, return values are documented elsewhere. It could mention what happens on invalid code or if both camera options are provided, but overall it is complete enough for a simple render tool.
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 all parameters. The description restates the parameters in prose but does not add new semantic details beyond what the schema provides, such as default values or the precedence rule between cameraPreset and cameraPosition (which is partially in the schema).
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 clearly states the tool renders OpenSCAD source code into a PNG preview image, using a specific verb ('render') and resource ('SCAD source code'), and distinguishes from the sibling tool by mentioning PNG output (vs STL). This makes the purpose unambiguous.
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 description explains how to use the tool (provide scadCode, set optional width/height/camera options) but does not explicitly state when to choose this over export_scad_stl or mention any exclusions. The usage context is implied by the word 'preview' but not made explicit.
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. Dates show when Glama detected each change.
v0.0.0export_scad_stlrender_scad_pngEach tool produces a distinct output format: PNG preview versus STL export. No overlap in purpose, and both descriptions clearly specify their output.
Both tools follow a consistent verb_noun pattern: render_scad_png and export_scad_stl. The naming clearly indicates the action and target format.
At 2 tools, the server is minimal but covers basic rendering/exporting needs. It is slightly thin but not unreasonable for a narrowly scoped utility.
The server provides a render and an export operation, but lacks common auxiliary functionality such as error checking, previewing in 3D, or accessing model metadata. The core workflow of generating a preview and exporting an STL is covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent-first CAD: editable .kcad.ts source, deterministic review, OpenCASCADE kernel.
Cloud Blender for AI agents: scenes, assets, renders, MP4, STL, GLB — over hosted remote MCP.
Deterministic image rendering for agents: JSON template in, on-brand PNG out.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/fboldo/openscad-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
