# Reported issues for Revit MCP by shuotao

Pod holds 16 of 23 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.

Back to [Revit MCP by shuotao](/mcp/revit-mcp-by-shuotao).

## Most discussed

### [RFC／提案] 新增可選的 Archicad Backend，並定義跨 Revit／Archicad 的 Skill 與 Domain 邊界

## 提案背景

我目前已使用 Agy CLI、BIM_MCP 與 `tapir-archicad-mcp` 完成 Archicad 實機連線測試。

目前已驗證：

- Agy CLI 可以啟動 Archicad MCP Server。
- `discovery_list_active_archicads` 可以找到目前開啟的 Archicad 專案。
- `archicad_discover_tools` 可以取得目前可用的 Archicad command 與 schema。
- `archicad_call_tool` 可以讀取 Archicad 模型資料，並已成功測試部分模型指令。
- Revit MCP 的原始設定與功能維持不變。
- Repository 已提交的 MCP 設定仍維持 Revit-only。

目前的實作：

- Branch: https://github.com/Archwiz-boss/BIM_MCP_study/tree/agent/archicad-mcp-integration-v2
- Commit: https://github.com/A

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/98) · 2026-07-22 · open · outside contributor · 7 comments

### 提案：導入 Loader/Core 熱重載架構，降低 Revit 開發過程中的重啟成本

#32 Issues提案
# 背景

目前上游的 Revit MCP 尚未提供「不重啟 Revit 即可重新載入插件核心邏輯」的機制。

在現行開發流程中，只要修改 Revit 端的插件邏輯，通常就需要：

1. 重新編譯插件
2. 覆蓋 DLL
3. 重啟 Revit
4. 重新連線並驗證結果

這個流程雖然可行，但對於高頻調整命令邏輯的開發情境來說，成本很高。

我們已經在 `feature/loader-core-r26` 分支上實作並驗證一套 Loader/Core 架構。  
這個 Issue 的目的，是討論是否要將這套機制正式導入主線。

## 這個解法可以達成什麼

透過將 Revit Add-in 拆成穩定的 Loader 與可重載的 Core Runtime，這個解法可以做到：

1. 在不重啟 Revit 的情況下，重新編譯並替換 `RevitMCP.CoreRuntime.dll`
2. 透過 Revit 內的 `Core 重載` 操作重新載入 Core 邏輯
3. 加快命令層開發迭代速度，尤其是 `CommandExecutor` 類型的修改
4. 將完整 Re

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/33) · 2026-04-09 · closed · outside contributor · 6 comments

### [提案] 將 SC REVIT 的 CAD 點位放置流程整理成 AI 可用工具

## 這個提案從哪裡來

機電 CAD 圖裡常有大量重複圖塊，例如灑水頭、設備或閥件。這些圖塊已經帶有名稱、位置和旋轉角度，但進到 Revit 後，使用者仍要逐點放置對應族群。

我已在 SC REVIT 中設計一套給 Revit 使用者操作的 CAD 點位放置工具。現在的流程是由人選擇 CAD、圖塊、族群與樓層，查看預覽後再確認放置。

這次提案不是把原本的對話框和按鈕搬進 MCP，也不是讓 AI 模擬人工點選，而是保留已驗證的圖塊辨識與放置邏輯，重新拆成 AI 可以呼叫的「發現、預覽、建立、驗證」流程。

## 目前給人使用的流程

1. 使用者選擇 CAD 與目標 Block。
2. 使用者指定 Revit FamilySymbol、Level 與 offset。
3. SC REVIT 在 Revit 中顯示偵測或預覽結果。
4. 使用者目視確認位置、旋轉與重複項目。
5. 使用者確認後，工具實際放置 FamilyInstance。

後續加入 Issue 的 Revit 偵測與放置畫面，會標示為「SC REVIT 現有人工工具」，用來說明既有工作流程，不代表 MCP 功能已完

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/100) · 2026-07-23 · closed · outside contributor · 5 comments

### [提案] 將 SC REVIT 的開孔定位流程整理成 AI 可用工具

## 這個提案從哪裡來

在機電管線穿過牆、樓板或樑時，工程師通常要逐筆確認穿透位置、需要多大的開孔，以及哪些位置不能直接處理。

我已在 SC REVIT 中設計一套給 Revit 使用者操作的工具。現在的流程是由人選擇來源、執行偵測、查看 Revit 畫面，再決定後續定位或放置。

這次提案不是直接移植 SC REVIT 的 UI，也不是讓 AI 模擬滑鼠操作，而是保留已驗證的工程邏輯，重新整理成 AI 可以穩定呼叫、預覽和驗證的 MCP 工具。

## 目前給人使用的流程

