MCP 架構：完整技術解析與示意圖

MCP 架構是讓 MCP（Model Context Protocol，模型上下文協定）得以運作的一組基礎元件與通訊規則。MCP 是一項開源標準，而 MCP 架構則是它賴以運行的底層基礎設施。

任何 MCP 架構都包含三個核心元件，並以此為基礎建構：主機、用戶端與伺服器。MCP 的通訊框架通常被描述為由資料層與傳輸層組成。資料層是規範訊息格式的一組規則（MCP 請求以 JSON-RPC 2.0 傳送）。傳輸層則負責傳遞這些訊息，對外連線時使用 Streaming HTTP。

MCP 架構是實作 Model Context Protocol 的伺服器框架；Model Context Protocol 是一項開放標準，用於將 AI 模型連接至工具、資料庫等資源，以及可擴充輸入上下文的提示詞。這些統稱為「基元」（primitives）。最終，MCP 架構讓 LLM 能夠探索有哪些工具可用並執行工作流程，而用戶端無需定期更新。

MCP 架構示意圖：AI 應用程式與 MCP 伺服器交換請求，而 MCP 伺服器提供工具、資源與提示詞。

自 Anthropic 推出以來，MCP 架構已廣泛應用於 AI 工作流程中。這主要是因為它能取代維護負擔較重的系統（例如以多個 API 連線為基礎建構的系統），且不會犧牲效能。由於所有可用功能都位於 MCP 伺服器之後，只需要一個連線，而且更新與新增的功能都能立即提供給用戶端應用程式使用。

MCP 讓 LLM 能夠探索並呼叫可供其使用的工具、提示詞與資源，這些項目可能位於主機應用程式的本機系統上，也可能來自外部提供者。

以提供外部功能存取權的工具為例，探索是指主機向 MCP 伺服器發出 tools/list 呼叫，以找出有哪些工具可用。接著，LLM（或在某些情況下由主機）可以讀取可用工具的說明，並視需要請求使用這些工具。提示詞與資源也採用類似的流程。

MCP 架構元件示意圖：包含 LLM、協調器與用戶端的主機，分兩個步驟（先探索、再請求）連接至 MCP 伺服器，而 MCP 伺服器公開工具、資源與提示詞。

這與一直以來作為軟體開發常態的客製化 API 架構形成對比；在那種架構中，應用程式以外的功能必須透過專用連線，並以格式精確的請求來呼叫。

主機應用程式是核心的協調平台，並連接至 LLM。Perplexity 與 Claude Desktop 等知名工具都可以在 MCP 系統中擔任主機。

在簡單的工作流程中，使用者透過聊天介面提出問題。接著，主機的協調器元件會為問題加入上下文，告知 LLM 有哪些 MCP 基元可用，並附上其功能說明。

用戶端是 AI 應用程式中的一個軟體元件。MCP 提供標準介面，讓用戶端能依據主機或 LLM 的指示，與內部及外部的 MCP 伺服器通訊。它的工作是建立連線、將訊息格式化為 JSON-RPC 訊息、傳送請求並接收回應。

「MCP 主機」與「MCP 用戶端」這兩個詞有時會被混用。不過，區分兩者很有用，因為像 Perplexity 這樣的主機可能同時協調多個 MCP 用戶端。複雜的 AI 工作流程可能需要存取數十甚至數百個獨立的 MCP 伺服器，而每個伺服器都會使用個別的連線。

MCP 主機（例如 Perplexity）協調三個 MCP 用戶端的示意圖，每個用戶端各自連接至自己的 MCP 伺服器，例如資料庫、檔案或外部 API。

伺服器會公開 AI 工具可使用的所有工具。從架構的角度來看，MCP 伺服器會解讀傳入的請求，並在需要時連接至所請求的基元。

MCP 伺服器可提供三類基元的存取權：

工具：這些本質上是外部軟體功能。以傳統的 API 方式為例，網站分析應用程式可能會向外部伺服器發出格式化的請求來擷取資料。在 MCP 架構中，提供者的所有第三方功能都可透過單一連線取得，而請求則依照標準格式規則建立。
資源：資源是提供唯讀上下文的資料來源，資料庫結構描述就是一個好例子。MCP 伺服器會公開主機可使用的各種資訊來源。如果主機查詢資料庫（例如透過 LLM 產生的 SQL 搜尋），這就會被視為工具請求。
提示詞：這些是可重複使用的提示詞範本，可協助 LLM 執行特定任務。使用者或主機之所以呼叫提示詞而非工具，是因為完成任務需要現成的指示。主機應用程式中的預設任務（例如「審查程式碼」或「分析資料」選項）通常會儲存為提示詞，供使用者選擇。

