I onboarded Claude as a Revit family creator

What I learned trying to teach an AI to build Revit families. 

I've been building Revit families since 2008. I run the team at Fetch that does this for a living. I’ve built up a decade of conventions about naming, parameters, nesting, and what "production-ready" actually means. During this time I followed a path that many will find familiar. I started with Revit and was immediately enamored with everything it can do, only to be quickly annoyed with everything it couldn’t. This pattern would repeat itself over and over. I picked up Dynamo, then pyRevit and Python, then C# for the plugin work. All of these extended what was possible but eventually you would hit the wall. Then AI showed up and promised to be the bridge. But a promise isn't a workflow. The question, especially in construction, is how to actually make it useful.

AI has been mainstream for a few years, but the AEC industry has been slow to make practical use of it. Autodesk has pushed generative design, but adoption has mostly stayed in rendering and visualization. The production workflows, where families and parameters and constraints live, haven't moved much. Then Anthropic shipped an official Claude integration for Fusion. Then a Blender one. Autodesk released Assistant for Revit and added its own MCP server, but the family editor is largely outside its reach. If you wanted to test agent-driven work where families actually get made, you built your own.

Earlier this year, Michael Kilkelly had taken a first run at it. He published I Gave Claude a Photo and It Built a Revit Family, which was the first time I'd seen someone use AI to try and do my job. Claude could read an image and produce a working Revit family. There were issues, but the most telling one was that the end product was static. No parameters, no flexing. The question I came away with was the next one. What would it take to cross the gap from a static demo to a family I'd actually ship out of Fetch?

My thesis was that I would need the AI to work more like a human. Instead of one-shotting the geometry I needed the AI to follow the normal family creation process.

1. Research the product
   • What are the sizes it comes in?
   • What material is it made of?
   • What are the important options?
   • What geometry should be nested families?
   • Determine necessary parameters
   • Determine correct family category
2. Create the scaffold with reference planes
   • Use existing reference planes in the family template and add new ones where needed
   • Connect reference planes with dimensions
   • Associate dimensions with parameters
   • Flex the parameters to ensure frame worked
3. Layer on geometry
   • Determine the correct tool for creating geometry (extrusion, blend, sweep, etc)
   • Lock solids to reference planes
   • Make sure geometry still flexed correctly
4. Add nested families
   • Repeat the same process for nested families
   • Constrain nested families to reference planes in the parent family

So I built it. With the help of Claude Code I wrote an MCP server inside Revit. I wrote a skill file as if I were onboarding a Junior content creator on my team. Then I gave the AI the same brief I'd give a new hire, a one-page cut sheet of a product. Build the family.

What happened next surprised me. Not because the AI did things I couldn't, but because the work of getting it there looked uncomfortably like the work of training a person.

MCP and the training problem

Kilkelly's process used a schema pipeline, where Claude creates a structured JSON contract describing the family and a plugin executes it inside Revit. That let him recreate and test the family on the web. I wanted to go a different direction. I needed the LLM to have direct access so I could iterate faster, and because I needed it to understand context. Revit has a lot of quirks you wouldn't catch without context. Ever noticed that casework family thumbnails appear flipped in Revit? That's because the casework family template has its Y direction reversed. The direction you draw reference planes determines its relative coordinates. Using a JSON pipeline, the agent would never see that issue. An agent on MCP can watch what happens, read the structured response, diagnose the failure, and patch.

Example of backwards facing casework thumbnail in Revit

MCP, the Model Context Protocol, is a way of giving the AI context. The agent makes a request, the tool runs in your environment, the agent reads the structured response and decides what to do next. For Revit, each tool is a wrapper around a Family API call. If I want the Agent to be able to make an extrusion I build a tool for it to access. I created an initial set with actions like create_reference_plane, create_extrusion, place_family_instance, flex_parameter.

I built a Family Editor focused MCP that connects through my plugin

Three reasons I chose to make an MCP server

1. The workflow is iterative. Since the Agent has direct access to Revit it can help me diagnose issues we run into, create a fix, and then run the test again.
2. The tool surface evolves. I started with 14 tools. Now I'm at 24. Every time the agent got surprised, I added a new tool or a parameter to surface what it needed to see. It’s very easy to layer on new tools as they become needed.
3. The plugin already had the scaffolding. IExternalEventHandler patterns for marshaling work onto Revit's main thread. MCP slotted in.

But MCP is just the plumbing. The interesting part, and the thing that took the longest, was the skill file.

