A
licenseNot graded
qualityD
maintenanceOpenSCAD wrapped as an MCP server. Render .scad with parameter overrides, run parametric sweeps,
validate syntax, compute STL metrics. Curated by Archimedes Market with a verified Trust Report.
3
MIT
cadloop-openscad
Allows slicing models using Bambu Studio, including checking bed fit, slicing, and extracting G-code.
Allows slicing models using Creality Print, including checking bed fit, slicing, and extracting G-code.
Allows slicing models using ElegooSlicer, including checking bed fit, slicing, and extracting G-code.
Provides tools for writing, compiling, and verifying OpenSCAD models, including syntax checking, parameter echoing, rendering, preview, and mesh verification.
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., "@cadloop-openscadcheck syntax and preview my parametric gear model"
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.
cadloop
A closed loop from parametric source to G-code, with the verification step in the middle that neither the CAD tool nor the slicer can do.
Two MCP servers. A model writes OpenSCAD, compiles it, reads computed values back out, looks at a render, checks it fits the bed, slices it and pulls out the G-code, with every plate proven against the printable area. No GUI at any point.
The verify step in the middle is yours to write. cadloop makes everything around it cheap enough that you get to run it often; it cannot tell you whether the part works.
Every number in that walkthrough is real output. The failing wheel is a real measurement, not an illustration. How it's built and where each number comes from is in docs/walkthrough.
setup_printer once, no arguments: which printer is this for
|
write .scad
|
check syntax and references, about a second
|
echo read computed values without rendering
|
preview look at it
|
verify does it actually work <- yours; nothing here does it for you
|
measure bounding box and volume
|
check_bed_fit against the printer you set up
|
slice_model -> .gcode.3mf
|
extract_gcode -> .gcodeThe ordering is the point. check and echo skip geometry evaluation
entirely, so they cost a second against models where a full render takes
minutes. Pay for the expensive steps only once the cheap ones pass.
Everything from the bed check down is also one call, make_printable, which
renders, packs, slices and proves the result on the bed and reports what it
did in a screen of text. See the worked example.
Install
pip install cadloopThe only dependency is mcp. Or from a checkout, which is what you want if you
intend to run the worked example or the tests — the verify extra is shapely,
needed by the example's own checker rather than by cadloop:
git clone https://github.com/richardofortune/cadloop
cd cadloop
pip install -e ".[verify]"Needs OpenSCAD on PATH or at OPENSCAD_BIN, and for slicing, OrcaSlicer,
Bambu Studio, ElegooSlicer or Creality Print. They share a CLI, so any of them
works, and all four are auto-detected along with the profiles they ship.
No slicer is preferred over another here. setup_printer probes each one it
finds and then proves the winner by slicing a 20mm cube with your profiles, so
which one you get is decided by which one works on your machine rather than by
the order of a list in this repository. Creality Print's CLI is broken headless
on macOS today, and that is something this discovers rather than something it
asserts, so it corrects itself when upstream ships a fix; see testing status
below. SLICER_BIN overrides the choice.
Related MCP server: OpenSCAD MCP Server
Configure
Copy mcp.json into your client's config and fix the paths. Both servers
should point at the same workspace directory, which is the only place either
one reads or writes.
Variable | Default | Meaning |
| auto-detected | binary paths |
|
| the sandbox |
| auto-detected | extra profile roots |
|
| where the machine record lives |
| 300, 600 | seconds before a kill |
The servers
openscad exposes check, echo, render, measure, preview and
workspace file access. preview returns the PNG as an MCP image, so the model
can look at what it built rather than inferring from numbers. render returns
OpenSCAD's manifold report alongside a bounding box and volume, where
simple: yes with a sensible volume count is the signal the mesh is printable.
The two split on what happens to the picture. preview hands it back and keeps
nothing; render writes it to the workspace when the output ends in .png,
taking the same camera, imgsize, projection and full_render options. Use
render when the image is the artefact rather than the answer. Since render
also takes source as text rather than a path, the before half of a comparison
is git show <rev>:model.scad piped straight in — no checkout, no temp file.
slicer exposes setup_printer, machine_info, make_printable,
slicer_info, list_profiles, check_bed_fit, slice_model,
slice_summary and extract_gcode.
make_printable is the whole chain in one call. Give it a .scad and the
parts you want out of it, and it renders each one, measures it, packs what
fits onto as few plates as it can, slices them, and then reads the finished
G-code back to prove every extruding move lands on the bed. It never edits
the model: a part that cannot print as designed is reported, not quietly
shrunk or split. The one thing it changes is which plate a part lands on, and
turning a part ninety degrees when it will not fit square, which it names in
the report. It answers with every fact it established and, in summary, the
one screen of text those facts add up to, ending in what to do next.
Call setup_printer() once, with no arguments. It reads what your slicer is
already configured with, resolves that to a machine, process and filament
profile from one install, proves the combination by slicing a 20mm cube, and
remembers it. It reports the printer, the quality and the filament it settled
on, and stores nothing at all if the test slice fails. Pass printer,
filament or process only to override one of those fields; the rest still
come from your slicer's own settings. A profile you name is either used or
refused by name, never quietly swapped for a different one.
After that, check_bed_fit and slice_model need no profile arguments, which
is the point: a caller cannot supply three profiles that disagree if it
supplies none. Explicit arguments still win where you pass them.
machine_info says which printer this workspace is set up for and whether it
is still current. The record is a cache, not a source of truth. If the slicer
moves, a profile is edited, or the slicer's version changes, every tool that
would have used it refuses with the reason instead - ok: null, nothing
written - until you run setup_printer again. A setup that no longer matches
reality is never used to produce G-code.
Call slicer_info before doing anything unusual: the Orca-family CLI is
undocumented, changes between releases, and Creality's fork diverges, so the
flag list it reads off your install is more trustworthy than anything assumed.
slice_model has an extra_args escape hatch and a dry_run mode.
check_bed_fit is where the two meet. The slicer will emit out-of-bounds
G-code without complaining, so this measures the STL, reads printable_area
out of the machine profile, and compares. It checks the 45 degree diagonal too,
since a part that misses square-on often fits rotated.
Reading printable_area back out is fiddlier than it looks. Stock profiles
write it both as a list of "XxY" strings and as one comma-separated string,
and most Bambu machines carry no bed of their own at all, inheriting it through
inherits from a common base. So the lookup parses both forms and walks the
inheritance chain. Of the 473 concrete machine profiles shipped with Creality
Print 7.1.1, 469 resolve; the remaining four define no bed anywhere in their
chain, and those report ok: null with a reason rather than guessing.
The verification step
This is the part cadloop does not do for you, and the reason it is a worked
example rather than a feature. models/verify_spirograph.py ships beside the
model, not inside the package: every project's version of "does it actually
work" is different, and none of them generalise. Yours will look nothing like
this one.
It runs two checks. For the spirograph the first lays each wheel's pitch curve onto the ring's pitch circle, walks a full circuit, and measures overlap between the two solids at every position. Zero overlap across the whole circuit at some meshing phase is the pass condition. The second checks the parts are not laid on top of each other on the sheet.
$ python models/verify_spirograph.py
part teeth overlap mm2 result
24T 24 0.000000 pass
...
trefoil 23 0.000000 pass
14/14 parts mesh cleanly
group volume mm3
ring 23939.8
outer_ring 25652.8
wheels 197113.5
shapes 10078.7
sum 256784.8
sheet 256784.8
no parts overlap on the sheetThe second check is the same idea one level up. A sheet that lays two parts
on top of each other still renders as a clean manifold, still fits the bed,
and still slices without a word; it just prints as one fused object. So it
renders the sheet and each of its groups and compares the union against the
sum, which is the only place the collision shows up. It needs OpenSCAD and
skips without one; --skip-layout and --skip-mesh run one half alone.
What the tooth counts decide
A pen in a wheel of r teeth rolling in a ring of R traces a figure with
R / gcd(R, r) lobes, closing after r / gcd(R, r) circuits. The pattern is
settled by the tooth counts before any geometry exists, so the checker's
--patterns mode reads it straight off the set:
$ python models/verify_spirograph.py --patterns
main ring, 96 teeth
part teeth lobes circuits
32T 32 3 1 plain
24T 24 4 1 plain
72T 72 4 3 plain
...
trefoil 23 96 2396 is 2^5 x 3, so it shares factors with most of an even wheel set and a good half of these wheels draw eight lobes or fewer. There is no 48 in the set for this reason: 48 is exactly half of 96, the degenerate ratio whose pen traces an ellipse and nothing else, so it earned no slot. The outer ring, 105 = 3 x 5 x 7, behaves far better, and the trefoil at 23 teeth is coprime to both rings, which is what makes it the richest wheel in the set.
This is worth running before choosing tooth counts rather than after printing them.
This is model-specific by nature, which is the honest lesson. A manifold mesh that fits the bed and slices cleanly can still be a part that does not work. Whatever your equivalent of "does it actually roll" is, it belongs in the loop between preview and measure, and you have to write it yourself.
The worked example
models/spirograph.scad is the model the loop was built around. A 96 tooth
internal ring in a flanged body, an outer ring, eleven circular wheels and
three non-circular ones (ellipse, egg, trefoil), all involute geared at module
1.5 with pen holes on a golden-angle spiral.
The non-circular wheels are why the verifier exists. A first attempt used capsule and teardrop outlines built from tangent lines; those looked right, rendered as clean manifolds, and would have sliced without complaint, but the rolling check showed them ploughing 30 to 80 mm² into the ring teeth. A flat section of pitch curve touches the ring at one point and stands proud of it everywhere else. Nothing downstream of CAD would have caught that. The shapes that shipped are smooth convex curves whose radius of curvature stays inside the ring's everywhere.
Taking the whole set from source to plates is two calls, and the first one is only needed once:
setup_printer()
make_printable("spirograph.scad",
["ring", "outer_ring", 24, 30, 32, 36, 40, 45, 52, 56, 63, 72,
80, "ellipse", "egg", "trefoil"])On an Ender-3 V3 SE with OrcaSlicer 2.4.2 and generic PLA, that is sixteen renders, five plates, five slices and five G-code files read back and checked against the bed, in about half a minute:
ok 16 parts on 5 plates, every plate proven on the bed
machine ...... Creality Ender-3 V3 SE 0.4 nozzle, 220 x 220 mm bed, PLA
parts ........ 16 of 16 fit this bed
plates ....... 16 parts packed onto 5
sliced ....... 5 of 5, every extruding move on the bed
ready ........ ~/cad/plates/spirograph, 13h09m, 63.17 m PLA
worth a look:
plate_2 sits 2.2 mm from the bed edge, consider a brim
next: print the plates in ~/cad/plates/spirograph. Nothing above stops the
print — the notes are advisories — so read them and go.Every number there is from that run. The brim note is an advisory and not a
defect: plate 2 is on the bed with 2.2 mm to spare, which is close enough to
the edge that a warped first layer would show. Anything the run could not
prove says so in its own words — ok for what came out, FAILED for
something attempted that did not, UNKNOWN for anything it could not tell —
and the last line is always the call to make next.
make verify # rolling interference and layout, all 14 parts
make render PART=ring # one part to an .stl, no printer set up needed
make smoke # both servers, end to endmake render is the one step of the old walkthrough worth keeping by hand:
it wants nothing but OpenSCAD, so it is the quickest way to look at a single
part while you are still changing the model. Everything after it is
make_printable.
Testing status
make smoke drives both servers over real MCP stdio sessions and asserts on
forty-five behaviours: tool surface, defines reaching the script, a
deliberate syntax error being caught, measured geometry matching known
dimensions, an image coming back from preview, profile classification,
argument ordering, archive parsing, G-code extraction, bed fit passing and
failing, both printable_area spellings and an inherited bed, and the
workspace guard rejecting traversal.
It also drives the zero-argument path end to end against a slicer install
built for that run alone: setup_printer() with no arguments has to name the
printer, quality and filament it chose and store a triple from one install,
and check_bed_fit and slice_model then have to work with no profile
arguments at all. Editing a profile afterwards has to make both of them refuse
and write nothing.
make_printable is driven the same way, over the same session: a two-part
.scad has to come back as at least one plate, with every plate proven on the
bed by reading its G-code rather than by assumption, and a report of thirty
lines or fewer that names the next step. That is the only automated end-to-end
check of the one-call path.
The OpenSCAD half runs against a real OpenSCAD and skips if none is installed.
The slicer half runs against a mock binary that emits an Orca-shaped help text
and a representative .gcode.3mf, so everything except the real slicer's own
behaviour is covered.
Against a real install, the OpenSCAD half and check_bed_fit are confirmed end
to end: a 24 tooth wheel rendered out of spirograph.scad measures 38.99 mm and
passes the K1's 220 mm bed. Every flag slice_model builds is present in
Creality Print 7.1.1's --help.
The loop is confirmed end to end against OrcaSlicer 2.4.2 on macOS: the 96 tooth ring slices to 113,808 lines of G-code over 35 layers, a 51 minute print using 7.27 m of PLA, with every coordinate inside the bed.
Creality Print's CLI does not work headless on macOS. On 7.1.1.4472 under
macOS 26, every operation except --help segfaults, including --info with no
profiles loaded at all. It dies in Slic3r::GUI::PartPlate::set_shape called
from Slic3r::CLI::run, a null dereference in GUI bed setup that the headless
path never initialises, and no combination of --datadir, --outputdir or
profile arguments avoids it. Point SLICER_BIN at OrcaSlicer, Bambu Studio or
ElegooSlicer instead, or run Creality Print's CLI on Linux. If you do pass
--datadir, it must be writable: an unwritable one aborts in set_data_dir
rather than segfaulting, which is a different failure with the same outcome.
The workspace guard covers tool arguments, not the scripts themselves.
OpenSCAD's include, use and import can reach any file the process can
read, so running an untrusted .scad is running untrusted code.
License
MIT. See LICENSE.
Not affiliated with Creality, Bambu Lab, Elegoo, the OrcaSlicer project or the OpenSCAD project. Those names appear here only to describe what this drives.
Available Tools
9 toolscheckB
Compile a script without evaluating geometry. Fast syntax and reference check. Returns errors, warnings and any ECHO output.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| source | No | ||
| defines | No | ||
| hard_warnings | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.2/5.0
Behavior3/5
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 usefully discloses the key behavioral trait — geometry is not evaluated, so the check is fast and side-effect-free — and states what comes back (errors, warnings, ECHO). It does not address what happens when both file and source are supplied, permission/path requirements for file, or whether anything is cached or written.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action ('Compile a script without evaluating geometry') followed by speed/scope and return contents. No filler and no repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the summary of returned errors/warnings/ECHO is a bonus rather than a necessity. However, for a 4-parameter tool with 0% schema description coverage, the description leaves the agent unable to decide between file and source or to understand defines/hard_warnings — the substantive gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across all four parameters, and the description adds nothing about file vs. source (the obvious mutual-exclusion question), what defines does, or what hard_warnings changes. The only hint is 'ECHO output,' which relates to nothing in the schema. The description does not compensate for the coverage gap.
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?
The description states a concrete verb and resource ('compile a script without evaluating geometry') and clarifies the mode of operation ('syntax and reference check'), which implicitly separates it from render/preview siblings. It never names a sibling explicitly, so the differentiation is inferential rather than stated.
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?
'Fast syntax and reference check' hints at a pre-render validation use case, but there is no explicit when-to-use statement, no when-not-to-use, and no named alternative (e.g. 'use render to actually evaluate geometry'). Usage is implied rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
echoA
Evaluate a script and return only its ECHO output. Use this to read computed values out of a model without paying for a mesh render.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| source | No | ||
| defines | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that only ECHO output is returned and that it is cheaper than a render, but says nothing about side effects of evaluating a script, which of file/source is required, permissions, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the core action and followed by the usage rationale. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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. However, with no annotations and three fully undocumented parameters, the description omits the input-selection guidance an agent needs to actually invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Three parameters (file, source, defines) exist with 0% schema description coverage, and the description never mentions any of them. It gives no guidance on the file-vs-source choice or the defines map, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Evaluate a script and return only its ECHO output') and explicitly scopes the result to ECHO output. It also differentiates from the sibling 'render' by noting it avoids a mesh render, so an agent can place it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this to read computed values out of a model without paying for a mesh render' gives a clear when-to-use and implicitly positions render as the heavier alternative. It does not state explicit exclusions or when another sibling (check, measure) is preferable, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_filesC
List files in the workspace matching a glob pattern.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | No | **/*.scad |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It doesn't disclose whether listing is recursive, whether hidden files are included, whether paths are absolute or relative, or any permission caveats — the default pattern hints at recursion but that lives in the schema, not the description.
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?
A single front-loaded sentence with no filler; every word earns its place. It is arguably too terse, but there is no structural waste to penalize.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 it is a simple one-parameter read tool. Still, for a no-annotation tool the description leaves unaddressed recursion scope, hidden-file handling, and path semantics, which are meaningful for a glob-based lister.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the single parameter is named only 'Pattern', so the description's phrase 'glob pattern' is the only thing telling the agent the value is a glob rather than a literal filename. That is genuine added meaning, but there is no syntax example, escaping guidance, or note about the default.
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 ('List') and resource ('files in the workspace') plus the filtering mechanism ('glob pattern'). It is clearly distinct from read_file/write_file, though it doesn't explicitly differentiate itself from openscad_info or render which also operate on the workspace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no when-to-use or when-not-to-use guidance and does not name any alternative among the eight siblings. An agent must infer from the name alone that this is the discovery step before read_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
measureB
Render to a throwaway STL and report bounding box, size, volume and triangle count. Use it to check a part fits the print bed.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| source | No | ||
| defines | No | ||
| timeout_s | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full load. It does add genuinely useful behavior: the STL is 'throwaway', implying a temporary artifact rather than a persisted file. But it says nothing about runtime cost, permission requirements, or what happens if the render fails or times out, even though a timeout_s parameter exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the mechanism and followed by the use case. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the returned metrics need not be explained (the description restates them anyway). With zero annotation coverage and four completely undocumented parameters, however, an agent cannot reliably know how to supply a model source or a timeout.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for four parameters (file, source, defines, timeout_s), and the description names none of them. The critical file-vs-source distinction and what 'defines' means are left entirely undocumented, so the description fails to compensate for the coverage gap.
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 action (render to a throwaway STL) and names exactly what it reports: bounding box, size, volume, triangle count. That is enough to separate it from siblings like render/preview, though it never explicitly says how it differs from 'check' or 'render', which sound adjacent.
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?
Gives one clear use case ('check a part fits the print bed') but no when-not-to-use and no routing against the obvious alternatives (render, preview, check). An agent must guess whether this replaces or complements a normal render.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openscad_infoA
Report the OpenSCAD binary, its version, and the workspace directory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full disclosure burden. It does convey the read-only informational nature and the exact data returned, but omits any behavioral caveats such as what happens if the OpenSCAD binary is absent, whether resolution/lookup is performed at call time, or any cost/latency characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence naming the verb and the three returned items, with no filler or redundancy. Nothing could be trimmed without losing information.
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?
An output schema exists, so the description need not enumerate return values or their formats, and it correctly does not. For a zero-parameter read-only info tool the description is close to sufficient; only failure/availability behavior is unaddressed.
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?
The tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the schema already shows. The baseline for a parameterless tool is 4.
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 ('Report') and three concrete resources ('the OpenSCAD binary, its version, and the workspace directory'), which is far more precise than a tautology. It is distinguishable from siblings like render/measure/preview by being purely informational, though it never names those siblings to reinforce the distinction.
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?
Usage is only implied: an agent can infer this is the diagnostic tool to call when it needs environment facts before rendering. There is no explicit when-to-use, no prerequisite/ordering guidance, and no statement of alternatives or exclusions relative to check or the file tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
previewB
Render a PNG of the model and return it as an image.
camera is OpenSCAD's own string. Seven numbers are gimbal style, translate x,y,z then rotate x,y,z then distance, for example "0,0,0,55,0,25,400". Six numbers are eye x,y,z then centre x,y,z. Leave it unset and viewall frames the object automatically. projection is "o" for orthogonal or "p" for perspective. Set full_render to evaluate the real geometry rather than the preview approximation. It is slower but shows what will export.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| camera | No | ||
| source | No | ||
| defines | No | ||
| imgsize | No | 800,600 | |
| viewall | No | ||
| timeout_s | No | ||
| projection | No | o | |
| colorscheme | No | Tomorrow | |
| full_render | No |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It discloses the output type (image), that unset camera means automatic viewall framing, and the performance/accuracy tradeoff of full_render — genuinely useful. It omits error behavior, timeout semantics, and any prerequisites (e.g. whether a file/source must be loaded first).
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?
Front-loads the one-line purpose, then walks parameters in a logical order. The multi-sentence camera explanation is long but earns its place given the non-obvious two numeric-string formats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with no annotations, no output schema, and 0% schema coverage, the description covers the rendering options well but leaves core inputs (file, source), defines, imgsize, colorscheme and timeout undocumented. Minimum viable, with clear gaps an agent must guess around.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate across 10 parameters. It richly documents the two hardest ones (camera's 7-number gimbal vs 6-number eye/centre forms, projection values) plus viewall and full_render, but leaves file, source, defines, imgsize, colorscheme, and timeout_s entirely unexplained — notably the file-vs-source distinction.
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+resource: render a PNG of the model and return it as an image. It also implicitly hints at the preview/render distinction via 'preview approximation' and 'what will export', but it never names the sibling 'render' to route the agent explicitly.
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?
Gives useful guidance on individual options (camera formats, projection, when to use full_render) but offers no explicit when-to-use-this-vs-`render`-or-`check` guidance. Usage is implied through parameter semantics rather than stated selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_fileC
Read a text file from the workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It never states what happens on a missing path, whether binary files error, encoding assumptions, or size limits; only "text file" hints at a constraint.
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?
One tight, front-loaded sentence with no filler. Brevity here reflects under-specification rather than poor structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 described. For a simple read with one required parameter this is nearly adequate, but with zero annotation coverage the missing error/encoding behavior leaves a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single 'path' parameter, so the description must compensate. "From the workspace" does imply workspace-relative resolution, which is real added meaning, but absolute-path support and format expectations remain unstated.
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?
Specific verb+resource ("Read a text file") with a scope qualifier ("text") that implies non-binary handling. It does not differentiate itself from siblings such as list_files or write_file, but the operation is unambiguous on its own.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No statement of when to use this versus alternatives like list_files or preview, and no preconditions. The agent must infer the routing from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
renderA
Render a script to a file in the workspace. The format is taken from the output extension: stl, off, amf, 3mf, dxf, svg, csg, png.
Returns the manifold report OpenSCAD prints (simple, volumes, facets), plus bounding box and volume when the output is an STL.
A png output keeps the picture instead of handing it back, which is what preview does. Use render when the image is the artefact — a before and after pair, a figure for a page — and preview when you only want to look. The view options below apply to png alone and mean what they mean in preview: camera is OpenSCAD's own string, seven numbers for gimbal style (translate x,y,z, rotate x,y,z, distance) or six for eye then centre. Leave camera unset and viewall frames the model. projection is "o" for orthogonal or "p" for perspective. full_render evaluates the real geometry rather than the preview approximation: slower, but it shows what would export, which matters for anything cut or differenced.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| camera | No | ||
| output | Yes | ||
| source | No | ||
| defines | No | ||
| imgsize | No | 800,600 | |
| measure | No | ||
| viewall | No | ||
| timeout_s | No | ||
| projection | No | o | |
| colorscheme | No | Tomorrow | |
| full_render | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the returned manifold report (simple, volumes, facets), the extra bounding box and volume for STL, that png output is retained rather than returned, and that full_render is slower but evaluates real geometry (mattering for cut/differenced models). It does not mention permissions, overwrite behavior, or timeout handling, leaving a few behavioral gaps for a mutation-style tool.
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?
Front-loaded with the core purpose and format rule, then returns, then the sibling comparison, then view options — a sensible order. The paragraph is on the long side with a few discursive phrasings, but nearly every sentence carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 described (though the description does so anyway, usefully). However, for a 12-parameter tool with only one required parameter, the description omits how to supply the input script/model (file, source, defines), image sizing (imgsize), and timeouts — real gaps an agent must resolve from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it covers only some parameters: camera (both seven-number gimbal and six-number eye/centre forms), viewall, projection ('o'/'p'), and full_render are explained with real syntax. But file, source, defines, imgsize, measure, colorscheme, and timeout_s get no mention at all, so roughly half the parameters remain undocumented outside a bare schema title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Render a script to a file in the workspace') and immediately pins down the output format rule (taken from the file extension), listing the supported formats. It also explicitly differentiates itself from the sibling 'preview', so an agent can tell the two apart without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use rule with the alternative named: 'Use render when the image is the artefact — a before and after pair, a figure for a page — and preview when you only want to look.' This is the clearest possible routing guidance and states the png case that selects this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
write_fileB
Write a text file into the workspace, creating parent directories.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| content | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It usefully discloses that parent directories are auto-created, but is silent on the key mutation behavior: whether an existing file is overwritten, truncated, or appended, and what permissions/encoding are applied. That gap matters for a write tool framed as non-destructive by default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. The verb leads, the resource and the parent-directory behavior follow, and nothing extraneous is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema removes the need to describe return values, and the tool is simple with only two required params. However, for a write operation with no annotations and no schema descriptions, the description leaves overwrite semantics and path handling unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema documents nothing about 'path' or 'content'. The description compensates only minimally by calling the payload 'text', leaving questions of relative vs absolute paths and encoding unaddressed; the parameter names themselves are largely self-explanatory.
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 ('Write a text file into the workspace') and adds the side effect of creating parent directories. An agent can distinguish this from read_file/list_files, though the description never names a sibling explicitly, so sibling differentiation is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives no when-to-use guidance, no prerequisites, and no mention of alternatives such as echo or render, which also appear to produce output. The agent must infer that writing is the right choice from the verb alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
9 tool updates
v0.3.0- First observed
check - First observed
echo - First observed
list_files - First observed
measure - First observed
openscad_info - First observed
preview - First observed
read_file - First observed
render - First observed
write_file
TDQS
B3.4/5.0
Scored across 9 tools
Disambiguation4/5
Most tools are clearly distinct: file ops (list/read/write), diagnostics (check, echo), and output tools (render, measure, preview). The main overlap is render vs measure vs preview, since render to STL also reports bounding box and volume and render to PNG overlaps with preview, but the descriptions explicitly delineate when to use each.
Naming Consistency3/5
File operations follow a clean verb_noun pattern (list_files, read_file, write_file), but the evaluation tools are bare verbs (check, echo, render, measure, preview) and openscad_info is a noun-style name. Two internally consistent clusters, but the set mixes conventions overall.
Tool Count5/5
Nine tools is well-scoped for an OpenSCAD workspace server, with each tool covering a distinct workflow stage (environment info, file I/O, syntax check, value extraction, and several render/measure variants). No tool feels redundant or padded.
Completeness4/5
The surface covers the full edit-check-render-inspect lifecycle for CAD scripts. Minor gaps exist, such as no delete/rename/move file operation and no explicit export-to-multiple-formats batch, but agents can work around these via write_file and render.
Maintenance
ActivityStale
ResponsivenessNo issues
Related MCP Connectors
Headless CAD engine & MCP server for 2D/3D drafting, solids, DXF/SVG export, and automation.
Render, verify, describe, and safely edit Mermaid diagrams through MCP.
- OwlCADOAuthcom.owlcad
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.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI assistants to create and manipulate 3D CAD models using OpenSCAD.415 npm1MIT
- AlicenseNot gradedqualityDmaintenanceEnables LLMs to create and manipulate 3D models using OpenSCAD through MCP tools for code-based modeling, preview, and export.1MIT
- AlicenseNot gradedqualityCmaintenanceExposes OpenSCAD CLI as MCP tools for validating, rendering, and exporting parametric 3D models. Enables LLM clients to interactively create and manipulate OpenSCAD designs.4MIT