MCP (Model Context Protocol)

MCP 是什麼，跟一般說的「外掛」或「插件」有什麼不同？

MCP（Model Context Protocol，模型上下文協定）是 Anthropic 開發的開放標準，定義了 AI 助理該用什麼格式跟外部系統溝通。在 MCP 出現之前，如果你想讓 Claude 存取 Google Drive，開發者要為 Google Drive 寫一套專屬的串接程式；想再接 Slack，又要為 Slack 重新寫一套。每個服務都要客製化開發，重複的工作量很大。

MCP 官方常用的比喻是「AI 界的 USB-C」：在 USB-C 出現之前，每種電子產品都有自己的專屬接頭；USB-C 出現後，只要遵循同一套規格，任何裝置都能用同一種接口互通。MCP 做的正是同樣的事——只要一個服務照著 MCP 規格開發，任何支援 MCP 的 AI 助理都能直接連上它，不需要為每個 AI、每個服務都重新開發一次。你有時候會聽到「MCP server」「MCP client」「Plugin」這些詞混著用，簡單區分：MCP 是底層的溝通協定本身，plugin 是建立在這套協定之上、包裝好讓使用者一鍵啟用的具體套件，兩者不是同一層級的東西。

MCP 這個標準為什麼會被設計出來，解決了什麼問題？

在 MCP 出現之前，讓 AI 助理存取外部資料主要有兩種做法：一種是直接把資料複製貼上到對話裡，但這種做法沒辦法即時更新，也沒辦法處理需要互動的任務（例如「幫我在資料庫裡查詢符合條件的紀錄」）；另一種是每個服務、每個 AI 平台都各自開發一套專屬的串接程式，這代表如果你想讓十種不同的 AI 工具都能存取同一個服務，理論上要寫十套不同的串接邏輯，維護成本隨服務數量跟 AI 平台數量兩邊同時倍增。

MCP 的設計目標，就是把「AI 助理」跟「外部服務」這兩端解耦：服務端只要照 MCP 規格開發一次（開發成 MCP server），就能被所有支援 MCP 的 AI 平台使用；AI 平台端只要實作一次 MCP client，就能連上生態系裡所有照規格開發的服務。這種「一次開發、多處適用」的架構，正是 MCP 官方公告裡強調的核心價值，也是為什麼這個協定推出後，短短一年多的時間內就累積出數千個公開的第三方 MCP server。

MCP 實際上是怎麼運作的，架構上分成哪幾個角色？

MCP 的架構主要分成三個角色：Host（宿主應用程式，例如 Claude Desktop 或某個 IDE）、Client（內建在宿主應用程式裡，負責跟 MCP server 維持一對一連線並實作協定的客戶端邏輯）、以及 Server（外部服務端，把某個資料來源或工具依 MCP 規格包裝、開放出來）。實際運作時，Claude 判斷這次任務需要用到某個外部能力，Client 就會用標準化的 JSON-RPC 格式送出請求給對應的 Server，Server 處理完（例如查詢一筆 GitHub 上的資料）後，把結構化的結果送回來，Claude 再把這個結果整合進回答裡，整段過程通常在使用者感受不到明顯延遲的情況下完成。

實務上要連接一個 MCP server，目前主要有兩種途徑：一種是透過 Anthropic 官方或第三方提供的「一鍵安裝」套件（例如 Claude Desktop 裡的 Extensions 目錄，或是官方文件裡稱為 Desktop Extensions／.mcpb 檔案的封裝格式），使用者不需要碰任何設定檔，點擊安裝、依提示輸入必要的授權資訊（例如 API 金鑰）即可；另一種是手動編輯 JSON 設定檔，這種方式彈性較高，適合連接客製化或還沒有一鍵安裝套件的服務，但需要一定的技術背景。對一般使用者來說，優先找有沒有現成的一鍵安裝選項，通常是門檻最低的起手式。

了解 MCP 對我實際使用 Claude 有什麼幫助？

最直接的幫助是：當你發現自己反覆把某份資料複製貼上到 Claude 對話裡（例如每次都要手動貼上 Google Drive 文件內容、或每次都要手動整理 GitHub 上的資訊），這種重複的手動流程，通常代表存在一個對應的 MCP server 能幫你省下這個步驟——連接之後，Claude 可以直接讀取即時的資料，而不是依賴你貼上的、可能已經過時的靜態內容。

理解 MCP 也能幫你在挑選要連接哪些服務時做出更好的判斷：不是每個看起來相關的 MCP server 都值得連接，因為每連接一個服務，Claude 的可用工具清單就會變長，工具清單過度膨脹反而會讓 Claude 在判斷「這次該用哪個工具」時準確度下降。實務上的建議通常是先從三到五個真正高頻使用的服務開始連接，而不是把所有看起來有用的東西一次性全部接上。