CAD/CAE Copilot
Most AI CAD tools stop when a picture appears. CAD/CAE Copilot turns an engineering spec into real, editable, verifiable CAD — and keeps every artifact reproducible.
An AI-native CAD/CAE/CAX workbench. An MCP-capable agent writes real
build123d / OpenCASCADE geometry, exports STEP/STL/GLB, names the parts,
exposes stable topology pointers, runs a deterministic critique, and can
continue into CAE — all preserved in one reproducible .aieng package.
You bring your own MCP client (e.g. Claude Code, Codex, Copilot, Cursor),
which carries its own model access. The aieng backend itself needs no API key.
What is this? ·
Quick Start ·
CAD Examples ·
Benchmarks ·
Why aieng ·
One-prompt setup ·
MCP Setup ·
Agent Guide
English | 中文
Real STEP/STL/GLB · Editable parameters · Named parts · Stable topology pointers · Deterministic critique · CAD → CAE artifacts · Approval-gated actions
At a glance
CAD/CAE Copilot lets an MCP-capable agent turn an engineering specification into
a reproducible CAD/CAE package.
- Input: explicit mechanical specs, dimensions, constraints, and follow-up
edits.
- CAD kernel: real build123d / OpenCASCADE geometry, not a mock renderer.
- Outputs: STEP, STL, GLB, generated source, thumbnails, topology maps, and
.aieng packages.
- Editability: named parts, editable parameters, and stable
@face:*
pointers when topology mapping succeeds.
- Verification: deterministic critique, geometry checks, design-rule
assertions, and diff-aware edits.
- CAE path: material, loads, constraints, mesh, solver artifacts, and
evidence are kept beside the CAD model.
- Agent model: bring your own MCP client and model access; the backend
itself does not require an API key.
engineering spec
-> MCP agent
-> build123d / OpenCASCADE CAD
-> named parts + topology pointers
-> critique / CAE setup / solver evidence
-> reproducible .aieng package
What is this? — architecture & information flow
In one picture: a natural-language engineering spec becomes optimized, verified
CAD/CAE, driven end-to-end by your own MCP agent and preserved in one
reproducible .aieng package.
User requirement → agent (plan & reason) → MCP tool layer → CAD modeling &
editing → CAE setup & simulation → result evaluation → closed-loop
optimization. A human-in-the-loop trust & approval layer gates every
mutation, a credibility tier is stamped on every result, and all artifacts
land in a self-describing .aieng package — so any MCP-capable agent can design,
analyze, optimize, and deliver verified, reproducible CAD/CAE solutions.
Quantitative benchmarking
The project includes a machine-readable analytical FEA benchmark corpus at
aieng/benchmarks/datasets/analytical_fea.
It builds runnable .aieng cases, compares solver metrics against documented
closed-form references, and emits an
aieng.benchmark.analytical_fea.scorecard JSON artifact. The harness reports
"agreement within tolerance"; it is not certification or a production-safety
claim.
cd aieng
python -m aieng.benchmarks.analytical_fea --out analytical_fea_scorecard.json
CI runs the analytical benchmark corpus tests so corpus/reference drift and
scorecard regressions fail fast.
Quick start
Three ways in — pick one and you're modeling in minutes.
Before you start: you need your own MCP client (Claude Code, OpenAI
Codex, GitHub Copilot, Cursor, …) with its own model access. The aieng
backend itself needs no API key — your agent connects to it over MCP and
drives the workbench through its own harness.
For a first try, Docker (Option 2) is the most reliable — it pins the
build123d / OpenCASCADE / CalculiX stack so nothing has to compile on your
machine. The local dev install is best once you intend to hack on the code.
Option 1: GitHub Codespaces (fastest, zero install)
Click "Open in GitHub Codespaces" above. The environment sets itself up;
when it finishes loading, run make dev (or python3 scripts/dev.py if make
is unavailable). Then connect an agent and paste the
motor mounting fixture prompt, or the
shorter bracket prompt:
Create a 120 × 80 × 12 mm machined bearing support bracket with a centered
Ø42 mm horizontal bearing bore, four Ø10 mm base mounting holes, and two
mirrored gussets. Preserve the exact dimensions, expose editable parameters,
verify the final geometry, and run the deterministic engineering critique.
Inspect the generated model, named parts, verification results, and stable
@face:* references in the workbench.
Option 2: Docker all-in-one (recommended local package)
Packages the backend, built viewer, MCP HTTP server, build123d / OpenCASCADE
dependencies, and CalculiX into one container.
Quick start — pull the published image (no local build):
docker pull ghcr.io/armpro24-blip/aieng-workbench:latest
docker run --rm -it -p 8000:8000 -p 8765:8765 -v aieng-data:/data ghcr.io/armpro24-blip/aieng-workbench:latest
For an agent-guided first run, paste the
one-prompt setup into your MCP-capable client.
It checks Docker, backend health, MCP endpoint visibility, onboarding calls, and
approval-surface readiness before any optional CAD smoke.
The alpha image is published to GHCR from main after the Docker smoke passes
(latest + an immutable sha-<commit> tag). Alpha-scoped, not
production-certified.
Releases: the current pre-release is
v0.1.0-alpha.4.
Distribution is the Git tag plus the GHCR image — PyPI publication is not
planned, so the Git form below is the install path, not a stopgap. To run just
the MCP server without cloning (Python 3.11+, pinned to the release tag):
uvx \
--from "aieng-workbench-mcp[full] @ git+https://github.com/armpro24-blip/[email protected]#subdirectory=aieng-ui/backend" \
--with "aieng-format @ git+https://github.com/armpro24-blip/[email protected]#subdirectory=aieng" \
aieng-workbench-mcp --approval-mode client --data-dir ~/.aieng-workbench
What a successful first run looks like
After the first successful CAD smoke, you should be able to verify:
- the workbench viewer shows a generated model,
- STEP/STL/GLB or preview artifacts were written,
- generated source and metadata are preserved in the project package,
- named parts and editable parameters are present when the model exposes them,
- stable topology references such as
@face:* are available when topology
mapping succeeds,
- deterministic critique or geometry checks report findings honestly,
- and the
.aieng package contains reproducible artifacts and provenance.
CAE setup, mesh generation, and solver execution are separate approval-gated
steps. A readiness or preflight report does not mean the solver has run.
Contributor path — build locally from source (Docker Compose or manual,
for developing the image or running an unmerged branch):
docker compose up -d
# or:
docker build -t aieng/workbench:local .
docker run --rm -it -p 8000:8000 -p 8765:8765 -v aieng-data:/data aieng/workbench:local
Open the viewer at http://localhost:8000/app/ and point an MCP-over-HTTP client
at http://localhost:8765/sse. Projects and .aieng packages persist in the
aieng-data volume. The container enables AIENG_MCP_MANAGED_APPROVAL=1 by
default, so approval-gated CAD/CAE tools surface through the workbench UI.
Option 3: Local developer install
Best when you intend to modify the code. Prerequisite: a conda env named
exactly aieng311 (Python ≥ 3.11) with build123d — the MCP configs
and run scripts assume this name. The build123d / OpenCASCADE (OCP) install
can be slow or fail on some platforms; if it does, prefer the Docker path
above.
conda create -n aieng311 python=3.11 -y
conda activate aieng311
pip install build123d
cd aieng-ui/backend && pip install -e .
Then start both services in one terminal (Ctrl+C stops both):
make dev # macOS / Linux / WSL
.\dev.ps1 # Windows PowerShell
python scripts/dev.py # cross-platform fallback
Backend → FastAPI on http://127.0.0.1:8000; frontend → Vite on
http://localhost:5173. Custom ports: BACKEND_PORT=8080 FRONTEND_PORT=3000 make dev.
make backend # or: cd aieng-ui/backend && uvicorn app.main:app --host 127.0.0.1 --port 8000 --reload
make frontend # or: cd aieng-ui/frontend && npm install && npm run dev
cd aieng-ui/backend && python -m pytest # backend test suite
From specification to verified CAD
The hero model above was built from an explicit industrial fixture
specification — fixed dimensions, named parts, exact hole and slot locations,
required symmetry, and no permission to invent extra geometry. The agent
executes and verifies the spec; it does not silently fill in the engineering.
Create a fully specified industrial motor mounting fixture using millimeters.
Coordinate system:
- X is the fixture width, Y is the fixture depth, and Z is vertical.
- Center the complete fixture on X=0.
- Place the bottom face of the base plate at Z=0.
Base plate:
- Create a 180 × 140 × 14 mm base plate.
- Add four Ø11 mm vertical through-holes at X=±70 mm and Y=±50 mm.
- Add an Ø18 mm, 5 mm deep counterbore to the top of every mounting hole.
- Add a 3 mm fillet to the four outside vertical corners.
Motor support:
- Add a centered rear vertical support plate, 130 mm wide, 14 mm thick,
and 120 mm tall above the base.
- Add a Ø72 mm horizontal locating bore through the plate along Y.
- Position its center at X=0 and Z=78 mm.
- Add four Ø8.5 mm horizontal mounting holes on a Ø100 mm bolt circle.
Reinforcement and rails:
- Add two mirrored 12 mm thick triangular gussets extending 45 mm forward
and rising 65 mm above the base.
- Add two separate 110 × 12 × 8 mm guide rails centered at X=±38 mm, Y=-12 mm.
- Add one centered 70 × 6 mm longitudinal slot to each rail.
Modeling requirements:
- Create named parts "fixture_body", "guide_rail_left", and "guide_rail_right".
- Color the fixture body dark blue-gray and both guide rails orange.
- Declare all major dimensions as editable UPPER_SNAKE_CASE constants.
- Preserve exact left/right symmetry.
- Verify overall dimensions, named parts, and stable topology pointers.
- Run the deterministic engineering critique after modeling.
- Do not add a motor, fasteners, logos, decorative features, or unspecified geometry.
Industrial CAD examples
Each example starts from explicit dimensions, feature locations, and modeling
constraints — the agent executes and verifies the specification rather than
inventing the requirements.
- Machined bearing support bracket — one manufacturable solid with a
specified base envelope, horizontal bearing bore, symmetric mounting pattern,
mirrored gussets, fillets, and chamfers. The workbench caught and corrected
construction errors, then verified the final datums, topology, editable
parameters, and engineering critique.
- Six-port pneumatic manifold — a specification-driven manifold with an
exact
160 × 50 × 40 mm envelope, six equally spaced outlets, axial inlet
ports, counterbored mounting holes, edge fillets, opening chamfers, and
editable dimensions.
- Industrial junction-box assembly — a two-part enclosure assembly with
named base and lid solids, internal mounting bosses, cable-gland openings,
separated lid placement, generated STEP/STL/GLB artifacts, and a selectable
stable face pointer for precise follow-up work.
Why aieng — beyond text-to-CAD
Most AI CAD and text-to-CAD demos stop when a model appears. aieng treats
geometry generation as one step in a reviewable engineering workflow built
around self-describing .aieng packages: editable parameters, stable topology,
provenance, and a full CAD → CAE path all survive after the picture.
Think of .aieng as a portable engineering evidence passport. It is not a CAD
kernel, solver, PLM database, or certification stamp; it is the shared package
where humans and MCP-capable agents can inspect what geometry exists, what CAE
setup is present, what result evidence was written, which claims cite evidence,
and what provenance explains how the package got there. A package can be handed
to another engineer or agent without losing the CAD/CAE context that matters for
review; see the package handoff runbook for the
safe send/receive flow.
| Capability | Typical text-to-CAD demo | aieng |
|---|
| Generate real CAD exports (STEP/STL/GLB) | Yes | Yes |
| Execute explicit dimensions and datums | Partial | Yes |
| Preserve editable source and parameters | Partial | Yes |
| Name parts and expose stable topology references | Rarely | Yes |
| Verify geometry and run deterministic critique | Rarely | Yes |
| Diff every edit (topology drift + manufacturability) | No | Yes |
Design-rule assertions that fail the build (require) | No | Yes |
| Stamp a credibility tier on every result (V&V-40) | No | Yes |
| Preserve artifacts and provenance in one package | Rarely | Yes |
| Continue from CAD into CAE workflows | Rarely | Yes |
| Require approval for gated engineering actions | Rarely | Yes |
| Standard parts library | No | Yes |
| Extended material database (51 materials) | No | Yes |
| BOM generation | No | Yes |
What that buys you:
- Real, exportable CAD — agent-written build123d / OpenCASCADE geometry
produces STEP, STL, GLB, topology maps, feature graphs, and 4-view thumbnails.
Not a stub.
- Specification-driven execution — agents follow explicit dimensions,
datums, feature positions, symmetry, and manufacturing constraints instead of
freely inventing a design.
- Inspect and correct — geometry reports, deterministic critiques, named
parts, and stable
@face:* pointers support precise verification and
follow-up edits.
- Reproducible engineering packages —
.aieng packages preserve geometry,
generated source, analysis state, artifacts, metadata, and provenance, so a
result is reviewable instead of opaque.
- Agent-independent MCP tools — Claude Code, GitHub Copilot, OpenAI Codex,
Cursor, and other MCP-capable agents drive the same backend.
- CAD → CAE path — material, boundary conditions, mesh, solver runs, result
mappings, and evidence live beside the CAD model.
Who it's for: AI agent / MCP developers wanting engineering tools beyond
text and code; mechanical engineers exploring AI-assisted CAD/CAE with real
geometry; and makers, researchers, and open-source contributors interested in
CAD, CAE, MCP, VS Code extensions, or build123d / OpenCASCADE.
Proof, not just screenshots
Each successful CAD run can preserve inspectable artifacts, not just a rendered
image:
- generated build123d source,
- STEP/STL/GLB exports,
- named parts and editable parameters,
- topology maps and stable
@face:* pointers when mapping succeeds,
- preview thumbnails,
- critique and geometry-check results,
- provenance and package metadata inside the
.aieng evidence package.
That means another engineer or MCP-capable agent can inspect, modify, rerun, and
review the result instead of trusting a static render.
Trust layer — verified & explainable by construction
The crowded field is generation; the empty field is trust. Every
AI-suggested change here is checked and explainable, not just rendered:
- Diff on every edit — each parametric edit / part swap / append returns a
regression_diff (did unintended parts move?) and a critique_diff (did the
edit worsen min-wall / hole-spacing / floating-part / symmetry rules?),
re-surfaced as a first-class before→after diff in the viewer.
- Design-rule assertions — author
require(WALL >= 3, "wall below 3mm") (or a
bare assert) in build123d code; a violation fails the build deterministically
with a structured design_rule_violation, so constraints are verified by
construction instead of hoped for.
- V&V-40 credibility tiering — every result-bearing output carries one ordered
tier (
critique_finding < surrogate_prediction < proxy_assembly_result <
executed_solver_result); a claim is never presented as more credible than its
evidence, and production_ready is never assumed. Running the solver is not
enough: a completed run on a mesh whose measured accuracy band is unreliable
is stamped unreliable_mesh, not executed_solver_result.
- Mesh accuracy by measurement, not hope — FE meshes default to quadratic
tetrahedra (C3D10; linear tets under-predicted bending stress ~2× in
calibration), and every mesh carries a measured
accuracy verdict
(reliable / marginal / unreliable) plus an optional GCI/Richardson
convergence study (cae.mesh_convergence).
- Surrogate error-band discipline — a surrogate-predicted number is never shown
without its uncertainty band + a leave-one-out validation error.
- Consistency-gated agency — low cross-sample agreement on an LLM-judged step
routes to ask the user instead of acting on a guess.
- NAFEMS-style V&V suite — analytically-backed linear-static benchmarks guard
the solver path in CI (results are verified against reference within tolerance,
never "certified").
How it works
- Provide a mechanical specification with explicit dimensions and constraints.
- An MCP-capable agent uses aieng tools to create real CAD geometry.
- aieng exports the model and records named parts, topology, editable
parameters, source, and provenance.
- Inspect the result visually and numerically, then reference exact parts,
features, or faces (
@face:*) for follow-up changes.
- Query the extended material database (51 engineering materials) to assign
accurate mechanical and thermal properties to parts.
- Insert standard parts — fasteners, bearings, shafts, structural profiles,
and standard holes — directly from the library into the model.
- Generate a Bill of Materials (BOM) from the assembled parts for review
and procurement.
- Continue into CAE setup and solver workflows once the required engineering
inputs are available.
Materials & standard parts workflow:
aieng.list_materials { category: "Aluminum Alloy" }
aieng.get_material_details { material_name: "Al6061-T6" }
aieng.compare_materials { material_names: ["Al6061-T6", "Steel-316L"] }
aieng.list_standard_parts { category: "fastener" }
aieng.get_standard_part_specs { part_type: "hex_bolt", preset_name: "M8" }
aieng.insert_standard_part { part_type: "hex_bolt", preset_name: "M8", position: [0,0,0] }
aieng.generate_bom { format: "markdown" }
The workbench UI and the
aieng-vscode-extension provide visual inspection for
live backend projects and .aieng packages.
Visual inspection in VS Code
The VS Code extension is the most visual way to experience aieng — a front-end
for the .aieng package format, MCP tools, and CAD/CAE backend that brings the
AI-CAD design loop directly into your editor. It can:
- open a local
.aieng package as a read-only custom editor,
- connect to a live backend project preview,
- visualize generated GLB/STL CAD outputs,
- and copy stable
@face:id pointers back into your chat with an agent.
The extension is one layer of the system, not the whole thing — the core is the
package format and engineering backend that let agents and humans share
reproducible CAD/CAE project state. Setup and development notes live in
aieng-vscode-extension/README.md. For the
current editor-first path, see
docs/mcp-first-vscode-workflow.md.
Drive aieng from AI agents via MCP
The backend exposes its tool registry as an MCP server (aieng-workbench),
so agents drive the workbench through their own harnesses — no API key needed on
our side. Connection configs are committed and load automatically for a fresh
clone, assuming the aieng311 env exists:
| Agent | Config file |
|---|
| Claude Code | .mcp.json |
| VS Code / GitHub Copilot | .vscode/mcp.json |
| Cursor | .cursor/mcp.json |
| Cline | its own cline_mcp_settings.json (copy the block from MCP_SETUP) |
| OpenAI Codex | add [mcp_servers.*] to ~/.codex/config.toml (see MCP_SETUP) |
Approval works three ways (--approval-mode): your client's own prompt
(client), the workbench viewer / VS Code extension card (managed), or
headless MCP elicitation (elicit) for agents with no UI — with a fail-safe
deny when no surface can answer. Run aieng-workbench-mcp --doctor to check that
your MCP config, backend, and tool set are wired before you start. Full matrix
of tested-vs-documented clients:
MCP client compatibility.
First three calls every session:
1. aieng.agent_readme -> compact operational onboarding
2. aieng.list_projects -> discover project IDs
3. aieng.agent_context { project_id } -> geometry state, pointers, next steps
Use aieng.guide { topic } for task-specific detail, or
aieng.agent_readme { detail: "full" } when the complete canonical
AGENTS.md is genuinely required.
The sustainable modeling loop:
cad.get_source -> see accumulated source, named parts, has_base
cad.execute_build123d -> build/extend geometry (mode=replace|append)
- set .label on parts -> semantic names you can reference
- mode=append builds onto `previous_result`
- returns a thumbnail + named_parts / parts_added
(inspect the result, repeat)
Full tool details, pointer syntax, and approval-gated operations live in
AGENTS.md; MCP wiring by client in
aieng-ui/backend/MCP_SETUP.md.
Showcase demos
Canonical backend demos, each runnable as a single test:
1. CAD Generation → Structural FEA → Topology Optimization
Runs the CAD → FEA → topology optimization loop and writes back editable
optimized geometry.
pytest aieng/tests/test_topology_optimization.py -q
Key artifacts: analysis/topology_optimization.json, geometry/shape_ir.json
Boundary: 2D plane-stress; 3D SIMP is experimental/reference only.
Details →
2. Rebuild CAD from Mesh → Export STEP
Reconstructs analytic CAD from a mesh and exports STEP when the shell validates.
pytest aieng/tests/test_mesh_brep_solidification.py -q
Key artifacts: geometry/reconstructed.step (when valid),
graph/mesh_brep_stitching_plan.json
Boundary: Mesh-derived/lossy; plane/cylinder dominant; freeform/NURBS
future work; partial shells do not produce STEP.
Details →
3. Assembly Model → Selected-Part Optimization
Builds a proxy assembly analysis model and optimizes one selected design part.
pytest aieng-ui/backend/tests/test_assembly_topopt_demo.py -q
Key artifacts: analysis/assembly_topology_optimization.json,
parts/bracket/geometry/optimized_shape_ir.json
Boundary: Proxy connections only; no real contact/friction/bolt preload;
one design part only; not production-certified.
Details →
4. Design Study: Adjustable Dimensions → Compare → Adopt
Validates, executes, compares, and optionally adopts parameterized design
candidates without overwriting the baseline.
pytest aieng-ui/backend/tests/test_design_study_demo.py -q
Key artifacts: analysis/design_study_candidate_ranking.json,
analysis/design_study_acceptance.json,
accepted/candidate_good/geometry/shape_ir.json
Boundary: Static metrics in demo; no autonomous optimization; no baseline
overwrite; ranking is advisory.
Details →
5. Real CAD->CAE Value Demo
Runs one canonical single-solid cantilever through CAD creation, face-pointer
selection, approval-gated CalculiX execution, a GCI/Richardson mesh-convergence
study, FRD-derived viewer fields, and a shareable engineering report.
python aieng-ui/backend/scripts/value_demo_packet.py --format markdown
Key artifacts: simulation/runs/value_demo_run_001/outputs/result.frd,
results/computed_metrics.json, analysis/mesh_convergence_report.json,
engineering report HTML.
Boundary: Requires real Gmsh/CalculiX; linear static — discretization
uncertainty is bounded by the GCI study (measured 1.31% on the reference
cantilever), not assumed away; no synthetic fallback counts as a successful demo.
Runbook ->
Current limitations
Honesty boundaries — outputs are review material, not production sign-off:
- Not production-certified CAD/CAE. Outputs still require human engineering judgment.
- No fatigue or durability analysis. Supported: linear static, modal, linear buckling, steady-state thermal, one-way thermal-stress. A cyclic load, a cycle count and a required life have nowhere to be entered, and the material library carries no endurance or S-N data. A cold-start agent trial found this boundary stated in exactly one document, so it is stated here too.
- Assembly contact and bolt preload are proxy-only; real nonlinear contact is future work.
- 3D SIMP is experimental/reference, not production-certified.
- Mesh-to-CAD works best for plane/cylinder-dominant geometry; broader freeform
and NURBS fitting is future work.
- Design study is agent-guided explicit execution, not autonomous global optimization.
Repository layout
| Path | Status | What it is |
|---|
aieng-ui/ | Active | FastAPI backend, React workbench, and MCP server — the active CAD/CAE engine (build123d) |
aieng/ | Core library | .aieng semantic package format engine, schemas, validation, CLI, Shape IR, and evidence model |
aieng-vscode-extension/ | Active | VS Code visualization front-end for .aieng packages and live project previews |
aieng-agent-skills/ | Active | SKILL.md contracts teaching agents how to use the ecosystem |
legacy/aieng-freecad-mcp/ | Legacy | Old FreeCAD execution adapter — not used by the active path |
archive/CAD-Agent-main/ | Archived | Historical and experimental auxiliary CAD-agent material |
Documentation
| Doc | Purpose |
|---|
| AGENTS.md | Canonical agent guide — tools, workflows, and conventions |
| docs/prompt-guide.md | Plain sentences to type at your connected agent — the user-facing phrasing guide |
| aieng-ui/backend/MCP_SETUP.md | Per-agent MCP wiring for Claude Code, Copilot, Cursor, and Codex |
| docs/cad_execution_boundary.md | Local-first execution boundary, privacy posture, approval gates, and sandbox limits |
| docs/parametric-edit-governance.md | Reviewable, reversible CAD parameter edit workflow and honesty boundaries |
| docs/cae-credibility-ladder.md | CAE evidence tiers from artifact presence to benchmark calibration and review support |
| docs/canonical_engineering_scenarios.md | Canonical engineering scenarios - reproducible packs, verification commands, artifacts, and honesty boundaries |
| aieng-vscode-extension/README.md | VS Code extension usage and development notes |
| aieng/docs/showcase_gallery.md |
Contributing
Contributions are welcome across the package format, backend workflows, MCP
tooling, and VS Code front-end. Work that improves reproducibility, visual
inspection, engineering honesty boundaries, or agent usability is especially in
scope.
Notes
- Public repo. No secrets are committed; runtime data (
data/projects/),
virtual environments, node_modules, and embedded conda envs are gitignored.
- If your CAD env is not named
aieng311, edit the -n aieng311 argument in
the MCP configs or point command directly at your interpreter — see
aieng-ui/backend/MCP_SETUP.md.
- A running backend at
http://127.0.0.1:8000 enables live UI updates when an
agent drives a build; if it is down, the MCP server falls back to in-process
execution.