另外值得注意的是，MCP 與 API 並非互斥的技術。MCP 伺服器可能會公開 API 呼叫，供回應探索請求時使用。關鍵在於，維護這些 API 的責任在於 MCP 提供者，而不是用戶端。

MCP 架構中的資料層是定義請求、回應與通知格式的一組規則。訊息的標準語言是 JSON-RPC。

所有 MCP 架構都遵循一個基本流程：(1) 由主機進行初始化與探索、(2) 由 MCP 伺服器回應，以及 (3) 由主機發出呼叫（有時由 LLM 決定），每個階段各代表一則獨立的 JSON 訊息。

MCP 資料層示意圖：使用者將提示詞傳送至主機應用程式，LLM 在其中與 MCP 用戶端協作；用戶端向 MCP 伺服器（工具、資源、提示詞）傳送請求並接收結果，最後主機將回應傳回給使用者。

讓我們透過兩個範例，看看工具探索如何運作（這些範例同樣適用於資源或提示詞）：

在 LLM 產生內容前探索工具：主機啟動 MCP 用戶端，由用戶端傳送 tools/list 請求（MCP 伺服器的可用工具清單）。LLM 會在產生內容的過程中審閱此清單，並判斷是否需要特定的工具、資源或提示詞。
讓 LLM 可以選擇執行搜尋：在代理式系統中，主機會將探索選項加入上下文輸入中，例如 search-tools，而 LLM 可在需要時請求搜尋。

工具大多是外部應用程式的功能，通常由 LLM 或主機選擇。資源與提示詞則通常應使用者要求或由主機請求。

以下是一個虛構的筆記應用程式向 MCP 伺服器發出的 tools/list 請求範例：

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

在此範例中，“id”:101 使用 ID 識別請求，讓用戶端能比對回應；而 “params” 欄位則包含有關用戶端的其他資訊，例如用戶端名稱（notes-app-client）與功能。

MCP 伺服器會回傳工具定義作為回應，其中包括可用工具的名稱及相關詳細資料。例如，清單中可能包含 add-task 工具，讓筆記應用程式能在已連接的任務管理或行事曆應用程式中建立任務，並為每項任務指定標題與優先順序。

請求可能如下所示：

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

“method” 欄位告訴 MCP 伺服器這是工具呼叫，“name” 指定要呼叫的工具，而 “arguments” 則提供必要的輸入。

如果說資料層是用戶端與 MCP 伺服器之間連線中的「傳什麼」，那麼傳輸層就是「怎麼傳」。它定義了訊息傳遞的方式：特定的通道，以及規範請求與回應如何傳遞的規則。

MCP 有兩種傳輸途徑：

標準輸入/輸出：當 MCP 伺服器與主機應用程式在同一個本機環境中執行時，就會使用這種方式。用戶端會將 JSON 請求寫入伺服器的標準輸入。伺服器讀取請求、執行所要求的操作，然後將回應寫入標準輸出。
Streamable HTTP：當 MCP 伺服器在主機應用程式外部執行時，MCP 用戶端會使用 HTTP POST 向伺服器傳送請求。伺服器會以單一 JSON 訊息回應，或以 Server-Sent Events (SSE) 串流回應；這是一種持續「監聽」的通道，讓伺服器能隨時間回傳多則訊息。

MCP 多租戶架構是一種可同時服務多個使用者（租戶）的實作方式。

在此，租戶可以是個人、一群人或一個組織。實作方式可以是為每個租戶執行獨立的 MCP 伺服器、提供單一共用伺服器的存取權，或將一組伺服器置於中央閘道之後。使用閘道時，閘道會根據使用者身分或請求性質，將請求路由至正確的端點。

它的基本原理與標準 MCP 架構相同，但個別使用者的請求會在各自的工作區中運作（即使涉及共用資源），並分別進行驗證。這種架構在企業情境中很常見，而且通常會偏好使用共用資源，因為執行多個 MCP 伺服器會造成不必要的成本。

端對端的 MCP 請求實際上是什麼樣子？它包含八個核心階段，每個階段都涉及不同的架構元件。

