MCP 說明：Model Context Protocol 如何運作

Bartek Kuban
發布日期 更新日期 閱讀時間約 13 分鐘
How Model Context Protocol works 的縮圖。MCP 說明

LLM 已經能呼叫工具一段時間了，但 Model Context Protocol (MCP) 帶來的是一種結構化、標準化的做法。

不過，許多人仍然不清楚 MCP 實際上_是_什麼。

許多人以為 MCP 是一個 App、一個 API，或某種工具，但它都不是。它是一個協定，而這有非常明確的意思。

我們來拆解說明。

如果你只想看 MCP 在實務上能帶來什麼，請觀看這段短片：

什麼是協定？

協定就是一組規則，用來定義兩個或多個系統如何彼此溝通。

它本身不會做任何事。它只定義兩個實體之間對話的結構與預期。你可以把它想成一種有嚴格文法規則的共同語言，電腦依照這種語言交換資訊。

郵政系統也做類似的事。任何國家的所有郵局都遵循標準化的地址格式來寄送信件。

也可以把它想成 AI 工具的 USB-C。二十年前，市場上充斥著各種充電線與資料線。AI 生態系也曾有多種方式把工具傳給語言模型。像 LangChain、Haystack 和 Pydantic AI 這類框架，都各自定義了整合工具的格式，這表示如果開發者想為 Google Maps 撰寫一組工具，就必須針對每一種特定技術各做一次。

為了讓這件事更具體，我們來看最常見的協定 HTTP (Hypertext Transfer Protocol)，也就是支撐網站運作的協定。HTTP 定義了許多事項，包括瀏覽器（client）如何向網頁伺服器請求網頁，以及伺服器應如何回應。

以下是一個 HTTP 請求與回應週期的範例：

  1. 瀏覽器發出 HTTP 請求

當你在瀏覽器輸入 https://example.com 時，瀏覽器會向網頁伺服器送出結構化的 HTTP 請求：

以下是我們範例中使用的 HTTP 參數與值：

"GET" – 這是動作（請求一個網頁）。
"/index.html" – 被請求的特定網頁。
"HTTP/1.1" – 使用中的協定版本。
"Host: example.com" – 網站的網域名稱。
"User-Agent: Mozilla/5.0" – 發出請求的瀏覽器相關資訊。

網頁伺服器知道如何解讀這個請求，因為 HTTP 將這種格式標準化。它理解這種「語言」。

  1. 伺服器使用 HTTP 協定回應

伺服器處理請求後，送回結構化的 HTTP 回應：

"HTTP/1.1 200 OK" – 回應碼（200 表示成功）。
"Content-Type: text/html" – 回傳內容的類型。
"Content-Length: 512" – 回應的大小。
HTML Content – 實際的網頁內容（只有一個「Welcome to Example.com」標題）

重點：HTTP 本身不會_儲存_網頁或顯示網頁。它只定義網頁瀏覽器與網頁伺服器允許如何溝通的_規則_。任何遵循這些規則的系統，都可以透過 HTTP 定義的網際網路進行溝通。

MCP 作為協定如何運作

現在，我們把同樣的思路套用到 MCP (Model Context Protocol)。

MCP 是讓 AI 代理與外部工具和資料來源對話的協定。和 HTTP 一樣，它本身不儲存資料，也不執行任務。它只是定義一種標準化方式，讓 AI 向工具請求並取得資訊。

你可能會問，這些「工具」是什麼？

在 LLM 的脈絡中，工具是 AI 可以互動的外部系統、API 或服務，用來將能力擴展到文字生成之外。它們讓 AI 代理能取得即時資料、預約行程，或傳訊息給你的朋友，使其更適合真實世界的需求。

假設你問 AI 代理：

「倫敦現在幾點？」

由於 AI 本身不知道正確答案，因為 AI 模型有知識截止日期（OpenAI 模型為 2023 年 10 月），它需要從時間服務取得即時資料。但 AI 不是用 HTTP 請求網頁，而是用 MCP 請求時間資料。

過程如下：

  1. AI 代理向時間服務發出 MCP 請求（範例）
"method": "tools.call" → AI 正在呼叫外部工具。
"tool": "get_time" → 它想使用的工具名稱。
"args": { "location": "London" } → 具體的輸入參數。

就像 HTTP 一樣，這個請求遵循嚴格格式，因此任何相容 MCP 的工具都確切知道如何解讀它。

  1. MCP 時間伺服器回應