A skill is a Markdown document the agent reads when you want it to perform specific tasks. It's the equivalent of the onboarding doc you write for a Junior content creator who'll start tomorrow. I didn't realize how much I was writing it like an onboarding doc until about the fourth iteration. Every time the agent missed something, like building panels that physically intersected, or picking the wrong template, or when to use a sweep instead of an extrusion, I added a new section to the SKILL.md file. Every gotcha became a rule. Every failure became a documented pattern. By the end it was over 800 lines.

Reading it back, I realized I'd spent a majority of my time writing down things I'd known for fifteen years and had never put on paper. The skill wasn't documentation for the agent. It was documentation of how a human family-creator approaches the work. That, more than the server, was the project.

Round 1. The picnic table

This was the proof of concept. I wasn’t worried about accuracy or visual fidelity. I didn’t even supply an image to the agent. I just wanted to know if I could build a parametric version of a family that actually flexed. I also wanted to know if I could handle different modeling techniques.

How does a content creator approach a new family? Chassis first. Build the entire constraint graph before any geometry. Reference planes, parameters, dimensions, formulas, in that order. Then flex every parameter through its full range with the chassis empty. No geometry yet. Just constraints. The chassis is flexed and tested. Only then add geometry, sketch-locked to the chassis.

I picked a picnic table for the first test because it is what Kilkelly showed in his demonstration. His pipeline produced rectangular approximations using extrusions. I wanted to know if our setup could do real blends.

Much to my surprise, it accomplished my goal fairly easily. While there were certainly plenty of issues with the family, It was able to create the necessary parameters, add the reference planes in multiple views/directions, add the parameters as dimensions, and then build the geometry. The thing the schema-based pipeline couldn't do, the agent-with-skill could.

What is even more interesting was the iterative process. In the first iteration we ran into an error trying to lock the legs to a reference plane. The agent was trying to constrain the leg to the wrong reference plane. It did not understand the context. I updated the MCP server with a tool that allowed the agent to understand the reference plane locations and updated the skill that explained how to use the tool when constraining geometry. With this new update the rebuild succeeded.

That's the loop a schema can't run. Structured failure, then diagnosis from the actual error text, then patch, then re-issue. The agent didn't do anything clever. It just read what the tool returned and reacted, the way a person would.

Round 1 wasn't about whether the AI could build a picnic table. It was about whether the AI could work like a human creator if I told it how. The answer was yes, but only if I explained much of the nuance. Which meant the next move was finding out what else a human knows that I hadn't told it yet.

Round 2. The cabinet, v1 to v3

The picnic table was a proof of concept. A 2-door base cabinet, something I have personally built dozens of variations of, was the real test. I fed the cut sheet to a fresh conversation and watched what happened.

It took three versions to land somewhere usable. v1 came back oriented backwards because the agent was flying blind on the coordinate system. v2 had the coordinate system right but the geometry physically intersected. The shelf ran straight through the back panel, since the agent had no mental model of stacked construction. v3 stacked correctly. Nine extrusions, all face-locked, Width and Depth and Height flexing cleanly.

Each version revealed another piece of mental scaffolding I'd never written down. Coordinate system literacy. The simple idea that two parts cannot occupy the same space. Each became a section in the skill, with worked examples and category-specific illustrations.

By v3 the cabinet was something a Junior content creator on my team might produce after a day or two of mentoring. But the wire pulls were still inline geometry, the lazy way. Real Fetch cabinet families nest their hardware. Separate .rfa files, loaded into the parent, placed with parameter bindings and position locks so the pulls ride up the door as the cabinet flexes. One pull family, forty cabinet variants. That is the DRY pattern the senior team expects to see. If the agent couldn't do that, none of the rest mattered for production work.

Round 3. Nesting and the from-scratch test

Adding the nested family workflow required a lot of tool building. I needed the Agent to be able to create new families from templates, save families, load families into other families, and more.

Adding a create_sweep tool might have been the most difficult of all. Sweeps are surprisingly difficult to explain to an LLM. The agent needs to understand profiles, sketch planes, the path, and how they all work together. I had several issues with the agent not creating the sketch in the correct plane. However, the agent helped to create a diagnostic tool to test and eventually solve the issue.

The cut sheet I gave the agent in order to build the family

Once I had everything working I wanted to run a test from scratch. I started a fresh conversation, attached the cut sheet, and asked it to create a family. Similar to what I would do with one of my content creators.

The process took about twenty minutes and required around 80 tool calls.

