一個 MCP 連線裡，Host、Client、Server 分別做什麼？

為什麼「客戶端連伺服器」還不夠？

把 MCP 說成「Client 連到 Server」沒有錯，但它藏掉了最容易混淆的角色：使用者實際操作的 AI 應用程式通常是 Host。Host 會管理模型、對話、使用者同意和多個外部連線；Client 是 Host 裡面負責和某一個 Server 交換 MCP 訊息的元件。

這個拆分解決的是責任問題。模型不應直接決定一個外部程式能讀什麼；Server 也不應因為接到一個請求，就看到 Host 的完整對話。Host 需要有一個可以檢查權限、整理上下文和呈現結果的位置，而 Client 需要維持清楚的單一連線邊界。

三個角色如何接在一起？

Host：容納應用邏輯與使用者決定

Host 是使用者直接操作的 AI 應用程式，例如一個桌面助手、編輯器或自建聊天應用。它建立並管理多個 Client，也負責把模型的需求轉成可執行的外部操作。當工具可能修改檔案或送出請求時，Host 應該能在執行前呈現清楚的資訊與確認機會。

Host 還負責把多個 Server 的結果放回正確的對話上下文。這表示「模型看到了什麼」和「Server 能讀到什麼」不是同一件事：Server 應只收到完成該次操作所需的資訊。

Client：Host 裡的一條隔離通道

每個 Client 只和一個 Server 溝通，而同一個 Host 可以建立多個 Client。Client 負責傳送 MCP 訊息、處理回應、依協定版本與能力處理互動，並維持這個 Server 的界線。它不是另一個模型，也不是提供資料的地方。

在目前的 2026-07-28 協定中，Client 會把協定版本與能力放進每個請求的 metadata（中繼資料）；Client 不應假設 Server 會因為之前同一條連線上的請求而記得這些資訊。較早的協定版本則使用初始化握手，這個版本差異會在下一篇拆解。

Server：提供明確能力的外部程式

Server 專注提供外部能力，例如讀取某種資料、列出可用工具，或產生一個可重用的提示模板。它可以是本機程序，也可以是遠端服務；MCP 不會因為 Server 是遠端或本機，就自動替它完成授權、隔離或資料驗證。

Server 提供的不是「讓模型任意執行程式」的總權限，而是透過 MCP 宣告可被發現的能力。Client 只有在看懂能力描述、Host 允許操作，且請求符合 Server 的檢查時，才應進一步呼叫它。

一次操作的責任路徑

可以把一個受控的工具操作理解成這條路徑：使用者在 Host 提出需求 → 模型或 Host 判斷需要某項能力 → 對應 Client 發送 MCP 請求 → Server 驗證並執行自己的邏輯 → 回傳結果 → Host 決定如何呈現或繼續處理。

這不是代表每次請求都一定由模型決定，也不是代表 Server 可以主動跳出對話要求使用者操作。它只是把「誰提出需求、誰傳送協定訊息、誰執行外部能力、誰負責呈現與同意」分開。分界清楚，才能在日後換 Host、增加 Server 或限制某個工具時，不必重寫整個應用。

一個容易犯的錯：把 Server 的狀態藏在連線裡

目前 MCP 的核心協定是 stateless：Server 不應把某一條連線或程序身份當成對話延續的證明。若應用真的需要跨請求保留購物車、瀏覽器工作階段或資料庫交易，應該由工具回傳明確的 handle，再由後續請求把 handle 當成參數傳回；Server 仍需在每次請求檢查授權與有效期限。

這個設計讓「Client 連到哪一台 Server」和「應用層要延續什麼工作」成為兩件事。它也使下一篇的訊息格式更重要：角色分工最後必須落在可驗證的 request、response 和 capability 上。

來源與版本邊界

本文依據 MCP 2026-07-28 Architecture 的 Host、Client、Server 定義與能力宣告；stateless 行為與跨請求狀態的處理方式見 MCP 2026-07-28 Overview 及 Tools 的狀態 handle 說明。權限與同意仍取決於實際 Host、Server 和部署設定，本文沒有把架構描述當成安全保證。