SolidCraft: a parametric CAD core in Rust, and how it admits its limits

The oracle test compares against FreeCAD, and admits the gap

Most open source CAD projects describe themselves qualitatively. SolidCraft publishes a number instead: 75 of 76 public reference parts match their analytic or FreeCAD-computed volume, area, centre of mass and bounding box, and the remaining one is a tracked bug.

That statement is more useful than it first appears, and also narrower than it sounds. It says the mass properties and extents of a built solid are correct on 75 known cases. It does not say the surfaces are equivalent to FreeCAD's in every configuration, and the README says so directly: these checks do not establish complete geometric or workflow equivalence.

So the honest reading is that SolidCraft has a regression suite for numerical correctness and no claim of overall parity. If your decision hinges on whether a fillet at a specific tangent condition produces the same B-rep face as FreeCAD, this suite does not answer it. What it does answer is whether the obvious operations compute the right volume, which is a real and frequently skipped check.

The coverage picture is deliberately not hidden. Commands SolidCraft has are listed by area in `docs/features.md`, status and plans sit in `ROADMAP.md`, and open work is tracked as GitHub issues.

One kernel crate, several front ends, and a vendored foundation

The workspace manifest shows the shape of the project more clearly than any description. Members are `crates/*`, `apps/*`, and `xtask`, with `vendor` explicitly excluded from the workspace because it holds third-party code kept with local fixes that should not be linted as the project's own.

The internal dependency list is essentially the architecture. There is `solidcraft-geom` for the base geometry layer, `solidcraft-kernel` for the modelling kernel, `solidcraft-sketch`, `solidcraft-render` alongside a separate `solidcraft-gpu` crate, `solidcraft-doc` for the documentation book, `solidcraft-io` for STEP and file handling, `solidcraft-engine` for the feature timeline, `solidcraft-ui-egui` for the interface, `solidcraft-mcp` for the agent interface, and `solidcraft-derive` for proc macros.

The geometry foundation is not written from scratch. It sits on `truck-modeling`, `truck-shapeops`, `truck-meshalgo`, `truck-stepio`, and `truck-topology`, with the manifest noting the kernel is Apache-2.0 under an architecture decision record, and that only `crates/kernel` uses it. Trimmed faces use constrained Delaunay triangulation with Ruppert refinement via `spade`. Building on an existing kernel means SolidCraft inherits STEP import capability rather than having to write it, and it means the geometry core is auditable separately from the parametric layer.

The workspace declares `edition = "2024"` and `rust-version = "1.95"`, so building from source needs a current toolchain.

Unsigned builds on every platform, and what that costs the user

The download matrix is unusually complete for a young project. Windows gets an MSI for x64, ARM64, and 32-bit, plus a portable zip that runs without installing, and it is on WinGet as `bherbruck.SolidCraft`. macOS gets a universal disk image covering Apple silicon and Intel, dragged into Applications. Linux gets an AppImage, a `.deb` for Ubuntu, Debian and Mint, an `.rpm` for Fedora and openSUSE, a Snap, and Flatpak, with ARM64 variants of the AppImage, `.deb`, and `.rpm`. The web build needs nothing at all.

Then the caveat, stated without hedging: the downloads are not signed yet. On Windows, if SmartScreen warns, the user is told to choose More info, then Run anyway. On macOS, the first launch requires right-clicking the app in Applications and choosing Open.

Both of those instructions train users to click through a security warning. For personal use that is a mild annoyance. That is the practical ceiling on distribution today, and it has nothing to do with the modelling kernel.

The MCP server turns CAD into an agent-reachable tool

The third front end is the one that distinguishes this from a desktop CAD clone. Alongside the desktop and browser builds there is a built-in MCP server, and the README's showcase is a scientific rover assembled entirely through it: SELENE, by @0xlillith, with 3,323 editable timeline steps that rebuild with no errors.

That example is chosen well, because it demonstrates the property that matters for agent-driven modelling. The model is a timeline of 3,323 steps, and the claim is that it replays and rebuilds cleanly rather than that it was drawn by hand. A timeline that rebuilds deterministically is exactly what an automated system needs; a sequence of interactive picks is not.

