BrickForge: from AFOL to designer, with Claude as a partner I have to fact-check

I've been building LEGO for years: hundreds of sets, thousands of steps, a good feel for which techniques hold and which don't. But I've always built someone else's design. Now I want to design my own models, and I wanted Claude as a design partner from day one.

My building experience caught the first problem quickly: language models are very confident about LEGO parts that don't exist. A believable part number, a color the part was never made in, a piece that's almost right. Any AFOL would spot some of these. Others look right until you try to buy the part. So BrickForge became less about getting AI to design, and more about setting up a workflow where every claim gets checked.

Step one: a catalog that keeps Claude honest

BrickForge is a Claude project connected to an MCP server I built: a LEGO catalog over Rebrickable's public data. It has six read-only tools. They search parts, look up a single part, list colors, return a set's inventory, decode element IDs and report how old the data is. Every answer carries its source and snapshot date.

An early concept sheet named three parts. Checking them took seconds:

• Windscreen 2 x 10 x 3 (24607) exists in Trans-Clear, but appears in only 13 sets. It's valid, but it may be hard to source.
• Cone 2 x 2 x 2 (3942c) comes in 42 colors. It has never been made in Trans-Orange.
• Round plate 1 x 1 (6141) in Trans-Orange is common: it appears in 659 sets.

That set count is a cheap rarity signal. As a builder I know some parts are hard to find. Having a number for it before committing a design to the part is new.

What a catalog can't do

A catalog knows what exists, not how it fits together. It has no geometry, no connections and no physics. So I went looking for a design layer, and I had two specialist AI agents review the options, one focused on strategy and one on architecture. Each had to label every outside claim as either verified, with its source, or unverified.

They caught real problems:

• A community tool that lets Claude place bricks only rotates parts in 90° steps and only checks connections through top studs. It can't handle SNOT, which every serious model I've built depends on. Its directory listing didn't say so. The source code did.
• The LEGO Ideas terms, in the version reviewed, restrict AI-assisted submissions. My models are personal projects anyway, but it's worth knowing before you share a design.

Dropping the existing tools didn't mean a design layer was impossible. It meant I'd have to build one.

The missing piece: connection data

The hard part of a LEGO design tool is knowing how parts connect in any orientation: studs, anti-studs, side studs, clips, Technic holes. That data exists in the LDCad Shadow Library, a community project that adds connection points (position, direction, shape) to the LDraw parts library.

The architecture review measured it against real set inventories: 95.8% of the parts actually used in sets have connection data. Bricks, plates, tiles, brackets and side-stud bricks are covered at 96–100%. The gaps are wheels, large figures and Duplo, which a first version can live without.

The solution design

The key idea: Claude never does 3D math. It decides what connects to what ("this bracket's anti-stud onto that wall's stud"), and a server computes the position, checks the fit and rejects collisions. Language models are good at choosing. They're unreliable at rotation matrices.

• My PC
  • Claude Desktop (BrickForge)
  • ↓Then: calls tools
  • Design-layer MCP (new, local)
    • Toolsplace_part, attach_part, open_connectors, check_model, export_ldraw
    • EngineConnector matching, position and rotation solver (SNOT), collision check, floating-part detection, model state
    • DataLDraw part geometry + LDCad connection points
  • ↓Then: exports .mpd (one way)
  • BrickLink Studio
    • The master model, stability, instructions, renders
• ↓Then: asks "does this part exist in this color?"
• Cloud
  • Catalog MCP (Rebrickable)
    • Legality, rarity, sets

A typical exchange: I ask for a tiled panel mounted sideways on a wall. Claude asks the server which side studs are free, attaches a bracket to one, attaches the tiles to the bracket, and runs a check: nothing floating, nothing colliding. Then it exports a sub-assembly file I import into Studio, where I check stability.

Three choices I made deliberately:

• One master file. Studio's model is the source of truth. Claude's sub-assemblies flow into it, never back.
• Two servers, two jobs. The local server owns geometry and models. The hosted catalog owns "is this real LEGO?". Neither duplicates the other.
• Local, not cloud. Building a model means keeping state across many steps, and the part geometry alone is about 279 MB. It runs on my PC in Claude Desktop.

How I'll know it works

Nothing gets built on faith. The plan has phases, and each one has a test it must pass:

1. Validate the checker first, against known real connections, before Claude touches it. Otherwise I'd be grading Claude with an untested ruler.
2. Then test Claude on three small builds: a staggered wall, a sideways panel and an offset SNOT detail. Five runs each, scored against references I build by hand, and compared with Claude working without the tools. If the tools don't beat that baseline, I stop. The layer isn't earning its keep.
3. Only then add clips, hinges, Technic, and the legality check against the catalog.

What I've learned so far

• An MCP is a fact layer, not a designer. Its value is that it makes the AI's claims checkable.
• Read the code, not the listing. A tool's description says what it hopes to do. The code says what it actually checks.
• "Those tools don't fit" is not "it can't be done." Ask what the hard part is, then look for the data.
• Building experience is the real validator. AI speeds up the path to a model worth testing. My hands still decide whether it holds.

What's next

Phase 0: build the connection data and prove the checker. I'll write about whether Claude passes its test, including if it doesn't.

---

Data: Rebrickable. Connection data: LDCad Shadow Library (CC BY-SA 4.0). Part geometry: LDraw.org (CC BY). LEGO® is a trademark of the LEGO Group, which does not sponsor or endorse this project.