The agent read the cut sheet. After researching the product it asked me clarifying questions on items like the toe kick recess and back panel thickness. Next it picked Casework.rft as the template, which was the right call. Built the cabinet chassis, with 12 parameters, 12 reference planes, 16 labeled dimensions, and 5 panels (sides, back, toekick, two doors). Then it flexed the family again after the geometry had been added. After that was successful it opened a new family from Generic Model.rft, built the wire pull as its own family, and saved it. Switched back to the parent, loaded the pull, placed two instances on the doors with parameter bindings AND position locks.

A Junior content creator on my team would have spent half a day on the same task. The agent was faster, no question. But it needed three corrections along the way, and a Junior would have made fewer mistakes the first time through.

Three substantive corrections during the run.

1. The agent tried to label an EQ dimension with a parameter (which over-constrains), Revit raised a dialog, and I clicked cancel manually.
2. The handles were in the wrong orientation. I prompted the agent to make them vertical. It didn’t have a tool to rotate the nested family so it opened up the pull family and re-drew it in the vertical orientation.
3. The pulls were then loaded into the parent family but constrained to the wrong reference plane. I prompted again with the position and it was quickly fixed.

The dialog is a good example of the cat-and-mouse. The agent didn't know Revit had raised a dialog because I hadn't given it access to the IFailuresPreprocessor or Warning events. I could have. That would have let the agent see the error itself and try a different approach. Every limit I ran into in this experiment looked like this. Not a fundamental wall, just a piece of plumbing I hadn't gotten to yet.

How could this change my job

I'm a family creator. I run a team of family creators. Take what follows with that lens.

What I think it could help with today

The agent performs at Junior content creator level today for a chunk of family work.

• Family audits
  • flex test the family
  • make sure you have the proper named references
  • check naming to make sure it matches your internal conventions.
• Parameter management
  • adding, renaming, and migrating across an entire library
• Enriching data from outside sources
• Building simple parametric families built from a clean cut sheet

Where it falls short

• There is an accuracy tradeoff. Even with amazing context there will be visual differences in what you showed it vs what it modeled. It’s also not deterministic so you might get something slightly different each time.
• The more complicated the family the more “training” it requires. I spent a few days creating the MCP tools and SKILL.md file. I imagine you would find a another 2 or 3 things each time you made a new family you needed to add.

Other considerations

• MCPs are not known for their efficiency. I ran this on Claude Code on a Premium Team plan, and the from-scratch test used twenty-one percent of the model's context window. Plenty of headroom for harder problems, but that could quickly run out with larger initial context or more complex families.

• The skill file is over 800 lines today, and I don't know whether there's a wall when it comes to adding to it, or whether performance starts to degrade past some tipping point between input and output.
• This approach is not a magic-button workflow. It requires human input. You have to answer questions, give guidance, and click cancel when Revit raises a dialog the agent can't see.

A list of what I didn't pursue yet

• Materials assignment
• Void cuts
• Type catalogs and multi-type families
• Hosted families, both face-based and wall-based
• Shared parameter file integration
• More complex geometry
• Levels of detail
• 2D annotations

Each is a known gap with a clear shape of fix. If I choose to continue pushing this boulder up the hill, these are what I would address next.

My final thoughts

This was an interesting experiment. What surprised me most was the speed. Getting the chassis built and flexing, with reference planes, parameters, dimensions, and formulas all working together, happened faster than I would have predicted.

After that, the returns got smaller. Each new family type surfaced two or three new things to add to the skill or another tool to build. That's the cat-and-mouse. The work is in the iteration, not the breakthrough, and I'm not sure that game ever ends.

I'm not going to claim this is going to take over my job or anyone else's. The "what I think it could help with today" list is short and concrete. The "where it falls short" list is honest. Both will probably keep moving as the tools and the skill evolve. But I don't see a near-term path where this replaces a content creator. I see one where it makes parts of the work go faster. Sometimes. With caveats.

If you're an AEC firm thinking about doing this for yourself, the order matters. The MCP plumbing is easy to set up with Claude code but you will need to use a plugin. The Claude skill requires content creators or BIM managers that know the ins and outs of the Revit family editor.

We're not publishing ours. It encodes a decade of Fetch conventions and we'd like to keep that to ourselves for now. But if you're a firm thinking about how to start, the part that matters is figuring out who in your organization holds the institutional knowledge that should go into it. Then giving them the time to write it down.

If that sounds like something you want to talk through, reach out. Happy to compare notes.