The repository carries `skills/` and both `AGENTS.md` and `CLAUDE.md` at the root, which tells you the project expects automated agents to work in it and documents how. `examples/` holds acceptance cases, regression cases, a `bracket.json`, and render scene files, so scripted models are a first-class part of the repo layout.

The dual front ends also share one engine, which means a model authored through MCP and one drawn in the egui interface are the same document rather than two exports. The README does not document any MCP transport details or tool names, so those live in the developer guide rather than the README.

A parametric timeline, not a feature tree

The demo description is more informative about the interaction model than any feature list would be. A Raspberry Pi 4 case is built from an empty design: a sketch dimensioned with the board's parameters, an extrude, a fillet, a shell, a rim rounded in one pick, standoffs patterned onto the board's mounting hole rectangle at 58 by 49 mm, port cut-outs, vent slots, the text "Pi 4" engraved in DejaVu Sans Bold, and a PETG material defined in the design with its mass shown in Properties. Then the height parameter changes from 24 to 32 mm and everything rebuilds.

Three things are worth pulling out. The sketch is dimensioned with parameters rather than fixed numbers, which is what makes the rebuild meaningful. The pattern is driven by the mounting hole rectangle, so the standoffs follow the board rather than being placed by hand. And the material carries a mass property surfaced in the UI, which is a manufacturing-data concern rather than a geometry one.

The rebuild is the point of a parametric modeller, and the demo reports 9x playback for that case. That figure is for one specific Raspberry Pi case in one recorded run, so treat it as evidence that the rebuild loop is responsive rather than as a general performance claim.

Rust licence, dual licensing, and a vendored dependency tree

The workspace package declares `license = "MIT OR Apache-2.0"`, and both licence files are in the repository root alongside `NOTICE` and a `THIRD-PARTY-LICENSES.txt`. That dual licence is the conventional Rust choice, giving you a choice of terms, and it is worth noting against the fact that the geometry kernel foundation is separately Apache-2.0.

The vendored tree is the more substantive point for an adopter. `vendor/` is excluded from the workspace lint but is described as third-party code kept with local fixes, and `ATTRIBUTION.md` plus `THIRD-PARTY-LICENSES.txt` exist to account for it. Vendoring with local patches can make builds more reproducible, but you must carry and reapply the patches when upstream advances. `deny.toml` and `clippy.toml` sit at the root, so dependency policy and lint configuration are both checked in rather than left to each contributor's machine.

The licence question for a company is therefore not the project's own terms but the aggregate: your build includes a vendored, patched dependency tree whose licence mix is documented in a text file rather than resolved by a package manager at build time.

Reading the release cadence before you pin anything

The release list is the best available signal about project velocity, and it is dense. v0.11.0 shipped on 2026-10-14, v0.11.1 followed the same day, and a nightly tagged v0.11.0-nightly.20261015.42.1 landed on 2026-10-15. The repository is not archived and the last push was on 2026-10-15.

A patch release and a nightly build appearing within a day of each other indicates active work, which is good, and it also means the version number moves fast enough that a pinned build will age quickly. For a project under version 0.11 with the README saying early but usable, that is expected rather than alarming.

The practical consequence is about workflows rather than code. If you script models through MCP, decide whether you pin a release tag or track main, because the nightly tags show that a moving build is available. The README keeps older versions and checksums on the releases page, which matters more than usual given that nothing is currently signed.

Editorial conclusion

Adopt SolidCraft if you want parametric modelling you can script, including through the MCP server, and you are willing to work in a project whose README states it is early but usable for simple parts. Do not adopt it as your production CAD tool for complex assemblies, since the project's own oracle checks do not establish complete geometric equivalence with FreeCAD. Verify first whether the commands you need appear in docs/features.md, because the coverage is listed by area rather than assumed.

Frequently asked questions

Official sources

1. bherbruck/solidcraft on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases