Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Taiwan Building Code Tracker 查詢建築技術規則中關於『防火時效』的條文"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
基於 MCP 協定的台灣建築法規自動化查詢工具，整合「法規條文」與「解釋函令」，提供最即時、精確且高品質的建築法規情報（目前以《建築技術規則建築構造編》為主）。
法規與函釋雙軌檢索: 同時支援「全國法規資料庫」條文查詢與「內政部國土管理署」解釋函搜尋。
動態網頁自動化技術 (Playwright):
採用 Headless Browser 技術繞過進階 WAF 防護與 Next.js 動態渲染，確保能即時獲取官網最新搜尋結果。
智慧標頭模擬：自動處理 JavaScript Challenge 與 Cookies，提供穩定的爬取效能。
條文結構化解析: 自動解析條文中的「編」、「章」、「節」與「條號」，並維持條文內容的完整性。
高效本地快取機制: 法規條文內建快取功能，大幅提升查詢速度並減少網路負擔。
AI 整合: 作為 Model Context Protocol (MCP) 伺服器，讓 AI (如 Claude) 能直接理解、分析並引用最新的台灣建築技術規範與實務解釋。
Related MCP server: taiwan-law-mcp
Runtime: Node.js (v20+)
Protocol: Model Context Protocol (MCP)
Browser Engine: Playwright (Chromium) - 用於處理動態解釋函網頁。
Data Source:
功能模組:
Building Scraper: 解析條文結構與本地 JSON 快取。
Interpretation Scraper: 動態搜尋國土署解釋函清單。
Detail Crawler: 深入抓取解釋函內文，供 AI 分析與引用。
安裝 Node.js (v20 或以上版本)。
確認已安裝 npm。
# 進入專案目錄
npm install
npx playwright install chromium
npm run build本服務為本機運行的 MCP Server，請將其加入 AI 客戶端（以 Claude Desktop 為例）。
找到 Claude Desktop 的設定檔 claude_desktop_config.json：
Windows: %APPDATA%\Claude\claude_desktop_config.json
將以下內容加入 mcpServers 區塊（請將路徑修改為您本機的絕對路徑）：
{
"mcpServers": {
"taiwan-building-code": {
"command": "node",
"args": [
"C:/Users/[您的使用者名稱]/.../Taiwam_building_code_tracker/dist/index.js"
]
}
}
}您可以對 AI 說：
「搜尋建築技術規則中關於『活載重』的規定。」
「幫我查一下『採光』相關的解釋令。」
「基礎構造在軟弱地層有什麼特別要求？是否有相關函釋？」
「重新更新法規資料 (refresh_data)。」
作者: 加號設計數位工程有限公司 HJPLUS.DESIGN
網站: 加號設計數位工程有限公司
我們是設計、建築與製造產業的外部研發夥伴，專門協助缺乏內部技術團隊的公司導入數位工作流程、工具與 AI。
僅供參考：本工具提供之資訊（包含法規條文與解釋函）僅供個人查詢輔助、學術研究或技術展示使用。所有資料內容均應以「全國法規資料庫」及「內政部國土管理署」官方公告為準。
無法律建議：本工具輸出之內容不構成任何形式的法律、設計或施工建議。使用者在根據本工具提供之資訊做出任何決策（如投標、設計、施工或法律救濟）前，務必自行核實資料的準確性、時效性與法律效力，或諮詢專業人士。
無責任擔保：開發者（加號設計數位工程有限公司）不對因使用本工具資料而產生的任何直接、間接、附帶或衍生性損失負責。
合法使用義務：使用者應確保使用本工具之行為符合相關法律規範。本工具模擬瀏覽器查詢行為以落實「政府資訊公開」，嚴禁將其用於任何形式的惡意爬取、拒絕服務攻擊 (DDoS) 或其他干擾政府系統正常運作之行為。
資料來源：全國法規資料庫、內政部國土管理署。
著作權聲明：依據中華民國《著作權法》第 9 條，法律、命令、公務員於職務上製作之文書（如解釋函）不適用著作權保護，任何人均得自由利用。本工具在引用時將自動標註原始來源與網址。
本專案採用 ISC License 開源授權。
版權所有 (c) 2026 加號設計數位工程有限公司 (HJPLUS.DESIGN Ltd.)。
Forcefully re-fetch the latest law articles from the official database and update the local cache.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear the burden. It notes a forceful update but lacks details on side effects, permissions, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and without redundancy, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the action and effect but does not mention return values or success indicators, which is needed since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the baseline score of 4 applies. The description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it forcefully re-fetches law articles and updates the local cache, distinguishing it from the sibling search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While not explicit, the context implies use for refreshing data vs. searching with sibling tool. Clear differentiation from 'search_building_code'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for official law articles in the 'Taiwan Building Code - Construction Works' (建築技術規則建築構造編). [IMPORTANT] The search 'query' MUST be in Traditional Chinese. Extract 1-3 core nouns from the conversation (e.g., '活載重', '地震力', '基礎構造') and use them as the query. Do not use long sentences.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default 10). | |
| query | Yes | Search keyword in Traditional Chinese. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Clearly states the search domain and language requirement, which is sufficient for a read-only search tool. Does not mention output format but no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, essential information front-loaded. Every sentence adds value: purpose and important usage rule.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of output format/return values, which is not covered by output schema (none). Given the tool's simplicity, a 3 is appropriate; could be improved by briefly mentioning what the search returns (e.g., list of articles).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by specifying query must be in Traditional Chinese and composed of core nouns, with examples. This goes beyond the schema's generic 'Search keyword in Traditional Chinese'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for official law articles in a specific code (Taiwan Building Code - Construction Works), with a specific verb 'search' and a well-defined resource. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions: query must be in Traditional Chinese, extract 1-3 core nouns. No explicit when-not-to-use or alternatives, but the guidance is strong for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: one refreshes cached data, the other searches for articles. There is no overlap or ambiguity.
Both tool names follow a consistent 'verb_noun' pattern in snake_case: refresh_data and search_building_code. The naming is predictable and clear.
With only 2 tools, the server feels thin for a domain like building code tracking, which typically requires more operations (e.g., listing articles, getting details). However, the scope may be intentionally narrow.
The server provides refresh and search capabilities but lacks basic retrieval operations like fetching a specific article by ID or listing all available articles. The surface is incomplete for a tracker.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Taiwan legal research MCP: 判決書、全國法規、釋字/憲判與立法歷程查詢，12 個工具，回應均附官方出處 URL。
An MCP server that provides congressional transcripts
City hiring-compliance MCP server with regulation search and full audit risk scoring.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/h30190/HJPLUS_Taiwan_building_code_tracker_MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
