revit-tools: A Python MCP Server for Autodesk Revit 2027
An AxoWorks Technical Review
Classification: Product Review | Status: Code verified against repository | Roster current as of: August 20, 2026
revit-tools is a single-file, standard-library-only Python Model Context Protocol (MCP) server that connects an AI chat client to a running Autodesk Revit 2027 model — developed and tested for DeepSeek Harness (DSH), and architecturally portable to any stdio MCP client. It wraps Autodesk's official Revit MCP Server Read-Tools Technical Preview and adds eight deterministic audit tools on top.
- 15 tools total: 7 native Autodesk read tools + 8 audit tools (floor area, lot area, lot coverage, septic, energy, window-to-wall ratio, setback).
- Deterministic, not generative: every number is computed from model geometry by pure math. However, the quality of the audit output is strictly bound to how well-structured and modeled the Revit file is — Garbage In, Garbage Out (GIGO). If elements are miscategorized or boundaries are unclosed, the calculations will be precisely incorrect. The LLM chooses which tool to call; it never computes the answers.
- Read-only and fully local: nothing written to the model, no cloud, no API keys, no telemetry, zero
pipdependencies. - Honest about gaps: when data isn't in the model, the tool says “not in the model” instead of inventing a figure. Several audits are labeled placeholders because the Autodesk add-in doesn't export the geometry yet.
- Verdict: a credible QA/QC proof of concept for senior architects who want to ask the model questions — the custom audit tools have not been fully tested, it is not production-grade software, and the single-threaded add-in underneath can permanently deadlock if your agent retry-storms.
- Best for: senior architects and QC leads who know buildings but not the Revit schedule palette. Skip if: you need write access, linked-model queries, or energy-grade U-factor extraction.
What is revit-tools? (The 40-Word Answer)
revit-tools is an open-source (MIT) MCP server that bridges an AI assistant to a live Revit 2027 model — built for DeepSeek Harness (DSH), portable in principle to any stdio MCP client — letting you ask plain-English questions (“total floor area per level?”) and get deterministic, math-verified answers.
That's the definition. Now the review.
Architecture: One File Between You and a Named Pipe
The stack is admirably boring:
MCP client (DSH, Claude Desktop, etc.)
│
└─ stdio ──▶ axo_mcp_server.py (one file, Python stdlib only)
├─ child stdio ──▶ Autodesk.RevitMcpServer.Stdio.exe
│ └─ named pipe ──▶ MCP add-in inside Revit 2027
└─ adds the 8 axo_* audit tools (deterministic math)
Three design decisions stand out:
- Zero dependencies. Python standard library only. No
pip install, novenv, no.env, nopywin32. Deployment is a folder copy plus three path edits in one YAML file. - Instance auto-injection. The server detects the running Revit process ID and injects
revitInstanceIdinto every call — the agent never manages it by hand. (The barerevit-directroute doesn't do this; it's one of two reasons to accept the Python requirement.) - Serialization and timeouts. Every upstream call is queued and time-boxed (5-minute default budget), because of the add-in's fatal flaw — covered below.
The Tool Surface: 15 Tools, Two Trust Classes
| Class | Tools | Trust model |
|---|---|---|
| Native Autodesk pass-through | query_model, get_element_data, export_views, open_view, select_elements, zoom_to_elements, get_running_revit_instances |
LLM interprets structured JSON — standard tool-call risk |
| Axoworks deterministic audits | axo_audit_floor_area, axo_query_floor_area, axo_audit_lot_area, axo_audit_lot_coverage, axo_audit_septic, axo_audit_energy, axo_audit_wwr, axo_audit_setback |
Pure math over geometry; LLM never touches the number |
The second class is the review's headline finding. In QC work, the failure mode that matters isn't “no answer” — it's a confident wrong number. Splitting computation out of the LLM is the right call, and it's the one decision in this codebase I'd defend in front of a building official. The shoelace-formula lot area and per-room floor aggregation produce the same figure every time, and the code is one readable file if you want to check the arithmetic.
Equally notable: the honest-placeholder policy. axo_audit_energy, axo_audit_wwr, and axo_audit_setback return narratives about what they couldn't compute — because the Autodesk add-in doesn't export property-line geometry, U-factors, or full envelope geometry — rather than a fabricated ratio. Most AI wrappers fail silently. This one fails out loud.
What It's Actually Like to Ask Questions
The plain-English mapping is the product:
| You ask | What runs |
|---|---|
| “Total floor area per level” | axo_audit_floor_area |
| “Lot area and lot coverage?” | axo_audit_lot_area → axo_audit_lot_coverage |
| “Export the door schedule to CSV” | get_running_revit_instances → export_views |
| “Window-to-wall ratio” | axo_audit_wwr (counts today; area ratio pending add-in geometry) |
The target user is explicit and correct: a senior architect with decades of judgment and no interest in learning the schedule palette. Revit's read-only constraint — usually framed as a limitation — is, for this persona, the feature. They never wanted an AI editing the model.
Limitations: Every One of Them Is Real
Credit where due — the project's README documents its own breaking points better than most commercial software. Verified against the repo:
- Model structure dependence (GIGO). The quality of the audit output is strictly bound to how well the Revit file is structured and modeled. If design elements are miscategorized, room boundaries are overlapping, or key parameter fields are empty, these audits will generate highly precise garbage. The tools extract geometry and parameters; they cannot fix poor modeling habits.
- Audit tools are not fully tested. The custom audit tools have not been fully tested and are currently experimental prototypes. They demonstrate the concept of out-of-model validation but should not be relied upon for permit submittals without independent validation.
- Single-threaded, permanently dead-lockable. Every query queues on Revit's UI thread. Retry loops don't slow the connection — they kill it, until you restart the add-in or Revit. Rule of engagement: one query at a time, stop on error, never retry-storm. The wrapper serializes calls, but the discipline lives in the agent, and anything with uncontrollable retry logic (looking at you, AnythingLLM's agent executor) will eventually shoot this pipe.
- Host model only. Linked models — where your consultants live — are visible but not queryable.
searchScope: "AllViews"or get silence. Forget it andquery_modelreturns empty lists for data that's right there. A small model will then conclude “the model has no levels.” This is intent engineering, and it's the real skill tax of this stack.OST_Roofscan hang on complex models. Probe withmaxResults: 1first.- Heavy queries run 30–60+ seconds. Normal, not a bug. Budget for it.
- No governance layer in the file itself. No dedup, no heartbeat. Deliberate scope — but it means the wrapper protects the pipe only if the agent cooperates.
The Alternatives, Fairly Weighed
| Route | Python needed | Tools | Instance handling | Tradeoff |
|---|---|---|---|---|
| revit-tools (this project) | Yes (stdlib only) | 15 (7 native + 8 audits) | Auto-injected | Small setup friction; deterministic audits |
| revit-direct | No | 7 native only | Manual revitInstanceId |
Zero install; no audit suite |
| revit (original proxy) | Yes + pip + venv | 15 + governance | Managed | Most features; heaviest install |
If your users won't touch a terminal, revit-direct is the honest recommendation and the project says so itself. If numbers end up in permit documents, the Python file earns its keep.
FAQ
Is revit-tools free?
Yes. MIT license, no API keys, no cloud account, no telemetry. It runs entirely on the machine where Revit is running.
Does revit-tools work with Claude Desktop or other MCP clients?
Architecturally, yes — but that path is untested. I read the server source: axo_mcp_server.py implements plain JSON-RPC over stdin/stdout (MCP protocol 2025-06-18) with zero external imports and no DSH-specific calls — any stdio client (Claude Desktop, Continue, Cursor) can spawn it, and the README documents a generic mcpServers config for exactly that. Two honest caveats: (1) the project was developed for and tested on DeepSeek Harness, which remains the supported reference environment; (2) given the add-in's deadlock-on-retry behavior, an unfamiliar client's built-in retry logic is a real risk — only DSH's preset configuration ships with the discipline baked in.
Can it modify a Revit model?
No — and it never will, by design. The underlying Autodesk add-in is read-only. It answers questions; it doesn't touch geometry.
What happens when the model lacks data?
The audit tools report “not in the model” explicitly. They never interpolate, estimate, or invent a figure.
Is it production software?
No. It's an experimental test of concept built on Autodesk's Technical Preview add-in. The custom audit tools have not been fully tested, and the maintainers are explicit that users are encouraged to run it in DSH, refine it, and add tools of their own. Verify every output with a licensed professional before relying on it.
Developed for DSH — and Meant to Be Customized There
This positioning deserves its own section, because it reframes what the repo is. revit-tools is not a shrink-wrapped product; it is a test of concept with DSH as the workbench, and the intended user journey is: copy the preset folder, run it, then start bending it.
The customization surface is deliberately low:
- Add an audit tool: write one handler function in
axo_mcp_server.pyand register it inaxo_tools()— it appears intools/liston the next session. No compilation, no packaging. - Change a rule: the septic clearance (50 ft), the WWR limit (default 40%), the lot-area parameter keys — all are readable constants in the one file you own.
- Add a whole second MCP server: (e.g., a code-RAG lookup) by adding one row to the DSH preset YAML.
I verified the portability question in the source, because it matters: nothing in the file imports or calls anything DSH-specific — the only DSH reference in the code is a comment. The DSH-specific part is the packaging (the agent.cordis.yml preset), not the server. So “portable to other MCP clients” is architecturally true; “supported on other MCP clients” is not a claim the project makes. Given the zero-dependency proof of concept is meant to be forked and extended by non-programmers, DSH-first is a defensible scope decision — just don't mistake it for vendor-agnostic shipping software.
Verdict
revit-tools is the rare AI wrapper that understands its own blast radius. The deterministic audit layer, the honest-placeholder policy, the self-documented deadlock risk, and the zero-dependency single file all point the same direction: this was built by someone who has watched a confident LLM state a wrong floor area and decided “never again.”
It won't close the verification loop alone — zoning-code RAG is still an open gap (the maintainers map three credible strategies, from plain file-context to a second MCP server in the same preset). And it inherits every limitation of a Technical Preview add-in. But as an answer to the question “can a senior architect interrogate a live Revit model the way they interrogate a drawing set — by asking?” — yes. It runs. And because it's built on standard MCP plumbing, it keeps running when the next Autodesk server ships.
Rating for its stated purpose (QC proof of concept): 8/10. Deductions for the single-threaded fragility it can't fix and the placeholder audits it can't complete — both Autodesk's constraints, both disclosed.
Repository: github.com/Axotopia/revit-tools — MIT license. Disclosure: independent technical review of a public repository; no affiliation. This is not professional architectural, engineering, or legal advice; verify audit results with a licensed Architect or Engineer of Record.