1. 使用者在 Revit 中選擇 MEP 與結構來源。
2. 工具掃描管線穿過牆、樓板、樑或柱的位置。
3. 使用者從 Revit 畫面查看偵測結果。
4. 使用者判斷哪些位置可以處理、哪些需要複核。
5. 使用者確認後，才進入開孔定位或放置流程。

後續加入 Issue 的 Revit 偵測與放置畫面，會標示為「SC REVIT 現有人工工具」，用來說明既有工作流程，不代表 MCP 功能已完成。

## 這個專案已經有很好的基礎

現有的 `detect_clashes` 已能找出 MEP 與結構元素的交

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/99) · 2026-07-23 · closed · outside contributor · 5 comments

### [Bug] 兩個 MCP 工具有 TS 註冊但無 C# handler，呼叫必拋 NotImplementedException

## 摘要

`main` 上有兩個 MCP 工具**只註冊了 TS 端、沒有對應的 C# handler**，呼叫時會直接落到 dispatcher 的 `default:` 而拋例外：

- `sync_room_ceiling_finish_from_ceilings`
- `remap_room_finish_codes`

## 證據（基於目前的 `main`）

TS 端有註冊：

- `MCP-Server/src/tools/room-tools.ts:201` → `name: "sync_room_ceiling_finish_from_ceilings"`
- `MCP-Server/src/tools/room-tools.ts:243` → `name: "remap_room_finish_codes"`

C# 端搜不到任何對應：

```bash
git grep -n "sync_room_ceiling_finish_from_ceilings\|remap_room_finish_codes" main -- MCP/
# 無輸出
```

而 `

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/111) · 2026-08-06 · closed · outside contributor · 3 comments

### MCP 工具無法自動觸發 pyRevit 按鈕 / Reload 功能

## 📋 問題背景 (Problem Statement)
目前 MCP 主要提供 Revit **DB API（模型資料庫操作）** 的存取介面，但無法主動存取或呼叫 **UI API（界面與按鈕觸發）**。
這導致使用 AI Agent 自動化開發/維護 pyRevit 工具時，當編輯完 `.py` 腳本後，仍必須由人工在 Revit 介面中手動點擊 **pyRevit → Reload** 或手動觸發對應的 pyRevit 按鈕，無法讓MCP自動測試按鈕功能是否有效。

---

## 🌐 OSI 網絡模型結構與限制分析 (OSI Layer Analysis)

透過 OSI 7 層模型架構來分析 MCP 與 pyRevit 按鈕呼叫之間的介面隔離問題：

### OSI 層級對應表

| OSI 層 | 標準定義 | Revit 生態系對應概念 | MCP 目前涵蓋狀態 |
|---|---|---|:---:|
| **L7 Application (應用層)** | 使用者軟體服務 | pyRevit 按鈕 UI / Ribbon Tab / 對話框邏輯 | ❌ 無法存取

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/110) · 2026-08-01 · closed · outside contributor · 2 comments

### [複核請求] #86 收攏時重建的 9 個 helper + IFC 柱偵測 0 columns — 請 @Jacky820507 對照原始碼確認

Hi @Jacky820507,你在 #79 / #81 / #82 的實作已由 #86 收攏進 main(自 `jacky/main` 取回、Windows 端 build 通過 R24+R26、Revit 2024 實跑 16/16 通過)。感謝你的貢獻 🙏

過程中發現一件事需要你複核:**你的 domain SOP 引用的 9 個 helper 方法,在你 fork 的任何 branch 都找不到定義**(只有被呼叫、沒有本體)——推測是你本機實作、但只推了 domain docs。為了讓程式能編譯執行,維護者依「呼叫點合約 + repo 既有同族程式 + 你的 domain 規格」**重建**了這 9 個,集中在 `MCP/Core/Commands/CommandExecutor.ReclaimedHelpers.cs`。

### 請對照你本機原始碼重點複核(風險高到低)

- 🟠 `CollectGeometryFloorBottomHitsAtPoint`(幾何版射線)—— 因測試模型偵測不到柱,**未能 runtime 驗證**,只有射線姊妹版經真實資料確認。
- 

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/87) · 2026-07-16 · closed · 2 comments

### [Feature Request] 新增 analyze_floor_slopes 工具 — 樓板表面幾何坡度分析與參數回寫

## 需求描述

在建築法規檢討流程中，室外樓板需確認排水坡度是否符合設計標準（例如最小 1~2%）。
目前 Revit 並未內建針對樓板表面幾何的坡度批次計算功能，需手動逐一檢查。

## 提議的工具功能

新增 `analyze_floor_slopes` MCP 工具，功能包含：

1. **幾何分析**：透過 Solid → PlanarFace 的法向量與 Z 軸夾角，計算每片朝上頂面的坡度百分比
2. **批次處理**：可指定特定 elementIds，或自動收集所有 Function=Exterior 的樓板
3. **參數回寫**：將計算出的最小/最大坡度寫入使用者指定的參數欄位（預設 Comments）
4. **回傳結構化結果**：包含 ProcessedCount 及每片樓板的 Min/Max Slope 數據

## 涉及的程式碼變更

此功能需修改以下受保護的程式碼區域：

- `MCP/Core/` — 新增 `FloorSlopeAnalyzer.cs`（獨立靜態類別）
- `MCP/Core/CommandExecutor.cs` — 新增 case 路

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/45) · 2026-05-07 · closed · external user · 2 comments

## Most recent

### [Bug] WebSocket 服務未驗證 Origin — 瀏覽器頁面可直接連上 8964 對模型下命令

## 摘要

`MCP/Core/SocketService.cs` 接受任何抵達 `localhost:8964` 的 WebSocket 握手，沒有 Origin 檢查、沒有任何 token。WebSocket 握手不受同源政策保護、也不做 CORS preflight，因此**使用者只要瀏覽器開著一個惡意分頁，該頁就能連上 add-in 並對正在編輯的模型下命令**（cross-site WebSocket hijacking）。

`HttpListener` 綁的是 `localhost` prefix，所以遠端主機打不進來 —— 威脅面是本機，但「本機」包含使用者瀏覽器裡的任何一個分頁，不需要對方在這台機器上有立足點。

`ExclusiveLock` 不但擋不住，反而是第二個攻擊面：先搶到鎖的一方就是持有者，惡意頁面可以佔住連線，讓真正的 MCP client 一直收 409。

## 重現

寫了一個 console harness 直接載入建構好的 `RevitMCP.dll`、跑真的 `SocketService`（非模擬），用兩種原始 TCP 握手打它：

| 握

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/125) · 2026-08-25 · closed · external user · 1 comment

### dwg-column-import: 梯形/任意四邊形 PolyLine 在退而求其次分支被誤建成矩形柱

## 症狀

DWG 圖層批次建柱時，`ExtractColumns()` 對每個 PolyLine 先嘗試 `MakeRect(pts)`（嚴格矩形判定）。
若判定失敗，會退而求其次走「通用外接矩形」分支，直接用 `BuildColFromPoints()` 建柱——但這個分支
沒有再檢查來源多邊形是否真的是矩形。梯形、斜切四邊形等非矩形斷面因此會被誤建成矩形柱，尺寸不對。

## 根因

`MCP/Core/DwgColumnExecutor.cs`，`ExtractColumns()` 內：

```csharp
var c = MakeRect(pts);                          // 嚴格矩形優先（向後相容）
if (c == null && pts.Count >= 3)                // 退而求其次：通用外接矩形
    c = BuildColFromPoints(pts, LongestEdgeAngle(pts), diag, "PolyLine(" + pts.Count + "pt)");
