MCP 是什麼？Model Context Protocol 如何連接 AI Agent、Tools、API 與 JSON Schema？

工具明明已經寫好，AI Agent 卻找不到、參數常錯，或每個客戶端都要重做一套整合。

最快解法：把 MCP 視為連線生命週期協定，而不是模型功能；讓 Client 先發現 Server 的工具與 JSON Schema，再由受控執行環境真正呼叫 API 並回傳結構化結果。

這篇文章適合哪些團隊？

如果你是 MCP Server 開發者，本文會幫你確認工具描述、輸入 Schema 與錯誤處理是否足夠清楚。
如果你是 Agent 平台工程師，你會看到多個 Client、模型與 Server 如何分層協作。
如果你負責運維或資安，本文則集中處理認證、憑據、確認流程、審計與限制工具權限。

MCP（Model Context Protocol）是連接 AI 應用與工具、資源、提示模板的開放協定。它不是模型，也不會取代 Function Calling。典型流程是：MCP Client 發現 Server 暴露的工具 Schema，模型選擇工具，Client 或平台執行呼叫，再把結構化結果交回模型。官方架構將 Host、Client、Server 分開，目的是讓權限與生命週期不直接交給模型。 官方架構說明 (modelcontextprotocol.io)

先把四個角色分清楚，避免架構一開始就放錯責任

你可以把一次 MCP 連線想成四層：

• Host：承載 AI 功能的應用，例如編輯器、聊天工具或企業內部 Agent 平台。Host 建立 Client、管理連線生命週期，並處理使用者確認與安全政策。
• MCP Client：Host 內的連接器。每個 Client 通常維持與單一 Server 的隔離連線，負責初始化、能力協商、工具發現、訊息轉送與關閉。
• MCP Server：暴露工具、資源或提示模板的程式。它可以是本地子程式，也可以是部署在雲端或企業網路內的遠端服務。
• 底層 API 或執行環境：真正讀取資料、建立工單、部署程式、操作檔案或執行 macOS 自動化的地方。

因此，「MCP 和大模型之間是什麼關係」的答案很簡單：模型負責推理與選擇，MCP 負責標準化互動，Host 與 Client 負責把互動放在可控的安全邊界內。模型通常不應自行建立網路連線，也不應持有所有後端憑據。

一次連線的端到端時序

使用者提出任務
    ↓
Host 將可用工具與上下文交給模型
    ↓
MCP Client ──初始化 / 能力協商──> MCP Server
    ↓                              ↓
工具清單 + inputSchema              驗證請求與權限
    ↓
模型選擇工具與參數
    ↓
MCP Client ──tools/call──────────> MCP Server
                                      ↓
                                  呼叫底層 API
                                      ↓
MCP Client <──工具結果 / 錯誤────── MCP Server
    ↓
Host 把結果交回模型，產生下一步回覆

這個分層很重要。Function Calling 是模型或模型 API 的工具選擇介面；MCP 是工具提供者與 AI 應用之間的連線協定；實際 API 執行則發生在 MCP Server 或其受控執行環境。 三者可以一起使用，但不能混寫成同一件事。

本地 STDIO 與遠端 HTTP 的部署取捨

第一次建置時，先決定 Server 是只給本機 Host 使用，還是要讓團隊與多個環境共享。官方規範目前定義 STDIO 與 Streamable HTTP 兩種主要傳輸方式；STDIO 由 Client 啟動子程式，Streamable HTTP 則由獨立伺服器處理網路連線。 官方傳輸規範 (github.com)

STDIO 的優點是部署快、沒有公開網路入口，適合先驗證工具契約；缺點是工具只跟著某一台機器與 Host 走，團隊共享、集中監控和權限撤銷會變得麻煩。

