2026.10.08

MCP Server 開發實作：把企業內部系統接上 AI 的 7 個步驟（2026）｜山葵組

文章目錄

重點摘要

MCP Server 是把企業系統的能力，包裝成 AI 工具看得懂、能呼叫的介面。文件平台、程式碼託管等常見服務多半已有現成的 MCP Server；ERP、自建後台這類內部系統則需要自行開發。
開發前先決定四件事：開放哪些能力、部署在本機還是遠端、怎麼驗證身分、操作紀錄怎麼留。
工具設計決定 AI 用得好不好：名稱與說明要寫給 AI 看、參數要明確、一個工具做一件事。
最重要的原則是沿用既有的使用者權限，並在高風險操作前保留人工確認。

什麼時候需要自己開發 MCP Server

MCP（Model Context Protocol）是讓 AI 應用連接外部系統的開放協定，概念與架構可參考MCP 企業導入完整指南。實際導入時，第一個問題通常是：要用現成的，還是自己開發？

情境	建議做法
常見的 SaaS 服務，例如文件平台、專案管理、程式碼託管	優先使用服務商提供的官方 MCP Server，維護成本最低
自建的後台、ERP、CRM 等內部系統	自行開發，因為只有自己的系統知道資料結構與商業規則
現成 MCP Server 的功能不夠，或權限控管不符內部規範	以現成的為基礎再包一層，或自行開發
只是想讓 AI 讀取文件內容回答問題	不一定需要 MCP，建立 RAG 知識庫可能更直接

開發前要先決定的四件事

一、要開放哪些能力

MCP 定義了三種能力，大部分企業系統以「工具」為主：

類型	用途	企業系統的例子
Tools（工具）	讓 AI 執行動作或查詢	查詢訂單、建立工單、更新客戶狀態
Resources（資源）	提供可讀取的資料	產品規格文件、作業手冊、報表
Prompts（提示範本）	預先寫好的操作範本	「整理本週逾期工單」「草擬報價說明」

建議從唯讀的查詢工具開始，確認效果與權限控管都穩定後，再開放會修改資料的工具。

二、部署在本機還是遠端

方式	傳輸方式	適合
本機執行	stdio：由 AI 應用直接啟動程式	開發者工具、個人使用、試點驗證
遠端服務	Streamable HTTP：透過網路連線	多人共用、需要集中管理權限與紀錄的企業情境

企業內部正式使用時，多半採用遠端部署，才能統一管理版本、權限與操作紀錄。

三、怎麼驗證身分

遠端 MCP Server 等於對外開了一個操作系統的入口，身分驗證不能省略。MCP 規範中針對 HTTP 連線定義了以 OAuth 為基礎的授權流程；企業內部也常直接串接既有的單一登入（SSO）。關鍵是讓每一次 AI 的操作，都能對應到一位實際的使用者。

四、操作紀錄怎麼留

AI 透過 MCP 執行的每個動作，都應該記錄是誰、透過哪個 AI 應用、呼叫了什麼工具、傳入什麼參數、結果如何。發生問題時才能追溯，也能作為日後調整權限的依據。

開發步驟

盤點既有 API：列出系統已經有哪些 API，以及使用者在後台最常做的操作。MCP Server 多半是在既有 API 之上包一層，不需要重寫商業邏輯。
設計工具清單：從常用操作挑出第一批工具，每個工具只做一件事，並寫好名稱、說明與參數。
選擇 SDK：官方提供 TypeScript、Python 等多種語言的 SDK，選擇和既有系統相同或團隊熟悉的語言即可。
串接權限：工具執行時以登入使用者的身分呼叫既有 API，沿用原本的角色權限，不要使用萬用的系統帳號。
加上確認機制：刪除、批次修改、對外寄送這類操作，在執行前要求使用者確認。工具也可以標註為唯讀或具破壞性，讓 AI 應用據此提示使用者。
處理回傳與錯誤：回傳結構清楚、資料量適中的結果；錯誤訊息要說明原因與下一步，AI 才能自行修正參數重試。
測試與上線：用官方的 MCP Inspector 逐一測試工具，再接到實際使用的 AI 應用驗證；上線後持續觀察呼叫紀錄與錯誤率。

