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 with a sphere next to it and save as /tmp/shapes.png"
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 that provides OpenSCAD rendering capabilities. This server allows you to render OpenSCAD code to PNG images through a standardized MCP interface.
Headless OpenSCAD Rendering: Execute OpenSCAD code and generate PNG images without a GUI
Flexible Camera Control: Support for custom camera positioning and orientation
Cross-Platform: Configurable OpenSCAD binary path for different operating systems
Related MCP server: OpenSCAD MCP Server
Node.js: Version 18 or higher
OpenSCAD: Nightly (dev) version must be installed on your system. Download and install from OpenSCAD.org.
Clone this repository:
git clone https://github.com/rahulgarg123/openscad-mcp.git
cd openscad-mcpInstall dependencies:
npm installBuild the project:
npm run buildBy default, the server looks for OpenSCAD at /Applications/OpenSCAD.app/Contents/MacOS/OpenSCAD (macOS path). You can customize this by setting the OPENSCAD_BINARY environment variable.
In your gemini settings.json file, e.g., ~/.gemini/settings.json, add the following:
"mcpServers": {
"openscad": {
"command": "node",
"args": ["/path/to/openscad-mcp/dist/index.js"],
"env": {
"OPENSCAD_BINARY": "/path/to/OpenSCAD/binary"
}
}
}Use included GEMINI.md file in the folder you want to generate openSCAD code in.
render_openscadRenders OpenSCAD code to a PNG image file.
Parameters:
code (string, required): The OpenSCAD code to render
output_path (string, required): Path where the rendered PNG image should be saved
camera (string, optional): Camera parameters in one of these formats:
translate_x,y,z,rot_x,y,z,dist - Translation, rotation, and distance
eye_x,y,z,center_x,y,z - Eye position and center point
Example Request:
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "render_openscad",
"arguments": {
"code": "cube([20, 30, 10]); translate([25, 0, 0]) sphere(r=8);",
"output_path": "/tmp/my_render.png",
"camera": "0,0,0,60,0,315,100"
}
}
}Response:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [
{
"type": "text",
"text": "OpenSCAD rendering completed successfully\n\nOutput:\n...\n\nRendered image saved to: /tmp/my_render.png"
}
]
}
}Prompt:
Generate openscad code for a very beautiful and unique planter. Iterate as many times as possible on the design, looking at the rendering in each iteration and improving it. The goal is to generate a unique and aesthetic planter design amenable for 3D printing.
|
First Iteration |
|
Final Iteration |
Generated OpenSCAD code:
module unique_planter(
height = 100,
width = 50,
wall_thickness = 4,
twist = 90,
freq = 8,
amp = 2,
drainage_hole_rad = 5
) {
$fn=100;
difference() {
linear_extrude(height = height, scale = 1.2, twist = twist, slices = 200) {
polygon([
for (a = [0:360/$fn:359])
let (r = width/2 + amp*sin(a*freq) + amp*sin(a*freq/2))
[r*cos(a), r*sin(a)]
]);
}
translate([0,0,wall_thickness]) {
linear_extrude(height = height, scale = 1.2, twist = twist, slices = 200) {
polygon([
for (a = [0:360/$fn:359])
let (r = width/2 - wall_thickness + amp*sin(a*freq) + amp*sin(a*freq/2))
[r*cos(a), r*sin(a)]
]);
}
}
translate([0,0,-1]) {
cylinder(h = wall_thickness+2, r = drainage_hole_rad);
}
}
}
unique_planter();Run the included tests to verify everything works:
node test_client.jsnpm run build: Compile TypeScript to JavaScript
npm run start: Start the MCP server
npm run dev: Watch mode for development
openscad-mcp/
├── src/
│ └── index.ts # Main MCP server implementation
├── dist/ # Compiled JavaScript output
├── test_client.js # Basic test client
├── test.scad # Sample OpenSCAD file
├── package.json # Node.js dependencies and scripts
├── tsconfig.json # TypeScript configuration
└── README.md # This fileError: spawn /Applications/OpenSCAD.app/Contents/MacOS/OpenSCAD ENOENTSolution: Verify OpenSCAD is installed and set the correct OPENSCAD_BINARY path.
Error: EACCES: permission denied, open '/path/to/output.png'Solution: Ensure the output directory exists and is writable.
Error: Command failed: timeoutSolution: Simplify your OpenSCAD code or increase the timeout in the source code.
Fork the repository
Create a feature branch
Make your changes
Add tests for new functionality
Submit a pull request
Render OpenSCAD code to PNG using OpenSCAD in headless mode
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The OpenSCAD code to render | |
| output_path | Yes | Path where the rendered PNG image should be saved | |
| camera | No | Camera parameters: translate_x,y,z,rot_x,y,z,dist or eye_x,y,z,center_x,y,z |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'headless mode', which implies no GUI, but doesn't cover critical aspects like performance (e.g., rendering time, resource usage), error handling, file system interactions, or dependencies. For a tool that generates files and executes code, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and includes relevant technical details (headless mode). Every part of the sentence contributes meaning, making it highly concise and well-structured.
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 the complexity of rendering code to an image file, the lack of annotations, and no output schema, the description is incomplete. It doesn't explain what happens on success (e.g., file creation details) or failure, nor does it cover behavioral traits like side effects or limitations. For a tool with 3 parameters and no structured safety hints, more context is needed.
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 three parameters (code, output_path, camera) with clear descriptions. The description adds no additional parameter semantics beyond what's in the schema, such as format details or examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb ('Render') and resource ('OpenSCAD code to PNG'), specifying the action and output format. It also mentions the execution mode ('using OpenSCAD in headless mode'), which adds useful context. However, with no sibling tools, it doesn't need to differentiate from alternatives, so it doesn't reach the highest score.
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 provides no guidance on when to use this tool versus alternatives, prerequisites, or constraints. It lacks any context about typical use cases, limitations, or comparisons to other rendering methods. This leaves the agent with minimal usage direction beyond the basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'render_openscad' has a clear and distinct purpose, making it impossible for an agent to misselect between tools.
A single tool inherently has perfect naming consistency, as there are no other tools to compare it against. The tool name 'render_openscad' follows a clear verb_noun pattern, but consistency cannot be assessed across multiple tools in this case.
A single tool is generally too few for most server purposes, as it limits functionality and may indicate an incomplete or overly narrow scope. While it might be appropriate for a very specific task, it feels thin and could hinder agent workflows that require more operations.
The server appears to target OpenSCAD rendering, but with only a render tool, there are significant gaps. For example, there are no tools for creating, editing, or managing OpenSCAD code, which are core operations in this domain. This severely limits the surface and will likely cause agent failures.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Cloud Blender for AI agents: scenes, assets, renders, MP4, STL, GLB — over hosted remote MCP.
Agent-first CAD: editable .kcad.ts source, deterministic review, OpenCASCADE kernel.
Deterministic image rendering for agents: JSON template in, on-brand PNG out.
DXF and PDF/X-4 for AI agents: structured facts, PNG renders, an interactive in-chat viewer.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rahulgarg123/openscad-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