外部工具（時間伺服器）遵循 MCP 的回應規則，並送回：

"status": "success" → 確認請求已正確處理。
"result" → 包含實際的時間資料。

現在，AI 代理可以取得這份資料，並向使用者組成實際回應：

「倫敦目前時間是下午 12:20 (GMT)。」

總結並釐清常見誤解：

「MCP 是一個 App。」→ 不是，MCP 是一組規則。 你需要實作 MCP 的 AI 軟體與工具，才能真正使用它，這就像 Instagram App 需要即時的 Instagram 伺服器回應 HTTP 請求並傳遞資料。

「MCP 是資料庫。」→ 不是，MCP 不儲存資料。 它協助 AI 代理與資料庫或 API 對話。

「MCP 像 API。」→ 不完全是。API 是與某一個系統互動的特定方式，而協定（例如 MCP 或 HTTP）定義的是許多不同系統都能溝通的通用方式。MCP 是 AI 系統可用來與許多實際 API（時間、資料庫、Stripe、Slack 等）互動的一種語言。

MCP 與協定比較表

為什麼 MCP 令人興奮

現在我們知道 MCP 是 AI 軟體與外部工具和 App 互動的標準化方式，也知道 MCP 不是 API，接著來理解為什麼 AI 開發者社群（包括我們）會對它感到興奮。

由於 MCP 不是 API，而是讓 AI App 能大規模與實際 API 互動，它能協助需要連接許多外部系統的專案更快啟動。工具也會賦予模型觸及外部系統的能力，而 OpenAI Hugging Face 事件中發生的事，就是這種觸及能力超出任務範圍時的樣子。為了做到這件事，開發者有時需要經過完整的 API 整合開發週期，但現在，他們通常會使用現有函式庫或開源專案（例如 GitHub 上可取得的專案）來提供所需功能。

使用這些函式庫能加速開發，但將它們正確整合到你的系統中（如果它和你在 GitHub 上找到的實作不相容）仍然需要投入工作，才能讓工具與 AI 協同運作。

有了 MCP，只要框架就位，新增一個整合（例如整合 Google Drive）可能只需要幾行程式碼連到 Google Drive MCP 伺服器。你不會遇到相容性問題，因為雙方使用同一個協定：MCP。

我們比較兩種做法，以更清楚地看出差異。

標準整合與使用 Model Context Protocol (MCP)

為了讓比較更具體，我們逐步說明如何替 AI Agent 新增 Google Drive 檔案存取，先用手動方式，再用相容 MCP 的工具。

標準整合

  1. 尋找並改寫函式庫：你搜尋 Google Drive API client 或開源專案。Google 提供 client libraries（例如 Python 的 Google Drive API），你將它納入專案。你仍然需要確認它能在 AI 的環境中運作。

  2. 實作邏輯：你撰寫函式，例如搜尋檔案或從 Drive 取得文件。AI 需要某個東西時，必須呼叫這些函式。你將 AI 的請求格式化成 Google Drive 專用的 API 呼叫。收到 Google 的回應後，你抽取內容並傳回 AI 的 context。

  3. 處理錯誤與邊界情況：新增程式碼處理「找不到檔案」、權限錯誤或 API rate limits 等情況。如果 Google 的 API 回傳錯誤，你要捕捉它，可能回覆道歉訊息，或請 AI 改寫請求。你也需要防止 AI 在太短時間內發送過多請求。

  4. 維護：隨著時間過去，如果 Google 更新 API 或函式庫，你必須更新程式碼。如果你在函式庫中發現錯誤，可能必須修補或尋找其他來源。本質上，你成為 AI 應用程式中這個 Google Drive 整合的維護者。

這個流程也適用其他工具：想把 Slack 或資料庫加到你的 AI？你需要針對每一項工具重複整個流程。

MCP 整合

現在來看使用 MCP 時，這個流程會是什麼樣子。

首先，定義幾個關鍵概念：

Client – AI 應用程式（ChatGPT、Claude app、Quickchat AI），會建立與一個或多個伺服器的連線，並請求資訊或動作，以執行使用者提示的任務。

Server – 每個 server 可能連接到某個資料庫、API（Google Drive）之類的系統，並定義一組它可以提供的「工具」或資料。在此情境中，server 是一個程式，會把這些工具與能力公開給 Client（AI app）。