工具設計：寫給 AI 看的介面

AI 是依據工具的名稱、說明與參數定義，決定什麼時候呼叫、怎麼呼叫。以下是一個查詢訂單工具的定義：

{
  "name": "search_orders",
  "description": "依客戶名稱、訂單狀態或日期區間查詢訂單。只回傳目前使用者有權限查看的訂單，每次最多 20 筆。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customer_name": { "type": "string", "description": "客戶名稱，可輸入部分文字" },
      "status": { "type": "string", "enum": ["pending", "shipped", "cancelled"] },
      "date_from": { "type": "string", "format": "date" },
      "date_to": { "type": "string", "format": "date" }
    }
  }
}

面向	不好的設計	好的設計
粒度	一個萬用工具 `run_sql` 或 `call_api`	一個工具對應一件業務操作，例如 `search_orders`、`create_ticket`
說明	「訂單 API」	寫清楚用途、適用情境、限制與回傳範圍
參數	一個自由格式的字串	欄位明確，能列舉的值用 enum，日期註明格式
回傳	把資料表整筆原樣丟回	只回傳回答問題需要的欄位，並限制筆數

常見錯誤

錯誤	後果	做法
用管理員帳號執行所有工具	一般員工透過 AI 就能看到或修改無權限的資料	以登入使用者的身分執行，沿用既有權限
一次開放太多工具	AI 選錯工具的機率上升，也難以測試	從少量高頻的工具開始，逐步擴充
沒有操作紀錄	出問題時無法追溯是哪一次呼叫造成	每次呼叫都記錄使用者、工具、參數與結果
直接開放資料庫查詢	繞過商業規則與權限檢查，也有資料外洩風險	透過既有 API 或服務層存取資料

系統本身的 API 決定導入成本

MCP Server 能做到什麼程度，取決於系統本身的 API 是否完整。後台的每個操作都有對應的 API、權限可以切到單一模組、欄位定義清楚的系統，包成 MCP 工具幾乎只是多一層轉接；反之，如果大部分功能只能透過網頁介面操作，就得先補齊 API。系統要怎麼設計才適合 AI 操作，可參考讓系統能被 AI Agent 操作。

規劃新系統時，若預期未來會讓 AI 協助操作，從一開始就把 API 與權限設計好，會比事後補做省力得多。這類設計可參考客製化系統開發，在後台內建 AI 助手的做法則可參考全域後台 AI 助手。

常見問題

MCP 和一般的 API 有什麼不同？
API 是給程式呼叫的介面，MCP 則是讓 AI 應用用統一的方式發現與呼叫這些能力。MCP Server 通常建立在既有 API 之上，不需要取代原本的 API。

既有系統沒有 API，可以做 MCP Server 嗎？
可以，但要先補上必要的 API 或服務層，再包成 MCP 工具。不建議直接讓 MCP Server 讀寫資料庫，否則會繞過系統原本的權限與商業規則。

MCP Server 要用什麼語言開發？
官方提供多種語言的 SDK。一般會選擇和既有系統相同的語言，方便共用程式與部署流程。

遠端 MCP Server 安全嗎？
安全性取決於設計：身分驗證、沿用既有權限、高風險操作確認、完整的操作紀錄，四項都做到，風險就和開放一般 API 相當。

結語

開發 MCP Server 的技術門檻不高，真正需要花心思的是工具設計與權限控管。建議從少量唯讀工具開始試點，確認 AI 能正確使用、紀錄完整後，再逐步開放更多操作。需要把 AI 串進既有流程時，可參考AI 流程自動化整合。