Allows creating and manipulating 3D CAD models using OpenSCAD, with capabilities to render to 3D mesh formats, generate 2D previews, validate syntax, and get OpenSCAD installation info.
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 Create a 20mm cube and export as STL"
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.
A Model Context Protocol (MCP) server for OpenSCAD - enables AI assistants to create and manipulate 3D CAD models.
Render: Compile OpenSCAD code to 3D mesh formats (STL, OFF, AMF, 3MF, CSG)
Preview: Generate 2D previews (PNG, SVG, DXF, PDF) with camera controls
Validate: Check OpenSCAD syntax without generating output
Info: Get OpenSCAD installation information
Related MCP server: 3D MCP Server
Node.js 18 or higher
OpenSCAD installed on your system
npm install -g openscad-mcp# Clone the repository
git clone https://github.com/dkpoulsen/openscad-mcp.git
cd openscad-mcp
# Install dependencies and build
npm install
npm run buildAdd to your Claude Desktop configuration:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"openscad": {
"command": "npx",
"args": ["-y", "openscad-mcp"]
}
}
}{
"mcpServers": {
"openscad": {
"command": "node",
"args": ["/path/to/openscad-mcp/dist/index.js"]
}
}
}Compile OpenSCAD code to a 3D mesh format.
Parameters:
scad (string, required): OpenSCAD code to compile
format (string, default: "stl"): Output format - stl, off, amf, 3mf, or csg
parameters (object, optional): Variables to pass via -D flags
exportFormat (string, optional): For STL - asciistl or binstl
hardwarnings (boolean, default: true): Treat warnings as errors
Generate a 2D preview or vector export.
Parameters:
scad (string, required): OpenSCAD code to preview
format (string, default: "png"): Output format - png, svg, dxf, or pdf
width (number, default: 800): Image width in pixels
height (number, default: 600): Image height in pixels
camera (string, optional): Camera position
colorscheme (string, default: "Cornfield"): Color scheme
projection (string, default: "perspective"): ortho or perspective
autocenter (boolean, default: true): Center the design
viewall (boolean, default: true): Fit entire design in view
render (boolean, default: false): Use full CGAL render
Validate OpenSCAD syntax.
Parameters:
scad (string, required): OpenSCAD code to validate
parameters (object, optional): Variables to define
Get OpenSCAD installation information.
User: Create a simple 10x10x10 cube in OpenSCAD and render it to STL
AI: I'll create a cube and render it for you.
[Uses render tool with:]
scad: cube([10, 10, 10]);
format: stlAvailable color schemes for PNG export:
Cornfield (default)
Metallic
Sunset
Starnight
BeforeDawn
Nature
Daylight Gem
Nocturnal Gem
DeepOcean
Solarized
Tomorrow
Tomorrow Night
ClearSky
Monotone
MIT
Get information about the OpenSCAD installation (version, features, library versions).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral disclosure. 'Get information' clearly signals a read-only, non-mutating operation, but the description does not explicitly state that it makes no changes or describe any potential environment interaction beyond reading version and library data.
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 immediately states the action and resource, then lists the specific information categories. Every word contributes value, with no filler or repetition.
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 zero-parameter introspection tool with no output schema, this description is complete. It tells the agent exactly what kind of information will be returned—version, features, library versions—and no additional context is necessary to call it correctly.
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 tool has zero parameters, and the input schema already fully reflects that with complete coverage. There is nothing for the description to add about parameter meaning or formatting, so the zero-parameter baseline of 4 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 states a clear verb-resource pair: 'Get information about the OpenSCAD installation' and specifies what that includes: 'version, features, library versions'. This naturally distinguishes it from sibling tools like render, preview, and validate, which are clearly operation-oriented.
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 tool's purpose strongly implies when to use it—when an agent needs environment or installation details—but it gives no explicit guidance about when not to use it or alternatives. No alternatives are named, so the usage context is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a 2D preview of OpenSCAD code. Export as PNG image or vector formats (SVG, DXF, PDF). Use camera settings to control the view.
| Name | Required | Description | Default |
|---|---|---|---|
| scad | Yes | OpenSCAD code to preview | |
| width | No | Image width in pixels (for PNG) | |
| camera | No | Camera position: "tx,ty,tz,rx,ry,rz,dist" (gimbal) or "ex,ey,ez,cx,cy,cz" (look-at) | |
| format | No | Output format: png (image), svg/dxf/pdf (2D vector) | png |
| height | No | Image height in pixels (for PNG) | |
| render | No | Use full CGAL render instead of preview (slower but more accurate) | |
| viewall | No | Adjust camera to fit entire design | |
| autocenter | No | Center the design in the view | |
| parameters | No | Variables to pass to OpenSCAD | |
| projection | No | Projection type | perspective |
| colorscheme | No | Color scheme for rendering | Cornfield |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden, and it does convey the core behavior (generating a 2D preview and exporting to image/vector formats). It does not disclose performance characteristics, side effects, or the meaning of the full-render option, which would give an agent a more complete safety and cost model.
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 tight sentences with no filler: it states the action, the supported export formats, and the camera-control affordance. Every sentence earns its place, and the main purpose is front-loaded.
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 an 11-parameter tool with no output schema and no annotations, this description is too thin. It omits how the generated file is returned, the distinction from the render sibling, and any caveats (e.g., vector export implications), leaving the agent to rely entirely on the schema for operational context.
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 parameter documentation already carries the load; the description's 'Use camera settings to control the view' loosely reinforces the camera parameter but adds no syntax or format detail beyond the schema. It also doesn't clarify interactions (e.g., width/height only for PNG), though that is already partly implied by 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?
Description clearly states a specific action—'Generate a 2D preview of OpenSCAD code'—and the resource being acted on, so the tool's purpose is immediately understandable. It also lists output formats, strengthening clarity. However, it does not explicitly differentiate this from the sibling 'render' tool, since both could plausibly produce an image from OpenSCAD code.
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 guidance on when to choose preview over render or how it relates to validate/info. The description says what the tool does but never states a use case, prerequisites, or exclusions, so an agent must infer when it is the appropriate sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compile OpenSCAD code to a 3D mesh format (STL, OFF, AMF, 3MF, or CSG). Use this to generate 3D-printable files.
| Name | Required | Description | Default |
|---|---|---|---|
| scad | Yes | OpenSCAD code to compile | |
| format | No | Output format for the 3D mesh | stl |
| parameters | No | Variables to pass to OpenSCAD via -D flags (e.g., {width: 10, name: "test"}) | |
| exportFormat | No | For STL: "asciistl" for ASCII format, "binstl" for binary (smaller file) | |
| hardwarnings | No | Treat warnings as errors |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the core transformation (compiling OpenSCAD to mesh formats) and the intent to produce printable files. However, it does not explain error behavior, how the result is delivered (file path, binary, URL), or other operational characteristics, leaving notable 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, front-loaded with the main action, formats, and use case. Every sentence earns its place, and there is no repetition 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?
Given 5 parameters, a nested object, and no output schema, the description omits essential operational context: what the tool returns, whether compilation can fail and how errors are reported, and how the generated file is exposed to the agent. It provides the 'what' but not the 'what happens next', making the definition incomplete for safe invocation.
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 documents all parameters. The description's format list overlaps with the format enum and adds no new parameter semantics. Baseline 3 is appropriate because the description does not need to compensate for schema gaps.
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 states a specific verb ('Compile'), a specific resource ('OpenSCAD code'), and the outcome ('3D mesh format' with named formats). It clearly identifies the tool's role relative to siblings like preview or validate, but it does not explicitly name or contrast them, so it misses the full differentiation of a 5.
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?
'Use this to generate 3D-printable files' gives clear, direct guidance on when to invoke this tool. It does not mention alternatives or exclusions, so it lacks the explicit when-not-to-use guidance needed for a 5, but it is more than an implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate OpenSCAD code syntax without generating output. Returns errors and warnings if any.
| Name | Required | Description | Default |
|---|---|---|---|
| scad | Yes | OpenSCAD code to validate | |
| parameters | No | Variables to define during validation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses two key behavioral traits: the tool does not generate output, and it returns errors and warnings. These are central for safe invocation, though it does not explicitly discuss side effects or permissions.
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 short sentences with no redundant wording. The core purpose and key constraint (no output) are front-loaded, and the return behavior is stated in the second sentence.
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 validation tool with full schema coverage, the description adequately conveys purpose, return behavior, and the no-output constraint. It is complete enough for an agent to call correctly, though it could optionally note that the returned errors/warnings are syntax-related.
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 (scad and parameters) are already documented. The description adds no extra parameter-level meaning, but with full schema coverage 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 uses a specific verb ('Validate') with a clear resource ('OpenSCAD code syntax') and immediately distinguishes itself from rendering/previewing tools by stating 'without generating output'. This makes the tool's purpose unmistakable and differentiates it from siblings like render and preview.
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 clearly conveys when to use this tool: when you need to check OpenSCAD syntax without producing output. It does not explicitly name sibling tools or provide exclusion criteria, but the behavioral distinction from rendering/prevving is strong enough context for an agent.
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.
v1.0.0infopreviewrendervalidateEach tool targets a distinct concern: render produces 3D meshes, preview produces 2D images/vectors, validate checks syntax, and info reports environment details. There is no meaningful overlap or ambiguity between tool purposes.
All tool names are single lowercase verbs in a consistent imperative style: render, preview, validate, info. The pattern is uniform and easy to predict.
Four tools is a well-scoped size for a specialized OpenSCAD server. Each tool serves a clear, necessary function without redundancy or bloat.
The tool surface covers the core OpenSCAD workflow: validate code, preview it in 2D, render it to 3D formats, and check the installation. There are no obvious dead ends or missing lifecycle operations for this domain.
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.
Give any MCP-compatible AI assistant a builder for live, hosted web tools and workflows.
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/dkpoulsen/openscad-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
