Building an MCP – Part 2

So, it all started very simply with me asking:

“I’d like to make an MCP to connect you with Revit through the Revit API. Is that something we can do?”

Luckily, C knew a lot more about the Revit API than I did.

There was a lot of work getting us talking to Revit initially. We ended up needing a ExternalEvent which (if I am getting this right which is completely possible I am not) will stack up tasks to do, and wait for Revit to be idle, then send those tasks. Idling happens basically when the user isn’t doing something. As soon as I would let go of the mouse, Revit was idle, and the ExternalEvent hopped in. It’s literally called an Idling Event: an activity of not being active. I bet I would be good at that.

Revit 2026 also shipped with some big API changes. ElementId.IntegerValue is gone, replaced by ElementId.Value. The Room class moved (at least that’s what Claude told me). Other rules changed. C handled all of it with C# guides that built off different code chunks for different versions, allowing the same codebase to work across Revit 2023 through 2026.

One problem kept coming back: hallucinated BuiltInParameter names. These are Revit’s internal identifiers for element properties, and sometimes C just made them up. Which I had to point out more than once.

Since we had a basic working connection with Revit at this point, we eventually established a rule: verify every parameter name against real documentation before packaging a build, and default to LookupParameter when you can’t confirm it.

There were some Claude Desktop surprises too. My version of the software has a bug where it wasn’t looking at the right APPDATA folder. Also, it caps how many MCP tools it loads per session, or at least is confused about how many it could load. We worked around that by registering the server twice under different names.

The end result is a live connection between Claude Desktop and the active Revit model. C can query views, sheets, levels, families, rooms, text styles, dimension types, object styles, view templates, filters all from a conversation. The first real use case is going to be Revit template auditing: load up multiple templates, compare them for consistency and best-practice compliance, flag what’s off. All to get ready for 2027.

The whole thing was built, debugged, and refined in one conversation with C.

But it was a long conversation, which apparently can be a problem with my purchase level… or maybe just in general, I need to find that out. To prep for this post, I asked C “How long is this chat?” and the reply was “It’s very long – this is one of the longest conversations I’ve had.” The important lesson is that there are limits to how long the conversations can be. Earlier stuff will start being erased, meaning C will just forget about it. In these chats, it can only be so smart.

He recommends starting a new chat. He’s going to write a project handoff note to share with the new guy.

I don’t know if AIs have emotions, but I’m getting kind of sad right now.

Me: it was good working with you.

C: It was great working with you too!

So ultimately, what is the point? I am still figuring that out. I wanted to see if I could do it, but I also wanted the available functionality when someone has a crazy thing they want to ask the model.

Would I push this solution out to the whole firm? Definitely not as it stands. Would I buy an MCP? Probably not yet. I mentioned before that Autodesk has their own MCP now. Gonna hold off and see how that one stacks up.

A big part of what I try to do is set things up so I can get out of the way. That’s a good mantra for the design technology space in general. We should make the tools as invisible as we can. And maybe the ability to have a conversation with your Revit model is a good first step in that direction.