遠端 HTTP 的優點是多個 Agent 可以共用同一個 Server，工具更新也集中；代價是你必須補齊 TLS、認證、網路隔離、連線逾時、重試和日誌。不要只把本地程式包一層 HTTP 就上線，這會把原本隱藏在本機環境裡的權限風險直接暴露出去。官方 SDK 也將 Streamable HTTP 用於遠端服務、STDIO 用於本地子程式。 官方 TypeScript SDK Server Guide (github.com)

注意： 不同 Host 或 Client 可能只支援規範的部分能力。你應記錄規範版本、SDK 版本與客戶端版本，並以實際初始化與工具呼叫結果判定相容性，不能把某一個產品的行為當成 MCP 通用保證。

連線生命週期中的工具與 Schema 使用方式

1. 初始化與能力協商

Client 建立 transport 後，會向 Server 發起初始化。這一步不是在詢問「模型有多聰明」，而是在確認雙方支援哪些協定能力、如何交換訊息，以及 Server 提供的基本識別資訊。

你應在這個階段檢查：

1. transport 是否真的建立。
2. Server 是否回應初始化。
3. 雙方協定版本是否可接受。
4. Server 宣告的能力是否符合預期。
5. 連線失敗時是否能明確區分 DNS、TLS、認證、版本或應用程式錯誤。

2. 工具發現與 Schema 讀取

Client 接著讀取工具清單。每個工具至少要有穩定的名稱、用途描述與 inputSchema；如果工具輸出需要被後續程式可靠消費，則可另外提供 outputSchema。MCP 工具規範明確將輸入與輸出 Schema 分開，並允許工具結果同時包含一般內容與結構化內容。 官方 Tools 規範 (modelcontextprotocol.io)

一個可維護的工具定義，應回答四件事：

• 什麼情況下應該使用它？
• 哪些欄位必填，格式限制是什麼？
• 執行後會改變什麼狀態？
• 失敗時會回傳哪一種可處理的錯誤？

JSON Schema 的價值在於讓 Client 能驗證參數，也讓模型知道欄位型別與必要條件。但 Schema 不是完整說明書。若你只寫 action: string，模型不知道可用值、風險和副作用；工具描述應明確寫出「只讀」、「會建立資源」、「不可重複執行」等語意。

3. 工具呼叫與 API 執行

當模型選定工具後，模型產生的是工具名稱與參數，不是直接執行指令。Client 會將呼叫送給 Server；Server 再依序進行輸入驗證、權限檢查、業務邏輯處理與底層 API 呼叫，最後回傳結果。

這裡至少要處理五種情況：

• 參數錯誤：回傳可修正的欄位問題，不要只丟出模糊的「Bad Request」。
• 逾時：為外部 API、資料庫與長任務分別設定逾時，避免 Agent 一直等待。
• 取消：使用者中止任務後，Server 必須停止或標記仍在執行的工作。
• 重試與冪等：建立訂單、發送郵件、刪除資料等操作不可無條件重試；需要冪等鍵或明確狀態查詢。
• 結構化結果：對後續流程有用的欄位放入結構化內容，文字則保留給人類閱讀與除錯。

如果工具在失敗後只回傳一段自然語言，模型可能反覆猜測並再次呼叫。較好的做法是回傳錯誤類型、是否可重試、建議修正欄位，以及追蹤識別碼，讓 Host 能控制下一步。

4. 權限、憑據與使用者確認

不要把 API Key、OAuth Token 或內部主機密碼寫進工具描述、Schema、提示模板或公開設定檔。Schema 描述的是資料形狀，不是秘密儲存區。

建議你把工具分為三層：

• 只讀工具：查詢狀態、搜尋文件、讀取報表，可在低風險範圍內自動執行。
• 寫入工具：建立工單、修改設定、推送程式，需要記錄操作者、目標與變更內容。
• 破壞性工具：刪除資料、撤銷憑證、停止服務，應加入白名單、明確確認與二次驗證。

遠端 HTTP Server 若需要保護，應依官方授權規範處理 Token、資源識別與 HTTPS；STDIO 則通常由本機環境提供憑據，不應直接套用 HTTP 認證流程。 MCP 授權規範 (modelcontextprotocol.io)