開發者可依據想做的事選擇站在哪一側：建立 server 來公開資料，或建立能與任何 server 對話的 AI client。多數人想要第二種，但我們仍先從 server 端開始，逐步了解 MCP 如何運作：

  • 初始化 MCP server。開發者或系統管理員會為某個工具或資料來源設定 MCP server。MCP server 通常只是一個實作 MCP 規格的小程式。例如，有一個可用的預先建置 Google Drive MCP server，知道如何搜尋與取得文件。

    初始化 server 時，你會授權它存取目標系統（Google Drive）。接著 server 會公開一組工具，對應它能處理的動作或查詢。它本質上是一個 API adapter，一側說 MCP，另一側說原生服務的語言。

    server 啟動後，就會等待請求。

  • 將 LLM (client) 連接到 MCP server。接著，AI 應用程式（「client」端）需要連接到該 server。實務上，如果你使用支援 MCP 的 AI 平台（例如 Claude Desktop），你會用位址或啟動 server 的指令進行設定。連接後，client 會依照 MCP 的握手流程與 server 建立 session。如果你使用 Claude 的介面，你會看到 Claude 已「connected」到某些 MCP servers（UI 可能會顯示可用的 connectors）。

加入工具後的 Claude

這是在 Claude UI 中的樣子

  • 探索可用工具。連線建立後，第一件事是找出 server 提供什麼（有時這會在你連上 server 後自動發生）。MCP client 會向 server 送出 tools/list request（這由協定定義）。server 會回覆其可用工具清單，每個工具包含名稱、描述和輸入 schema 等詳細資訊。

    例如，server 可能回應它有 create_file(path, content), read_file(path), and search_files(query) 工具可用。client 接著把這些資訊提供給 LLM。在許多實作中，client 會格式化這些工具描述，並把它們放進模型的 context（例如加入 system prompt：「你可以使用以下工具……[工具清單]」）。

System prompt

這是一段 AI system prompt，以及使用者請求目前時間的訊息

prompt 中的 MCP 工具

實作 MCP 工具後，一個名為 “get_current_time” 的工具被整合進來，讓 AI 能存取外部資源並取得倫敦的精確時間

這表示你不需要預先思考並寫好 AI app 可能需要完成某項任務的所有潛在動作。 有了 MCP，AI 可以透過詢問 MCP server 即時探索所有可能動作，並選擇所需項目。

  • 透過 MCP 使用工具。 當 AI 需要執行動作或取得資料時，它會透過 MCP 呼叫工具。從 AI 的角度來看（尤其是像 Claude 這種原生支援工具使用的模型），它會在推理中決定：「我應該用這些參數呼叫工具 X。」MCP client 會捕捉這個意圖，並以 MCP 格式向適當的 server（Google Drive MCP server）送出 tools/call request。

  • MCP server 扮演橋樑。它接收來自 AI 代理的結構化 MCP 相容請求，將其對應到正確的 Google Drive API endpoint，把請求改寫成實際的 Google Drive API 呼叫，執行請求，處理回應，然後再次重新格式化成 MCP 相容回應，再傳回 AI 代理。

    值得注意的是，MCP servers 以結構化方式處理錯誤，確保 AI Agents 能有效解讀並採取行動。

    假設 AI Agent 正使用 MCP 工具在 Google Drive 中尋找檔案。如果請求包含無效的 file ID（例如五個字元長的字串，而不是預期格式），MCP server 會回傳錯誤訊息：

    AI Agent 不會只是失敗，而是可以接收這個結構化回應，並將其改寫成使用者容易理解的回饋：

    “看起來你提供的 file ID 太短。Google Drive file ID 通常為 28 個字元。請你再檢查一次並重試。”

    這種做法能確保錯誤不會導致流程中斷，而是成為 AI Agent 引導使用者成功解決問題的機會。

  • 回答使用者的問題/請求。 MCP server 回傳結果後，MCP client 會把資料交回 AI app。模型接著將結果納入其推理，或直接放入它為使用者生成的輸出中。

    如果使用者請求建立新的 Google Sheets 檔案，server 的回覆（包含 file ID 和產生的連結）會被送進模型。模型接著會回覆使用者：「好消息！你的新 Google Sheets 檔案已準備好。你可以在這裡存取：[link]。」

MCP 運作流程

在整個過程中，AI 仍然掌控流程：它決定何時呼叫工具，以及如何使用結果形成答案。同時，開發者不需要手動編排這些步驟，MCP framework 和 AI model 會處理。最終結果是，使用者可以向 AI 提出需要外部資訊或動作的複雜問題或任務，而 AI 可以透過 MCP 自主完成這些操作並回傳結果。

