AgentCAD Turns Claude Code Into a Parametric CAD Operator — With JSON Where the Vibes Usually Go

AI CAD keeps getting marketed as if the hard part is turning a sentence into a shape. AgentCAD is interesting because it refuses that premise. The hard part is not convincing a model to emit a cube with a fillet; any decent coding agent can write plausible Python for that. The hard part is making the loop produce evidence: geometry that exports, metrics that can be checked, previews that can be inspected, and revisions that can be compared without treating a screenshot as ground truth.

That is why this tiny launch matters more than its current traction suggests. AgentCAD is a new open-source CLI and MCP server from James Dillard that lets Claude Code, Cursor, Windsurf, or another coding agent create 3D models by writing CadQuery or build123d scripts. The repository was created on June 2, 2026, had 2 stars and 0 forks during research, and the PyPI package agentcad reached version 0.2.4 on June 2 with support for Python >=3.10,<3.13. This is not a breakout adoption story. It is a pattern story.

The pattern is simple: stop asking the agent to be magical, and give it a real instrument panel.

The useful part is the harness, not the prompt

AgentCAD’s README positions the package as a “CLI CAD tool for AI agents” that writes CadQuery scripts and returns STEP files, renders, and metrics. That sentence hides the important architecture. A model can generate a script; AgentCAD runs it, exports versioned STEP files, creates PNG renders, can produce STL, GLB, and OBJ meshes, and reports geometric metrics such as volume, dimensions, validity, face counts, and edge counts. It also supports browser preview and visual verification options including four-view PNGs, turntable GIFs, and higher-quality rendered views.

Those details are not decorative. In CAD, “the model said it built the part” is worthless unless the resulting solid is valid, inspectable, and portable. STEP export matters because it moves the artifact into the actual CAD/manufacturing ecosystem. STL and OBJ matter because mesh workflows are still where a lot of prototyping and visualization land. Face and edge counts matter because they give the agent a cheap way to notice when an apparently small change exploded the topology. Bounding dimensions matter because “make this bracket 40 mm wide” is not a vibe.

The project’s dependency list tells the same story. Runtime dependencies include click>=8.0, cadquery>=2.0, and build123d>=0.9, with optional MCP support through mcp>=1.0.0. The test configuration runs both tests/ and tests_b3d/ with a 120-second per-test timeout, reportedly after prior regressions around build123d and wedged subprocess daemons. For a tiny project, that is the kind of unglamorous hygiene that suggests the author has actually fought the toolchain instead of just shipping a demo video.

The MCP setup is intentionally boring: install agentcad[mcp], then add a local stdio server command to .mcp.json pointing at python -m agentcad.mcp. That puts the CAD loop directly inside Claude Code or any compatible agent runtime. The agent writes the script; the tool executes the script; the result comes back as files and structured output rather than a reassuring paragraph.

CAD exposes the lie in “agent generated” demos

CAD is a useful stress test for coding agents because there are many ways to be wrong while still looking superficially correct. A phone stand can render beautifully and still have the wrong angle, insufficient clearance, non-manifold geometry, bad tolerances, weak load paths, or features that cannot be manufactured without heroic support material. A fixture can be dimensionally valid and still fail because the holes are not where the mating part needs them. A bracket can export cleanly and still be structurally silly.

AgentCAD does not solve those engineering problems. That is the point. It gives the agent a better loop for the subset of correctness that software can cheaply verify: execution, geometry validity, exported artifacts, dimensions, topology metrics, and previews. It moves the task from “Claude, imagine a part” to “Claude, write parametric code, run it, inspect the metrics, revise it, and show me the artifact.” That is a smaller claim and a much more useful one.

This is also why the choice of CadQuery and build123d is pragmatic. Both are Python-based parametric CAD approaches, which means the model works in a language it already handles well and can express design intent as code. Parametric scripts are reviewable in a way that pure generated geometry is not. If the agent changes a hole diameter, a human can see the parameter. If it adds a fillet, a reviewer can inspect the operation. The code becomes the design history, not just the delivery mechanism.

For practitioners, the immediate use cases are not “replace mechanical engineering.” They are rapid concept iteration, enclosures, brackets, simple fixtures, adapter plates, desk accessories, and early visual exploration where a measurable, exportable artifact is better than a napkin sketch. If you are already comfortable with CadQuery or build123d, AgentCAD gives your coding agent a way to operate inside that environment. If you are not, the tool still lowers the cost of exploring parametric CAD, but it does not remove the need to review dimensions and manufacturing constraints.

Run it like executable code, because it is

The sharp edge is obvious: a local CAD MCP server executes Python that the agent wrote. That is powerful. It is also exactly the kind of thing teams should treat as a privileged tool, not an innocent plugin. Generated scripts should run in a project-scoped virtual environment. Secrets should not be mounted into the same shell. Outputs should live in versioned directories. If the agent proposes changing build configuration, import paths, or local environment settings to “make CAD work,” review that like any other execution-adjacent change.

The broader MCP lesson is that domain tools need explicit trust boundaries. AgentCAD’s output may be structured, but the inputs are still model-authored code. If you connect it to Claude Code, make the workflow boring: constrain the working directory, inspect generated scripts before using the artifacts, commit both the scripts and exported files when appropriate, and avoid letting the agent silently overwrite previous design iterations. In a professional mechanical workflow, add simulation, fit checks, material constraints, and human review before anything gets printed, machined, or deployed near a person.

The more interesting comparison is to other agent domains. For frontend work, the equivalent loop is screenshots, DOM diffs, accessibility checks, visual regression, and bundle-size deltas. For data engineering, it is row counts, schema diffs, freshness checks, and query plans. For infrastructure, it is plans, policy checks, drift detection, and rollbacks. AgentCAD’s core insight is transferable: domain-specific agent tools win when they make reality cheap to check.

That is where the “anti-vibes” framing lands. AgentCAD is not impressive because it promises AI-native CAD magic. It is impressive because it makes the boring parts first-class: run the script, export the model, render the views, compute the metrics, diff the revision, and hand the human something inspectable. The agent can still hallucinate. The difference is that now it has to hallucinate in front of a compiler, a geometry kernel, and a set of measurable artifacts.

For a project with almost no community traction yet, that is enough signal. The next wave of coding-agent tools will not be generic chat wrappers. They will be domain loops that turn “I did the thing” into evidence. AgentCAD is early, small, and probably rough around the edges. But the architecture is pointed in the right direction: verification before vibes, artifacts before assertions, and JSON where the demo usually puts jazz hands.

Sources: jdilla1277/agentcad, PyPI agentcad package metadata, HN Show HN item, Model Context Protocol docs, CadQuery docs, build123d docs