端對端 MCP 請求的八步驟流程圖：工具探索、使用者輸入、模型處理、工具選擇、請求、工具執行、結果與答案產生。

以下沿用前面連接至任務管理服務的筆記應用程式範例，說明 MCP 工具呼叫的實際運作方式：

工具探索：筆記應用程式（主機）透過其 MCP 用戶端發出 tools/list 請求，以取得伺服器的可用工具。伺服器會回傳這些工具的名稱、說明與預期輸入，其中包括 add-task 工具的相關資訊。這可能會在您提交提示詞之前發生。
使用者輸入：您透過應用程式內的聊天機器人，向以 LLM 為基礎的筆記應用程式提交請求，例如：「在我的行事曆中建立一項任務，以中優先順序審查我的新草稿。」
模型處理：主機將您的請求與相關的工具定義傳送給 LLM。
工具選擇：LLM 產生結構化的工具請求，指定工具及其輸入：add-task，搭配 title: Review the draft 與 priority: Medium。主機會檢查該動作是否獲得允許，並將請求傳遞給 MCP 用戶端，再由用戶端傳送 JSON-RPC 訊息。
請求：MCP 用戶端向其 MCP 伺服器傳送 tools/call 請求。
工具執行：MCP 伺服器呼叫任務管理應用程式的 API，以指定的標題與優先順序建立新任務。
結果回傳：伺服器將結果傳回 MCP 用戶端，再由用戶端傳遞給主機。主機會將結果加入提供給 LLM 的資訊中。
答案產生：LLM 使用該結果為使用者產生答案，例如「我已建立一項以中優先順序審查草稿的任務。」

MCP 與傳統 API 架構經常被混為一談，但兩者其實是互補的技術。MCP 專為 AI 應用程式而設計，能克服實作與管理多個硬式編碼 API 連線所帶來的沉重維護負擔。

透過為主機應用程式提供與每個功能提供者或內部資源之間的單一連線，MCP 有助於解決上下文輸入過於臃腫（列出所有 API）或以 API 為基礎的應用程式指令碼受限的問題。

相反地，MCP 可以將 API（更確切地說，是呼叫 API 的功能）公開為其工具清單的一部分。每當提供者更新其應用程式並推出新的 API，或文件有所變更時，只需更新 MCP 伺服器即可。主機應用程式端不需要變更任何程式碼。

自推出以來，MCP 的安全性一直備受爭議。雖然它普遍被視為安全的技術，但仍存在若干安全風險，其中許多風險在複雜的架構實作中更為明顯。

MCP 架構存在下列潛在弱點：

提示詞注入：使用者將惡意提示詞插入外部資料中，導致 AI 模型誤將其解讀為指示。
權限過高的存取：MCP 伺服器可能會向 AI 模型公開大量工具，進而擴大安全問題的潛在影響範圍（即「爆炸半徑」）。
意外資料外洩：設定不當的實作可能會導致 API 金鑰或資料庫憑證等敏感資訊被傳遞給 LLM。
本機系統遭操控：本機 MCP 伺服器與其他任何應用程式一樣，容易受到惡意指令碼等本機系統問題的影響，而且還可能對代理式 AI 系統造成下游的有害影響。

這些問題都並非無法克服。通常，只需採取既有的措施即可確保系統安全。讓人員參與流程（human in the loop）、對敏感資料實施嚴格控管，以及防範伺服器攻擊等措施，都是常見的做法。

事實證明，MCP 對開發人員而言是實用且廣受歡迎的開放標準。它克服了以 LLM 為基礎的應用程式中硬式編碼 API 的許多問題，並大幅減輕開發人員的程式編寫負擔。

展望未來，MCP 底層的主機與伺服器架構幾乎可以肯定會維持不變。未來的創新將聚焦於跨多步驟工作流程的進階代理式能力。

此外，隨著這些代理式功能逐步實作，將需要更強大的安全防護措施；而隨著 AI 系統日益龐大複雜，也將需要可擴充的架構，尤其是在傳輸層方面。

什麼是 MCP 架構？

MCP 架構元件：主機、用戶端與伺服器

主機

用戶端

伺服器

MCP 架構中的資料層是什麼？

MCP 架構中的傳輸層是什麼？

什麼是 MCP 多租戶架構？

MCP 架構圖：逐步解說

MCP 架構與傳統 API 架構有何不同？

MCP 架構安全嗎？

MCP 架構的下一步是什麼？