```

`MakeRect

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/118) · 2026-08-15 · closed · outside contributor · 1 comment

### dwg-beam-import: StructuralUsage 設定被 try-catch 吞掉、beamRole 別名不完整

## 症狀

用 `create_beams_from_dwg` 批次建樑時，`beamRole`（大樑/次樑/地樑）對應的 Structural Usage
沒有正確落到新建的樑上；且對正參數（Y_JUSTIFICATION / Z_OFFSET_VALUE / Z_JUSTIFICATION）
設定若失敗會被靜默吞掉，難以排查。

## 根因

`MCP/Core/DwgBeamExecutor.cs`：
1. Y/Z 對正參數的設定原本包在 `try { ... } catch { }` 裡，且寫在 `StructuralUsage` 賦值**之前**，
   例外被整段吞掉、沒有任何錯誤訊息。
2. `MapBeamRoleToUsage()` 只比對「次樑／次梁」關鍵字，沒有涵蓋「小梁／小樑」這個常見別名，
   會導致該類樑的 usage 判定為 null（不設定）。

## 修正方向（本機已驗證）

- 把對正參數設定移到 `StructuralUsage` 賦值之後，並拿掉外層 try-catch（讓錯誤能被看見）。
- `MapBeamRoleToUsage()` 新

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/117) · 2026-08-15 · closed · outside contributor · 1 comment

### [實作] CAD 圖塊點位放置三支工具 — discover / preview / create

## 背景

規格已定案於 `domain/cad-block-point-placement.md`，由 @NicheSam 於 #100 提供規格與 Revit 2024 實測證據，特此致謝。

本 issue 追蹤三支工具的實作。

## 三支工具

1. **`get_dwg_block_instances`** — 唯讀盤點已載入 Linked DWG 中的 Block 名稱、數量、插入點、旋轉與唯一 identity。必須同時回傳「供人辨識的 CAD 名稱」與「供工具精確解析的 Revit identity」，後續工具沿用 identity，**不由 agent 自行拼接名稱**。