使用 MCP 的好處

注意這種做法如何抽象化許多細節：client 沒有處理 API keys 或 HTTP status codes，這些都由 MCP server 處理。

重點在於整合點的簡潔性：我們「要求」取得客戶，然後得到客戶。如何取得的邏輯被封裝在其他地方。這表示負責 AI 端的開發者不需要為每個新動作撰寫新的 HTTP 呼叫，他們只要按名稱呼叫工具即可。繁重工作（auth、呼叫 Google Drive 的 endpoints、格式化回應）都在 MCP server 程式碼中完成，而這些程式碼可重用且標準化。

以下是主要好處的摘要：

  • 減少 API 專用膠水程式碼。 在 MCP 之前，要讓 AI 使用外部服務通常需要撰寫大量「膠水」程式碼：呼叫 API、把回應轉成模型能消化的文字，然後解析模型輸出，也許再呼叫另一個 API 等。有了 MCP，許多膠水都被移除。模型的 client 和 server 以結構化方式處理資料交換，因此你不需要手動把其他格式（例如 JSON）轉成文字，或反向轉換，協定會處理。你也不必撰寫邏輯來決定何時呼叫什麼。AI（由工具描述和自身推理或 prompt 引導）會處理。

  • 以可重用、共享的 connectors 取代一次性的 API wrappers。 有了 MCP，你只需撰寫一次整合，就能在許多專案與 AI 系統中重用。例如，你可以為公司的內部 wiki 建立 MCP server。任何支援 MCP 的 AI app 都能連到該 server 查詢 wiki。你不需要為每個新的 AI chatbot 或每個不同的 LLM vendor 重新實作「wiki search」。這種可重用性與過去不同，過去每個團隊可能都會為同一個 API 撰寫略有差異的整合。MCP 鼓勵建立可共享並共同改善的 connector library。

  • 與不同 LLM 的即插即用整合。 MCP 與模型無關。協定不在乎 client 是 Claude、GPT-4、DeepSeek，或任何未來模型，只要 client 能處理 MCP interface 即可。未來如果你想切換到其他模型，可以不用重寫所有整合。

  • 更容易維護。 因為它是開放標準，社群正在成長，並貢獻可直接使用的 servers（用於資料庫、熱門 API 等），你可以利用它們，而不必從零開始建置。隨著你整合更多系統，MCP 有助於避免許多點對點整合形成的「義大利麵」式混亂。而且你不需要監控其他 provider 的所有 API 更新。

API 整合會過時嗎？

傳統 API 整合和 MCP 各有其適用場景。最佳做法取決於專案性質、團隊專業和長期目標。

如果你只需要整合一兩個外部服務，而且互動相對直接，直接 API 整合通常是最快的解法。如果你的 web app 只需要在 checkout 時驗證 Stripe payment token，直接呼叫 Stripe 的 API 簡單且有效。在這種情境導入 MCP 可能有些過度。你可以用一個經審核的 HTTP Action 將 AI Agent 連接到任何有文件的 REST API，或使用一鍵整合，例如用 Google Sheets 記錄 leads 和 demo requests，而不需要執行 MCP server。

在需要非常精細控制 request/response（例如效能調校、特殊資料處理或專有協定）的情況下，直接寫入 API 可能更好。傳統整合讓你使用 API 的所有進階功能，並精確調整呼叫。如果某個 API 有不尋常的要求，或你想避免任何抽象層以取得最大清晰度與控制，傳統做法是合適的。

如需了解 MCP tools 如何與自訂 API actions 一起公開給 production AI Agent 的具體範例，請參考 Quickchat AI Agents 如何結合兩種做法。關於何時使用 MCP、個別 AI Actions，或 “Generate from Text” 的更深入討論，請見 AI Agents 的 API：從 MCP 到自訂 Endpoints。若要自行嘗試，請依照逐步指南將你的 AI Agent 連接到遠端 MCP server，讓它在對話中途呼叫即時工具。

可用 MCP servers 清單

如果你想開始使用 MCP，請查看以下 MCP servers 目錄：

你也可以不用寫任何程式碼就執行一個 server：每個 Quickchat AI Agent 都能變成 MCP server，並透過 hosted URL 讓 Claude、ChatGPT 和 Cursor 將其作為工具呼叫。連線也能朝另一個方向運作：Quickchat AI Agent 可以將供應商託管的 MCP server 作為自己的工具呼叫，這就是建立在 Calendly MCP server 上的 AI scheduling assistant如何檢查真實可用時段並從 chat 預約會議，以及 Notion AI chatbot 如何從即時 help center 回答並將 support requests 記錄回 Notion database。