經驗： 先讓所有工具以「預覽模式」回傳將要執行的動作，再把真正寫入或破壞性操作放到第二次確認。這比只依賴 destructiveHint 更可靠，因為工具標註仍需要由 Client 以安全邏輯判斷，不能盲目信任。

MCP 部署路線的決策條件

請用以下條件作為決策工具：

• 若只有一名開發者、工具需要讀取本機檔案或本地命令，且不需要跨裝置共享，選本地 STDIO。
• 若多個 Agent、團隊成員或自動化工作流需要共用同一套 API，選遠端 Streamable HTTP。
• 若工具包含寫入或破壞性動作，無論使用哪種 transport，都加入 Host 端確認、Server 端授權和可追蹤審計。
• 若內部 API 不能暴露到公網，將 MCP Server 放在企業內網或受控閘道後方，不要用公開 endpoint 繞過原有網路政策。
• 若依賴 macOS 資源、Xcode、程式簽名或長期蘋果自動化，才評估常駐 Mac；一般 API 型 MCP Server 不需要部署在 Mac。

常見驗收錯誤與排查順序

你可以按照以下五步完成第一次接入：

1. 先固定一個最小工具：例如查詢專案狀態，不要一開始就暴露十幾個寫入工具。
2. 用官方 SDK 或相容 Client 完成初始化：記錄 transport、規範版本、Client 版本與 Server 版本。
3. 執行工具發現：確認工具名稱穩定、描述可理解、inputSchema 是有效 JSON Schema，必要欄位與列舉值沒有遺漏。
4. 測試成功與失敗路徑：至少測試缺少欄位、錯誤型別、無權限、上游逾時、使用者取消與重複提交。
5. 再進行遠端化：將 STDIO 改為 Streamable HTTP 後，重新測試 TLS、Token、連線中斷、重連、日誌與並行呼叫。

若工具清單能出現但呼叫失敗，優先檢查 Server 內部 API，而不是先怪模型。若呼叫參數一直不對，先檢查工具描述和 Schema；若結果能回傳但後續 Agent 無法使用，則檢查 outputSchema、錯誤欄位與結構化內容。

MCP Server 長期運行與 Mac 方案評估

個人本地 Server 適合快速開發，但會受到電腦休眠、使用者登出、本機權限變動和網路位置改變影響。團隊遠端 Server 比較容易集中管理與審計，但你需要自行處理憑據、更新、監控和故障切換。混合模式通常較穩妥：開發階段用 STDIO，正式工具放到受控 HTTP 環境。

只有當 MCP 工具必須持續存取 Xcode、程式簽名環境、iOS 模擬器或 macOS 自動化時，遠端 Mac 才有明確價值。這類需求可以先閱讀 Kvmjet 的基礎設施說明，再透過 支援中心確認常駐、連線與權限驗收條件；若需要針對團隊流程評估，也可從聯絡 Kvmjet開始。

如果你的現有方案是讓每位開發者各自維護本地 Mac，常見缺點是環境版本不一致、電腦休眠造成工具中斷，以及憑據和審計分散在個人裝置上。若改用一般 Linux 或雲端主機，又可能無法提供 Xcode、簽名工具與完整蘋果自動化環境。對需要讓 MCP 工具持續接觸這些資源的團隊，租用 Kvmjet 的遠端 Mac 會比臨時拼裝多台個人電腦更容易集中管理；但若你是長期高負載、需要實體介面，或已有成熟自建機房，直接購置與自管硬體仍可能更合適。

MCP 的重點不是把所有工具搬到同一台機器，而是讓 AI Agent 以一致方式發現能力、提出呼叫，並在清楚的權限與執行邊界內取得結果。先用最小工具完成一輪初始化、發現、呼叫與錯誤驗證，再決定是否遠端化，通常比一開始追求完整平台更能降低返工成本。