SkillAgentSearch skills...

noBS-CAD

Local-first, open-source mechanical CAD

Install / Use

claude mcp add jackControls -- npx -y github:jackControls/noBS-CAD

If the server publishes to npm under a different name, use that package instead — check the repo README.

About this skill
🔌

MCP Server

Model Context Protocol server

Quality Score

76/100

Supported Platforms

Claude Code
Claude Desktop

noBS CAD

noBS means no cloud, no BS. noBS CAD is fully local, fully free, and fully open source. It is designed first for mechanical parts, around the familiar sketch-and-extrude workflow.

noBS CAD is currently pre-alpha. Download the current macOS and Windows desktop snapshots from GitHub Releases. These builds are for testing and feedback, not production-critical work.

testPiece modeled in noBS CAD

A simple test piece modeled in noBS CAD. Download the editable testPiece.nbcad project or its testPiece.step geometry backup.

Fillet, chamfer, and a modeled threaded hole in noBS CAD

Fillet, chamfer, and a modeled M12 threaded hole shown together in the editable feature history.

Why this project exists

We are grateful for projects such as FreeCAD and for the community work that proved open-source CAD can be serious and useful. At the same time, we would love an option with a gentler learning curve and the kind of clear, modern experience people have come to expect from commercial and cloud CAD platforms.

That is the direction we are exploring with noBS CAD:

  • project and modeling data stay on your computer;
  • there is no account, subscription, or cloud backend;
  • the complete source is public under an open-source license;
  • the software is free to use;
  • mechanical-part workflows are the priority.

What works today

noBS CAD now spans part design, technical drawings, and an early assembly workflow. It is happiest with small and medium mechanical models; the best way to understand the real boundary is still to try building something useful and report where it breaks down.

The current application includes:

  • a native Bevy/wgpu desktop viewport beneath the React interface, packaged with Tauri for Apple-silicon macOS and x64 Windows;
  • parametric sketches with dimensions, geometric constraints, snapping, construction geometry, patterns, trim/extend, and fillet/chamfer tools;
  • extrude, revolve, sweep, loft, rib, hole, fillet, chamfer, shell, combine, split-body, mirror, pattern, and construction-plane features;
  • modeled hole threads for common ISO metric and Unified standards;
  • live feature previews, direct viewport manipulators, body/component Move/Copy, stable topology references, and an editable design history;
  • ISO and ANSI/ASME drawing sheets with aligned projected and derived views, semantic dimensions, center geometry, manufacturing annotations, title blocks, DXF output, and the platform print/PDF path;
  • reusable components and occurrences, multi-body components, nested subassemblies, grounding, and rigid/revolute/slider/cylindrical/planar/ball/ universal/pin-slot/screw joints;
  • multi-joint kinematic previews, direct mechanism dragging, named positions, motion studies, path export, and native static/sampled interference checks;
  • multi-document tabs, undo/redo, project saving and reopening, and unsaved change protection;
  • local .nbcad project files (ZIP archives containing editable part, drawing, assembly, and metadata records); and
  • STEP import plus AP242 STEP export, including placed visible assembly occurrences as flattened exact geometry.

Drawing and assembly are newer than the core part-modeling path. Assembly is currently deterministic rigid-body kinematics, not a physics or dynamics engine, and large/closed-loop mechanisms still need broad real-world testing. Exact OCCT projection, interference, and export behavior belongs to the native desktop build; the browser build is a development and automated-test surface.

Not every tool or combination is reliable yet. We would especially like people to try real mechanical parts and whatever else is useful to you. Tell us where the workflow becomes confusing, where the geometry fails, and which missing capability would help most.

The .nbcad format may still change during pre-alpha, so we recommend exporting a STEP copy of any design you care about as a backup. STEP preserves the final solid geometry for use in other CAD software, but not the editable noBS CAD feature history.

🐞 Edge-case hunters wanted. Pre-alpha CAD gets reliable by breaking on purpose. Model something real — or work the challenge list of nasty geometry (thin walls, tangent faces, grazing fillets, self-intersecting sweeps). Every report becomes a regression test. Join the Edge-case hunt.

Local automation (MCP)

The repository includes a stateful, headless MCP server for local testing and agent-driven modeling over stdio. It uses the same Rust planning model and native OCCT adapter as the desktop app and registers 105 sketch/solid modeling tools (plus control and export helpers).

Default dynamic disclosure advertises a focus-scoped subset (spine + active and soft packs with TTL) — guidance for agents, not a hard jail. Out-of-focus tools stay callable. Use full_static or cad_list_all_tools when a client ignores notifications/tools/list_changed.

Export via MCP: STEP (CAD interchange), STL (geometry-only mesh), and 3MF (preferred for slicers; per-body color/material plus compatible slicer Metadata hints — not a full pre-sliced project). Session helpers (cad_list_sessions / cad_attach / cad_refresh / cad_detach) load read-only snapshots from NBCAD_SESSION_DIR; live UI co-link is not shipped.

Details: docs/mcp-harness.md.

3D mouse compatibility

noBS CAD is compatible with 3Dconnexion SpaceMouse devices. In the browser development build, the optional hosted 3Dconnexion driver bridge is loaded only after the user clicks the 3D-mouse control; it is not downloaded during ordinary startup.

