mcp-servers-for-revit: connecting Claude and Cline to Autodesk Revit

What mcp-servers-for-revit actually solves

Revit exposes a large .NET API, and reaching it normally means writing and deploying an add-in. mcp-servers-for-revit skips that step by putting a Model Context Protocol server in front of Revit, so an AI client can call named tools instead of generating C# against the API from scratch. The README frames the goal directly: it "enables AI clients like Claude, Cline, and other MCP-compatible tools to read, create, modify, and delete elements in Revit projects."

The audience is narrow and specific. You need Windows, a licensed Revit installation between 2020 and 2026, and an MCP-capable client. This is not a library you import into a web service. It is a bridge that only exists while Revit is open, because the plugin runs inside the Revit process and the command set executes against the live document. If your work is batch processing of .rvt files on a server, this project is the wrong shape.

The fork adds tools and functionality improvements over the original revit-mcp, per the README note. The tool table is where that shows up: query tools such as get_current_view_elements, get_material_quantities and analyze_model_statistics sit alongside creation tools for point, line and surface based elements, plus annotation tools like tag_all_walls and create_dimensions.

The three-process chain from AI client to Revit API

The README's architecture diagram lays out four boxes and three hops. The MCP client speaks stdio to the TypeScript server in server/. That server translates tool calls into WebSocket messages. The C# plugin in plugin/ listens on the WebSocket, dispatches to the command set in commandset/, and the command set performs the Revit API operations. Results travel back up the same chain.

The split matters for debugging. A tool call that never reaches Revit is a server or client configuration problem. A call that arrives but fails is a command set problem, and the failure surfaces inside Revit rather than in the AI client's transcript. The README does not document a log location or an error channel for the WebSocket hop, so expect to diagnose the middle of the chain by observation.

The command set is loaded by the plugin rather than compiled into it, which is why the release layout nests Commands/RevitMCPCommandSet/ underneath revit_mcp_plugin/ with a command.json at the top of that folder and a per-year subfolder holding the DLL. That structure lets one plugin build carry command sets for different Revit versions.

Installing from a release ZIP and connecting Claude Desktop

The documented path is the release ZIP, not a build from source. Download the archive matching your Revit version, for example mcp-servers-for-revit-v1.0.0-Revit2025.zip, and extract it into your Revit addins folder:

%AppData%\Autodesk\Revit\Addins\<your Revit version>\

After copying, the README says you should see mcp-servers-for-revit.addin next to a revit_mcp_plugin/ folder containing RevitMCPPlugin.dll and Commands/RevitMCPCommandSet/ with command.json and a versioned DLL folder. Start Revit, and if it warns about an unknown add-in, click Always Load. Then open the mcp-servers-for-revit ribbon tab, click Settings, enable the commands you want, and click Save. That Settings step is the real gate: nothing the AI client can call works until the corresponding command is enabled there.

On the client side, the server is published to npm and runs through npx. For Claude Code, the README gives this terminal command:

claude mcp add mcp-server-for-revit -- cmd /c npx -y mcp-server-for-revit

For Claude Desktop, edit claude_desktop_config.json through Settings, Developer, Edit Config:

{
    "mcpServers": {
        "mcp-server-for-revit": {
            "command": "cmd",
            "args": ["/c", "npx", "-y", "mcp-server-for-revit"]
        }
    }
}

Restart Claude Desktop. The README says the hammer icon appearing means the MCP server is connected. For a first check that the whole chain is live, call say_hello, which the tool table describes as displaying a greeting dialog in Revit. If that dialog appears, the stdio hop, the WebSocket hop and the command set are all working, and you can move on to a read-only call such as get_current_view_info before enabling anything that writes.

send_code_to_revit and the limits of the tool list

One entry in the tool table stands apart: send_code_to_revit, described as sending C# code to Revit to execute. Every other tool is a bounded operation with a named intent. This one is an open channel from the language model into the Revit process, and the README does not describe a sandbox, a review step, a confirmation prompt or an allowlist around it. If you enable it, the model's output runs with the same privileges as the add-in.

That is the honest failure mode of this project. The Settings dialog lets you enable commands individually, which is the only documented control surface, so the responsible configuration is to leave send_code_to_revit disabled unless you have a specific reason and a way to inspect what is being sent. The same caution applies to delete_element and the creation tools, which modify the live document. The README does not document rollback, undo behaviour, or a dry-run mode for any tool, so an unwanted change is something you reverse in Revit itself.

There is also a platform boundary. The plugin is a C# add-in for Windows Revit, and the test notes state that the -r win-x64 flag is required on ARM64 machines because the Revit API assemblies are x64-only. Nothing here runs on macOS or in a browser.

How it compares to writing a Revit add-in directly

The conventional alternative is the Revit API itself: write an IExternalCommand or IExternalApplication in C#, build against the Revit API assemblies, and ship your own add-in. That path gives you full control over transaction handling, error reporting and UI, and it does not depend on an AI client being correct about which tool to call. It also means every new capability is a new build and a new deployment to each machine.

mcp-servers-for-revit trades that control for reach. A model can compose calls across the existing tool set, for example reading get_selected_elements and then applying operate_element or color_elements to the same set, without anyone compiling anything. The cost is that you inherit the tool set's granularity. If your operation is not close to one of the listed tools, you are back to send_code_to_revit, which is the direct-API path with less structure around it.

The other comparison worth naming is the upstream revit-mcp project this repository forks. The README describes the fork as adding tools and functionality improvements, and the release history shows v1.0.0 published on 2026-02-26. If a tool you need is missing here, checking whether upstream has it, or vice versa, is a reasonable first move before writing C#.

Maintenance, licensing and the cost of upgrading Revit

The repository is not archived, and the last push was on 2026-04-05, which is roughly five months before today. That is recent enough that the project is not abandoned, but the README does not describe a release cadence or a support commitment, so treat version-to-version movement as something to check rather than assume.

The upgrade cost is structural. The release layout is versioned by Revit year: the add-in folder path includes the Revit version, the command set sits under a per-year subfolder such as 2025/, and the test configurations are split into Debug.R26 and Debug.R25. Moving to a new Revit release means a build of the command set for that year, not a config change. The README states support for Revit 2020 through 2026, and the release page is where you confirm a ZIP exists for your version rather than assuming it.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is a summary of the licence text, not legal advice; read the LICENSE file in the repository and your own organisation's policy before shipping a modified build.

Building from source has its own prerequisites. The test project uses Nice3point.TUnit.Revit and requires the .NET 10 SDK, installed via winget install Microsoft.DotNet.SDK.10, plus a licensed Revit 2026 or 2025 on the machine. Tests run against a live Revit instance with no separate add-in installation, because the framework injects into the running process.

Editorial conclusion

Adopt it if you already run Revit 2020 to 2026 on Windows and want an MCP client to query levels, rooms, materials and selected elements without writing a Revit add-in yourself. Do not adopt it if you need a documented rollback path for destructive calls, cross-platform support, or a guarantee that send_code_to_revit is safe to expose to an autonomous agent. Before you install, verify that your Revit version has a matching ZIP on the Releases page, that Node.js is at 18 or higher, and that the command list in the Settings dialog contains only the tools you intend the model to call.

Frequently asked questions

Official sources

1. License: MIT
2. mcp-servers-for-revit/mcp-servers-for-revit on GitHub
3. Project website
4. README
5. Releases