What the Model Context Protocol is, what a Revit MCP server would actually have to do, which workflows it would be useful for, and what it must never be allowed to do. BIMRACE has not built one — this page explains the architecture rather than selling it.
Read this first. BIMRACE does not have a working Model Context Protocol server for Revit. We have not shipped one, we do not operate one, and nothing on this page is a product you can buy or licence. Roadmap is the honest badge for the protocol layer and it is the badge it carries in our navigation.
What is real today is underneath it: automation and checking routines that have been Live on client appointments for years, and model data extraction and reasoning that is In development and used on our own delivery. This page describes how those would connect to an AI assistant through MCP, because it is a question worth answering properly in a market that is currently answering it loudly and badly.
What it is
The Model Context Protocol is an open standard for connecting AI assistants to external tools and data. A server exposes a set of typed tools and resources; a client discovers what is available and calls it. The protocol itself is unremarkable — which is the point.
What matters for engineering is the consequence of that structure: the complete set of things an assistant can do against your model is a finite, enumerable list that somebody wrote and somebody else can review. Compare that with the alternative currently being sold, which is an assistant with unspecified access and a reassuring paragraph about safety.
An engineering practice should be able to read the tool list, disagree with an entry, and have it removed. That is a governable interface. An integration you cannot enumerate is not.
In their own words, about a model they are accountable for.
From an enumerable list, not from unspecified access.
Into Revit's API context, inside a read-only boundary.
Elements, parameters, systems, relationships — with element IDs.
Nothing is committed to the model by anything above this line.
The hard part
Most published enthusiasm about AI and Revit skips this section. It is the section that determines whether any of it works on a real project.
Use cases
Ordered by how close each one is to being real. The badge on each is the status of the underlying capability at BIMRACE, not of the MCP layer — that remains Roadmap throughout.
01
Element counts by system, parameter completeness by family, where a given type is used, which elements are missing a required value. Today this is a script somebody has to write for each question. The value of a declared tool interface is that the question no longer needs a script.
02
Asking why a QA run produced a finding, which rule fired, and what else shares the same root cause. The rule sets and the findings are live today; what is missing is the conversational route into them.
03
Which findings belong to which discipline, what changed since the last federation, which issues recurred. The coordination data exists; querying it in plain language does not.
04
Quantities by system, by level, by classification, with the measurement rule and the element list behind each line. Automated extraction is live; asking for a cut of it is not.
05
Drafting the repetitive parts of a report, a schedule note or an issue description from model state, for an engineer to correct rather than to write from nothing.
06
Answering "how is this model organised" for someone who has just inherited it — worksets, naming, parameter schema, system structure, where the conventions have been broken. Not built, and arguably the most valuable of the six.
The read boundary is the design. Every use case above is a read. That is not a phase-one limitation with write access scheduled for phase two — it is the boundary we would build to and stay behind.
A routine that silently edits a live model removes the one thing that makes an engineering deliverable worth anything: a person who is answerable for it. Automation here drafts, proposes and reports. It does not commit.
Where an engineer signs. The review step is not a checkbox at the end. It is the point at which a named person takes responsibility for an output, and it is why the architecture keeps every AI-produced artefact in a reviewable state rather than in the model.
What it must never do
Every item on that list is currently being done somewhere in this sector, usually in a demonstration video, usually with the reviewing engineer edited out.
Security
These are not rhetorical. They are the questions that decide whether an AI integration is adoptable by a practice with NDAs and professional indemnity, and most current offerings answer them badly or not at all.
Where we actually are
If you find a claim on this page that we cannot support at enquiry stage, that is a defect and we want to hear about it. The four-state legend behind every badge is published at capability status.
FAQ
Including the one about whether this is real, which is answered first.
No. This is marked roadmap on this page and in the platform navigation, and nothing on this page should be read as a released integration. What exists today is model data extraction and reasoning, which is in development and used on our own delivery, and the automation and checking routines that have been live on client appointments for years. The protocol layer between them and an AI assistant is not built.
An open protocol for connecting AI assistants to external tools and data. A server exposes a set of typed tools and resources; a client — an AI assistant — discovers them and calls them. The value is that the interface is declared and enumerable rather than improvised, which means the set of things an assistant is able to do against a system is a finite list somebody wrote down and can review.
Because the Revit API is not a service. Calls have to run on Revit's main thread inside a valid API context, model changes require transactions, and Revit is not designed to run headless for interactive documents. An MCP server cannot simply call the API from a request handler — it has to marshal every call into Revit's execution context and hand the result back. That is an engineering problem with known solutions, but it is the reason a Revit MCP integration is more than a wrapper.
Not in anything we would build. The read boundary is the design: query, extract, report and draft. Write operations against a live model would remain behind the same constraint as every other automation on this site — a named engineer accepts, amends or rejects, and nothing commits without that. This is not a technical limitation we expect to remove later. It is the thing that makes an engineering deliverable worth anything.
That is the question to ask any vendor proposing this, and the answer determines whether it is adoptable at all. A model contains commercially sensitive design information and frequently sits under an NDA that predates anyone's AI strategy. Any architecture we would propose has to be explicit about what leaves the machine, what is retained, and by whom — before it is interesting rather than after.
Yes, and it is a more useful conversation than a demonstration would be. We can show the extraction and checking work that is real today, describe honestly where the protocol layer would sit, and tell you which parts of what you have read elsewhere are further away than they are being presented as.
Related
Engineering enquiry
We will show the extraction and checking work that is real today, describe honestly where the protocol layer would sit, and tell you which of the claims you have read elsewhere are further away than they are being presented as.