Quickchat AI 也會為你的帳號執行遠端 MCP server。將它連接到 ChatGPT、Claude、Cursor 或 Codex 後，你就可以從那裡管理你的 AI Agents：analytics、conversation transcripts、knowledge base updates 和 new Agent creation，並由單一 OAuth sign-in 保護。每個 client 的設定步驟請見使用 MCP 從 ChatGPT、Claude 和 Codex 管理你的 AI Agent。

FAQ

它只能和 Claude 搭配使用嗎？

MCP 與模型無關。協定不在乎 client 是 Claude、GPT-4、本機 LLaMA 衍生模型，或任何未來模型，只要 client 能處理 MCP interface 即可。這表示當你建置工具整合時，不會被鎖定在單一 AI provider。

MCP 和一開始就把模型需要的所有資訊都給它有什麼不同？為什麼不直接把資料塞進 prompt？

MCP 從根本上不同於把資料塞進模型的 prompt，因為它讓模型能在需要時動態取得資訊，而不是使用靜態、預先載入的 prompt。把文字塞進 prompt 會遇到限制，因為 AI 模型有固定的 context window，這表示資料過多可能導致重要細節遺失、回應變慢，並增加 API 成本（因為 LLM vendors 使用依 token 計價的模型）。它也只能提供某一時間點的知識，而 MCP 能即時存取外部即時資料，並且讓 AI 採取行動，不只是讀取資訊。帶有大量 prompt 的 AI 可能知道客戶詳細資料，但無法更新紀錄或處理交易。

如果我們把_數十個_工具連到 AI，會不會讓模型不知所措，或導致它誤用工具？

這取決於實作，但目前的 LLM 在區分並從許多選項中選擇時確實有其限制。如果你向模型提供例如 50 個可能工具，它可能選錯。MCP 做法本身不會強迫你一次載入所有內容。你應該根據 context 連接相關工具。最佳實務是只連接當前任務/領域需要的工具，並利用多代理協作，也就是一種工具路由，或由一個代理先決定要考慮哪一部分工具。

MCP vs Function Calling

傳統 function calling（如 OpenAI API 或其他 LLM 中所見）允許開發者定義一組函式，把定義提供給模型，並讓模型以名稱和 arguments「呼叫」它們。這對 AI 整合是一大步，但有其限制。一個主要差異在於工具何時以及如何被定義。在典型 function calling 中，所有可能函式都必須在前期（設計階段）於 prompt 或透過 API 宣告。模型只能呼叫那些固定函式。在 MCP 中，工具可於 runtime 被探索，AI 可以查詢可用項目，甚至在 session 中途取得新工具。

MCP vs GPT Actions & Plugins

GPT Actions/Plugins 指的是 OpenAI 的生態系，你可以為 ChatGPT 啟用 plugins（例如網頁瀏覽器或 PDF reader），或使用可具備工具使用能力的「GPTs」（自訂 ChatGPT agents）。這些功能曾經令人期待，但每個 plugin 都需要自訂開發，且受限於 OpenAI 的平台。如果你想為某項任務建立 ChatGPT plugin，就必須建立 API 和 manifest，並經過 OpenAI 的核准，或至少手動啟用。每個 plugin 本質上都是一個 silo，天氣 plugin、旅遊 plugin 等，各自有自己的 endpoints 和邏輯。MCP 透過統一並開放這個概念來改進它。

MCP vs RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) 是一種為 LLM 補充外部知識庫的技術。通常，RAG 涉及 vector database 或 search index：使用者的查詢會用來取得相關文件或資料（透過 semantic search 或其他方法），這些文件會被提供給模型作為額外 context，讓模型在形成答案時「閱讀」。RAG 的重點是提供模型原本沒有的知識，對事實問答或特定領域資訊特別有幫助。不過，RAG 是唯讀的，模型會擷取文字段落，但不會執行擷取以外的動作。

相較之下，MCP 的重點是採取行動或執行任意操作，而不只是擷取資訊 context。有了 MCP，AI 可以_做_事情：寫入資料庫、傳送電子郵件、執行程式碼等。它不限於取得知識，也可以觸發外部系統的變更。因此在許多方面，RAG 和 MCP 服務的是不同目的。