Can AI move past querying Revit models and start actually building inside them? Chun-Lin Peng, Associate AIA and architectural designer at Leuterio Thomas Architects & Engineers, tests Claude + MCP + pyRevit to find out
Ask most architectural firms what “AI in Revit” means right now and you’ll get some version of: faster tags, cleaner schedules, maybe a chatbot that explains what a parameter does. This is useful but also falls short of what the phrase truly promises. I wanted to test the promise directly and explore whether AI can actually write to a model, not just read it.
What follows isn’t a success story. It’s a record of what that chain got right (ceilings, walls, windows, creating worksets), what it got wrong (stair dimensioning, a rebuild of Mies van der Rohe’s Farnsworth House that’s recognisable but not usable), and what the gap between those two tells us about where this is actually headed. I started where most people testing AI in Revit start: with what Autodesk ships. Revit 2027’s built-in Autodesk Assistant is fine for a narrow band of tasks — creating schedules, tagging rooms, doors, windows. But it can’t touch anything that already exists in the model.
In my testing, it couldn’t even rename a schedule it had just created. The official MCP server extension tells nearly the same story: it’s good for querying model information and pulling it into an LLM like Claude to reorganise or re-present, but it’s read-only against the model itself — it can reformat data, but it builds nothing.
That’s the comparison that actually matters here: both official routes save time on schedules and tags, but neither touch actual geometry. For real project work, that’s a small dent, not a shift. The useful version of AI in our field is one that actually produces the model — walls, ceilings, stairs, complex parameter chains — through natural language, at a level that can become deliverables. That’s what pushed me to look for another route: an open-source toolchain combining Claude, MCP (Model Context Protocol), and pyRevit.
The setup
The chain has three parts, each doing a distinct job. Claude is the reasoning engine — it works through what needs to happen in plain conversation. MCP is the standardised layer that lets Claude call external tools. pyRevit is the execution environment that sits inside Revit and calls the native Revit API directly. Put together: a prompt goes to Claude, Claude goes through MCP, MCP hands off to pyRevit, and pyRevit executes against the Revit API to produce the model output.
The idea for this chain came from two demos I came across on YouTube: “Revit + Claude AI Connector with NonicaTab” by BIM Pure, and “AI in Revit: Claude + MCP pyRevit 100% free” by BIM Coder — which I then extended into the testing below.
The difference from the official tools is access level, not just capability: this route has full API access, not read-only. Anything a Python script or C# add-in can do to a model, Claude can now do dynamically through conversation.
Two things worth flagging about getting this running. First, I had Claude write its own connection guide — the setup documentation was partly self-generated, which tells you something about where the actual bar for entry sits. Second, some of the setup steps look like real programming, and they are, but once Claude has access to the working files it can carry out those steps itself. The barrier is lower than it looks, not non-existent.
The piece that matters longer-term is what Claude calls a “skill” — a reusable instruction set, trained once and reused identically in every future session. That’s the difference between a one-off experiment and something repeatable.
What works now
These run today from a plain-language instruction, no custom skill required: walls, windows, ceilings; new floor and wall types; filters, colour codes; creating worksets and assigning elements to the correct one; floor plans and reflected ceiling plans. Ceilings are the clearest case — “create the ceiling for each room at Level X” finishes fast and correctly, and across multiple rooms it’s faster than doing it by hand. This isn’t a demo. It’s real production time back on a task nobody particularly enjoys doing manually.
Stairs are the exception, and the reason why is the more interesting finding.
Where it struggles
I tested whether Claude could read 2D drawings and produce a model from them, using Mies van der Rohe’s Farnsworth House as the test case because it’s about as simple as a building gets — plans, elevations, and sections in, model out. The honest result: a lot needs correcting, but you can clearly tell it’s the Farnsworth House. That’s not deliverable, and I want to be direct about that. But it’s also genuinely notable that drawings-in, model-out works at all, on a first attempt, with no training specific to this building. Better source drawings should mean better output — I haven’t proven that yet, but it’s the obvious next test. For existing-building projects that rely on legacy record drawings, maturing this could eventually cut a lot of hours out of some of the least rewarding modelling work we do.
Stair dimensioning is a different kind of hard. Ceilings are one instruction; stairs are dense with parameters that all depend on each other — run direction, width, tread and riser dimensions, landing size, where the annotation actually lands on the sheet. Getting one of those right in isolation is easy. Getting all of them right together, matching how we actually document stairs, is not. What’s working is decomposing the task into smaller trained skills rather than one large instruction — and that decomposition, more than the stair output itself, is the actual finding. It’s the template for how the harder modelling tasks get trained going forward.
I’m currently benchmarking time and token cost against manual modelling for the same tasks. That work is still in progress, so I don’t have numbers to report here — but it’s the next thing I want on the record, because “real time savings” needs a figure behind it eventually, not just my impression of it.
The strategic takeaway
Even with everything here still unfinished, it already reduces modelling time on the simple repetitive layer — and the ceiling on what it could eventually do is considerably higher than what the official tools are aiming at.
Where this fits in the wider landscape
I did a scan of what else exists in this space before deciding pyRevit was the right route. The commercial AI extensions built for Revit right now are mostly aimed at framing and refining documentation — helping write specs, clean up sheet notes, that kind of thing — not direct modelling. There’s also a growing open-source scene doing similar Claude-to-BIM connections, which suggests this isn’t a one-off approach so much as an early, still-forming category. Worth watching rather than treating as settled.
Where this goes next
The next test, and probably the highest-value one, is families — whether this can build usable families from shop drawings, or add parameters that make existing families more flexible. I also want to finish the stair-dimensioning skill chain end-to-end and eventually get this working without needing Claude in the loop at all: package what actually works into tools that make Revit easier to work in directly, rather than staying dependent on me personally training and retraining the same skills.
That still doesn’t settle the more important question, though: if AI ends up doing a real share of modelling work, does architecture converge — everyone drawing on the same trained patterns, the same skills, the same defaults — or diverge, because the hours that used to go into repetitive modelling get spent on design instead? I don’t have an answer. I’m not sure the industry does yet either. But it’s the question worth asking now, while tools like this are still rough enough that the answer isn’t locked in.