2. **`preview_family_instances_from_dwg_blocks`** — 唯讀檢查座標鏈、FamilySymbol、Level、offset 與重複項目，**不建立任何 Revit 元素**（不建十字線、群組或其他暫時元素）。FamilySymbol / Level / offset 由使用者明確指定，preview 只負責驗證與回報。

3. **`create

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/113) · 2026-08-10 · open · 1 comment

### [Enhancement] ezdxf_worker.py 錯誤訊息補充 Python 路徑與版本，方便診斷環境問題

## 問題描述

原本 ezdxf 找不到時只顯示：
```
缺少 ezdxf 套件，請在系統 Python 環境中安裝 (pip install ezdxf)
```

在多 Python 版本環境（如系統同時有 3.12 和 3.14）下，使用者不知道 Revit 呼叫的是哪個 Python，難以診斷安裝位置是否正確。

## 建議修正

將 ImportError 改為 Exception（捕捉範圍更廣），並在錯誤訊息中補充 Python 執行路徑與版本資訊，讓使用者能快速確認 Revit 呼叫的是哪個 Python 環境。

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/93) · 2026-07-18 · closed · outside contributor · 1 comment

### [Bug] install-addon.ps1 複製 DLL 路徑與 .addin 設定不符，導致部署後 Revit 載入舊版

## 問題描述

`RevitMCP.addin` 指定的 Assembly 路徑為：
```xml
<Assembly>RevitMCP\RevitMCP.dll</Assembly>
```
（子資料夾）

但 `install-addon.ps1` 實際複製到：
```
Addins\2024\RevitMCP.dll
```
（上層）

導致每次重新部署後，Revit 載入的仍是子資料夾裡的舊版 DLL，程式碼修改完全不生效。這個不一致從 commit `6ac1cf0` 起就存在。

## 修正方式

```powershell
$dllDestDir = Join-Path $addonPath RevitMCP
New-Item -ItemType Directory -Path $dllDestDir -Force
Copy-Item -Path $sourceDll -Destination (Join-Path $dllDestDir RevitMCP.dll)
```

`Newtonsoft.Json.dll` 也需要同步複製到子資料夾。

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/91) · 2026-07-18 · closed · outside contributor · 1 comment

### [調查/負面結果] 連結模型基準品類無法 per-link 隱藏 — Revit API 限制（2023–2026）

## 背景與需求

在疊了多個連結模型（結構＋機電）的視圖裡，每個 link 都會帶入自己的網格/樓層/參考平面，造成圖面雜訊。常見需求是：

> **只隱藏「連結模型」的基準品類，保留「本體」自己的基準**（本體基準常是以 Copy/Monitor 從主體模型監視複製而來）。

## 動機：為什麼需要「自動化」（明明視圖樣板就做得到）

這件事**在 UI 上確實做得到**——視圖樣板可以透過「Revit Links → 該 link → Custom」逐 link 關掉網格/樓層。問題不在「能不能」，而在「**維護成本**」：

1. **初始設定就很繁瑣**：一個視圖疊 8+ 個 link，每個 link 都要進 Custom 逐品類關，一次就要點很多下。
2. **真正的痛點——新增 link 後的維護災難**：一旦專案**中途新增一個連結**，這個新 link **不在任何既有樣板的覆寫清單裡**，於是**每一個已經做好的視圖樣板都得手動再進去、把新 link 的基準關掉**。專案樣板數量一多，這是**極度耗時且容易漏**的重複勞動。

所以理想是：**一個指令，對指定視圖/

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/72) · 2026-07-06 · closed · outside contributor · 1 comment

### 車位淨高檢查對應不同車位種類決定數值

# [Feature Request] 實作車位淨高檢查 (Parking Clearance Check) 工具

## 背景與需求
根據 `domain/parking-clearance-check.md` 的分析，我們需要一個能夠自動檢查特定樓層（例如 B1F）停車位上方淨高的工具。
該工具應具備以下功能：
1. 針對指定的車位，透過 Revit API 的射線檢測 (`ReferenceIntersector`) 到達天花板、樑、管線等障礙物的距離。
2. 針對「法規的一般性要求」自動判別一般車位（需大於 210cm）。
3. 針對「特殊的車位種類」，能**參照當地土地使用分區管制**的要求給予不同寬限值。例如「裝卸車位」通常需大於 270cm。
4. 根據檢測結果於視圖中直接以填滿顏色標示：合格為綠色，不合格為紅色。

## 建議實作方式 (供參考)
為了滿足土地使用分區管制的特殊車位要求，建議在工具的 `inputSchema` 中增加選填的規則參數，以便在面對不同法規時保有擴展性：

### 1. `MCP-Server/src/tools/parking-cleara

[Read the thread](https://github.com/shuotao/REVIT_MCP_study/issues/31) · 2026-04-06 · closed · external user · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/shuotao/REVIT_MCP_study/issues).