台北市使用分區、容積率、建照套繪 一次查清楚：從點位到危老試算的完整工作流

台北市的使用分區資料散在三個地方：都市計畫圖（zone_code 是什麼）、《自治條例》（FAR/BCR 數值是什麼）、建管處套繪（現在實際蓋了什麼）。 估價、都更、投資決策都需要這三套資料同時對得起來。 Funraise MCP 把這三層資料整合到 5 個工具，一次串完。本指南用幾個真實場景拆給你看。

場景一：估價師收到案件，10 分鐘確認可建容量

客戶丟一個地址「臺北市信義區虎林街 66 巷 31 號」。傳統作業要打開三套系統：地政司 EasyMap 查地號、都市發展局土地使用分區查詢系統查分區、《自治條例》查 FAR/BCR。 用 MCP 串起來大概這樣：

1. coordinates_by_address → 經緯度 (121.5759, 25.0448)
2. taipei_zoning_at_point → 回 zone_code「住3」(R3)，且預設一次帶上 FAR 2.25 / BCR 0.45
3. 客戶下一句問「臨路寬 8 米可以做都更嗎」→ 因為是基本種別 R3，沒 conditional 問題，直接算

整段對話走完 3 個 tool call、不到 10 秒。如果換成住三-1（R31），第二步會回 FAR=NULL + 警告「請先確認面前道路寬度 ≥16 米」— 工具刻意對齊估價師的真實工作流，不讓 LLM 拿著高值含糊估算。

場景二：都更整合商評估街廓，「商三特」這個陷阱

整合商盯上一塊地，分區查到是 B3A（第三種商業區特）。直覺：商三 = 560%、(特) 應該不會差太多，姑且按 560% 算可建坪數。這個直覺常踩雷。

「(特)」其實不是法定種別，而是該地號額外受某個子計畫拘束的記號。實務上 B3A 在信義計畫區某街廓比照商二 630%、其他街廓寫死 440%、敦化專用區內又是另一套規則。直接套 560% 算下來的投報率可能整整差一倍。

MCP 工具碰到 (特) 區會主動踩煞車：FAR/BCR 都回 NULL，notes 明寫「→ 請查該地號適用之細部計畫書」。這是設計上的取捨 — 寧可少給數字也不要給錯數字。整合商收到這個訊號，就知道下一步要去都市發展局調該街廓的子計畫書，而不是進試算公式。

場景三：投資顧問做現況調查，「這塊地現在有什麼」

使用分區告訴你「能蓋什麼」，建照套繪告訴你「現在蓋了什麼」。兩件事用不同工具。

taipei_bldg_overlay_at_point 餵點位，回該位置覆蓋的所有建照 polygon。預設只回 kind != null 的（有建照的），含建物、建物基地範圍、騎樓等。回傳的 {year_minguo, kind, permit_no} 三元組可唯一識別一張建照。

如果客戶要看完整一張建照覆蓋哪些 polygon（建物 + 空地 + 防火間隔），用 taipei_bldg_overlay_by_permit 餵三元組，回該建照所有 polygon、union bounding box、總面積。舉例：087 年第 0499 號建照（台北市政府廳舍，1998 年建）回 2 個 polygon、總面積 46,093 ㎡。

場景四：危老顧問接到 dd-memo 自動試算

最終目標通常是把分區資料接到危老／都更試算公式。dd-memo MCP 的 generate_renewal_underwriting 工具吃 base_far 跟 base_coverage 兩個 decimal 參數（2.25 / 0.45 這種格式）。

整套串起來的 typical chain：coordinates_by_address → taipei_zoning_at_point → 拿到 FAR/BCR → 餵 dd-memo。中間如果碰到 conditional 種別（FAR=NULL）、(特) 變體（FAR/BCR=NULL）、公設用地（永遠 NULL），LLM 會主動跟使用者確認臨路寬度或先查子計畫，再進試算。

240 列分區法規對照表的設計取捨

ES taipei_zoning 含 239 個 distinct zone_code。Funraise 的 D1 法規對照表 (taipei_zone_regulation) seed 了 240 列（含一列已廢除的 I1 ghost stub），分三層：

• Tier 1（25 列）：住宅基本種別 R1-R4 + 加成種 R21-R41、商業基本 B1-B4、工業 I2-I3、文教 C、行政 G — 主要分區，11 列有確切 FAR/BCR 法規值。
• Tier 2（22 列）：高頻公設 PEA / PEB / PG / PSB / PTA…、特定專用區 D4 / D5、住宅長尾 RR / R31A / R3B — 全 NULL + 個案需求書 notes。
• Tier 3（193 列）：長尾分類，機械生成從 ES aggregation。全 NULL + 「→ 請查子計畫書」notes。涵蓋率達 100% — LLM 拿到任何 zone_code 都不會 hard miss。

涵蓋率 100% 不是裝飾。它代表的是：客戶查到罕見的 zone_code（如「特定觀光商業專用區 B5」），工具至少能回 zone_name、提示「需查子計畫」，而不是回 404 讓客戶以為 MCP 壞了。

什麼時候不要用這幾個工具

幾個明確的邊界：

• 非台北市：只支援台北市範圍。新北 / 桃園 / 其他縣市請用 land_boundary（地籍）或 newtaipei-cadastral（新北專屬）。
• 具體個案估價：FAR/BCR 是上限值。具體投報率、容積獎勵、整合期成本估算仍須委由執業估價師簽證。
• 法律意見：分區資料是公開資訊，但都更條例、危老條例的同意比例、實施者資格等仍須諮詢律師。
• 都市計畫變更預測：MCP 提供的是現行法規。未來的計畫變更、容積獎勵調整需追蹤都市發展局公告。

Funraise MCP 的設計理念是「把資料整理乾淨、把陷阱標出來、把下一步指清楚」，不是取代專業判斷。