Revit MCP in production: what an AI agent may read, write and undo
Zakhar Vityk, CEO, Consedge Tech
In 2026 the Model Context Protocol went from an experiment to something Autodesk ships. An AI assistant can now query a live Revit model, and with the right server it can change one.
That moves the question for BIM managers and software vendors. It is no longer "can an agent talk to Revit?" It is "what should it be allowed to do, and what has to be true around it?" This guide covers where the Revit MCP server stands today and what production use requires.
Where things stand
Autodesk's Revit Public MCP Server is a technical preview. It runs locally, talks to AI clients such as Claude Desktop or Cursor, and requires Revit 2027.2. Since that update it comes in three configurations.
| Server | What it adds | Changes the model |
|---|---|---|
| Read | 8 tools: query elements, read parameters, select, zoom, open and export views | No |
| Write | Read tools plus 3: change parameters or types, move, rotate | Yes |
| Experimental | All of the above plus 28 more: views, sheets, schedules, tags, graphic overrides, IFC and gbXML export, delete | Yes |
Autodesk's own tool reference is candid about the status. Tools may change before general availability. Proposed changes should be reviewed before they are accepted. A backup is advised before any write operation.
Community MCP servers for Revit existed earlier and cover older versions and wider toolsets. They vary a great deal in how carefully they handle writes.
Read is the easy win
Read access pays off quickly and risks little:
- model audits: rooms without numbers, elements missing a parameter, views not on sheets,
- counts and breakdowns for a report,
- answers for people who do not know where to look in Revit.
Three cautions still apply. Check an agent's counts against a schedule before you trust them. Large models produce large answers, which cost time and tokens. And the server may be local, but what the AI client sends to its provider depends on that client. Agree a data policy with IT first.
Write is a different product
Once an agent can change a model, five things must be true. They hold for Autodesk's server, a community server and one you build yourself.
- Preview. The user sees what will change, element by element, old value and new, before anything is applied.
- Confirmation. A person approves each batch. Deletion always asks.
- One Undo entry. A request becomes one named transaction. If part of it fails, all of it rolls back.
- Limits. Only the selection, the active view or a named workset. A ceiling on element count. A check on element ownership in workshared models.
- A log. Who asked, what was asked, which tools ran, which element IDs changed.
The agent proposes; a person approves; Revit records one transaction the user can undo.
Without these, the first bad prompt on a central model becomes a morning of recovery.
Notes for teams building their own MCP tools
Respect the threading model. The Revit API runs on one thread. An MCP server is a separate process, so every call has to cross into the add-in and wait in an external event queue.
Use one command queue for every entry point. Ribbon buttons, panels and MCP requests should pass through the same validation, the same transaction handling and the same log. A separate path for the agent is where rules get skipped.
Expose intentions, not the API. "Renumber rooms on this level by this rule" is a tool. "Run this code" is a liability. Coarse tools are easier to preview, test and explain.
Let rules decide and the model explain. Checks with exact answers belong in deterministic code. The agent chooses which check to run and explains the result. We describe that division in our article on AI assistants.
Treat model content as untrusted input. Parameter values, sheet notes and linked files are text an agent will read. A linked model from outside your firm can contain instructions. Never let an agent approve its own changes.
Test tools like commands. Each tool gets tests on reference models, as described in how to test a Revit add-in.
A rollout checklist for BIM managers
- Start with the Read server on a detached copy of a real project.
- Agree with IT which AI client is allowed and whether model data may leave the firm.
- Pick three audit questions and compare the answers with schedules.
- Pilot write tools on a non-production model, with a backup and a named group of users.
- Write the allowed uses into your BIM execution plan.
- Repeat the checks after each Revit update. Preview tools change.
How we approach it
In the plugin platform we are building for our own tools, requests from an AI agent go through the same command queue as ribbon commands and panels. Preview, confirmation and a single Undo entry apply to all three.
If you have an MCP prototype, or an AI feature inside a plugin, and want to know what it needs before real users touch it, request a Production Readiness Audit. The background is in what it takes to ship an AI-built Revit plugin, and the service is described on our AI engineering page.
FAQ
What is an MCP server for Revit?
A small program that lets an AI assistant call a defined set of tools in a running Revit session: query elements, read parameters and, depending on the server, change the model.
Which Revit version does Autodesk's MCP server need?
During the technical preview it is supported on Revit 2027.2 only.
Can an AI agent modify my Revit model?
Yes, with the Write or Experimental server, or with some community servers. Review every proposed change and keep a backup.
Does my model data leave my computer?
The server runs locally. The AI client then sends what it reads to its model provider, so the answer depends on the client and the plan you use.
Working on something like this?
Bring the prototype — yours, your vendor’s, or the one an AI tool generated — and we tell you exactly what it takes to ship it.
- First call free, no obligation
- Straight answers
- Fixed-price written verdict
- Senior engineers, not account managers