noBS CAD is an independent project and is not affiliated with, endorsed by, or certified by 3Dconnexion. 3Dconnexion and SpaceMouse are trademarks or registered trademarks of 3Dconnexion.

3D input device development tools and related technology are provided under license from 3Dconnexion. © 3Dconnexion 1992 - 2020. All rights reserved.

We want your feedback

The most helpful contribution right now is simply trying to make a real part and showing us what gets in the way. Not sure what to try? The edge-case hunt guide lists the geometry most likely to break.

For a bug, it helps to include:

  • your operating system and the build you tested;
  • the exact steps from a new project;
  • what you expected and what happened instead;
  • a screenshot or short recording for visual problems;
  • a small .nbcad file when it is safe to share.

Feature requests are welcome too. We want to know what people actually need, not just guess from a checklist of CAD commands. Please open an issue with what you find.

Contributors: see CONTRIBUTING.md for a short, welcoming contribution guide.

Where we are going

High-level directions (mechanical CAD first) are in docs/goals.md: reliable foundation, careful CAM, additive 3MF (with useful color/material metadata) alongside STEP, strong local MCP automation, and staged simulation later. Proposed implementation ideas stay in docs/proposed-architecture.md until prototyped.

Near-term engineering priorities:

  1. Make sketching, solid modeling, drawings, assemblies, history, undo, and project-file workflows more dependable.
  2. Harden closed-loop and large-assembly solving, connector repair, collision workflows, and component editing.
  3. Keep improving selection, manipulators, navigation, responsive desktop UI, and accessibility on both macOS and Windows.
  4. Improve interactive preview, picking, recompute, and large-model rendering performance.
  5. Turn reported failures into focused cross-platform regression tests.

In the longer run, we prefer a true native desktop experience. The browser build is valuable for development and automated testing, but it is not the intended final product experience.

We would also like to explore a functional, modern CAM workflow for 3-axis machines. We know that is ambitious and difficult, so we plan to approach it carefully: start with research and testable pieces, listen to machinists, and earn trust one operation at a time. We would love to hear from CAM experts!

Build locally

Windows x64 portable build

The Windows release path targets Windows 10 version 1803 or newer and Windows 11. It produces a portable ZIP rather than an installer, uses the WebView2 runtime supplied by Windows, and requires Microsoft's centrally installed Visual C++ v14 x64 Redistributable. The desktop build uses the same native Bevy viewport as macOS, backed by wgpu's DX12/Vulkan support; React and CSS remain the real menu, tab, dialog, and accessibility interface.

The build itself requires Windows, Visual Studio C++ Build Tools, the Windows SDK, Rust, Node.js, wasm-pack, and the pinned OCCT 7.9.3 vcpkg dependency. After installing the pinned vcpkg manifest:

$env:OCCT_ROOT = "$PWD\vcpkg_installed\x64-windows"
npm ci
npm run bundle:windows:portable

See Windows portable packaging for the complete setup, output layout, runtime requirements, and GitHub Actions workflow.

Native macOS development bundle

The macOS packaging path uses Tauri with OCCT 7.9.x.

brew install opencascade wasm-pack
rustup target add wasm32-unknown-unknown
npm ci
npm run bundle:macos

The resulting ad-hoc-signed development application and disk image are written to:

src-tauri/target/release/bundle/macos/noBS CAD.app
src-tauri/target/release/bundle/dmg/noBS CAD_0.1.0_aarch64.dmg

Development packages intentionally retain Rust symbols for crash diagnosis. The desktop packaging workflow treats a v* Git tag as the production boundary and sets CARGO_PROFILE_RELEASE_STRIP=symbols for both macOS and Windows. To reproduce a stripped production package locally, set that variable before running the platform bundle command:

CARGO_PROFILE_RELEASE_STRIP=symbols npm run bundle:macos
$env:CARGO_PROFILE_RELEASE_STRIP = "symbols"
npm run bundle:windows:portable

See OCCT packaging and browser/WASM strategy for native SDK overrides, the Apple-silicon GitHub Actions build, and packaging details.

Browser development build

The browser build is a development and testing environment. It requires Node.js, npm, a current Rust toolchain, the wasm32-unknown-unknown target, and wasm-pack.

rustup target add wasm32-unknown-unknown
npm ci
npm run build:wasm
npm run dev

Open the local address printed by Vite. Create a production browser bundle with:

npm run build

Project structure

  • React, TypeScript, and Vite provide the DOM interface; Bevy renders the native desktop viewport.
  • Host-neutral Rust crates own project data, sketches, feature definitions, history, stable references, drawing intent, assembly structure, kinematics, and recompute planning.
  • Native builds use Open CASCADE Technology through a narrow C++ bridge.
  • The browser development build uses the same Rust model through WebAssembly and OpenCascade.js for solid operations.
  • .nbcad files are inspectable ZIP archives containing a manifest and model data.

Public technical references:

Truncated for display — read the full file on GitHub.

Related Skills

View on GitHub
GitHub Stars3
CategoryDevelopment
Updated1d ago
Forks2

Languages

Rust

Security Score

75/100

Audited on Aug 16, 2026

1 medium2 low