AI 中的 MCP 代表什麼？模型上下文協定解析

AI 中的 MCP 代表什麼？

MCP 代表 模型上下文協定。

這是一項開放原始碼標準，用於將 AI 應用程式連接至檔案、資料庫、搜尋工具、行事曆、程式碼儲存庫及商業軟體等外部系統。官方 MCP 文件將其比喻為 USB-C 連接埠：不同裝置可以使用同一種連線標準，而不必為每種組合準備新的線材。

這個比喻很有用，但也可能讓 MCP 聽起來比實際情況更簡單。

MCP 不是 AI 模型、應用程式，也不是 API 的替代品。它是由相容的 AI 應用程式與伺服器使用的通訊標準。應用程式仍需要語言模型來理解使用者的請求，而連線的服務通常仍會在底層依賴既有的 API。

更精確的定義是：

MCP 將 AI 應用程式探索、連線及與外部工具和資料來源交換資訊的方式標準化。

「上下文」一詞很重要。語言模型只知道訓練資料中包含的內容，或目前互動期間提供給它的資訊。當需要額外資訊時，MCP 可以讓 AI 應用程式存取額外的上下文—例如最新的資料庫記錄、本機檔案，或即時 API 請求的結果—。

為什麼會建立模型上下文協定？

在 MCP 出現之前，開發人員通常必須針對 AI 應用程式與外部服務的每種組合，分別建立整合。

假設有一個 AI 助理需要與 Google Calendar、GitHub、客戶資料庫及內部計費系統協作。每個整合可能都有自己的 API 格式、驗證流程、函式定義與錯誤處理規則。

現在再想像一次：要為另一個 AI 助理重新建立相同的連線。

MCP 嘗試減少這些重複的整合工作。服務可以透過 MCP 伺服器公開其能力，而相容的 AI 應用程式則可透過共用協定進行連線。

這並不表示開發人員可以停止建立整合。仍然需要有人實作 MCP 伺服器、將其連接至底層服務、管理憑證、驗證請求並維護系統。其好處在於重複使用：一項能力遵循該協定後，可能更容易連接至多個相容的 AI 主機。

當工具、資料來源及 AI 用戶端的數量開始增加時，MCP 最有價值。若只有一個應用程式連接至一項穩定服務，直接整合 API 可能仍是更簡單的選擇。

MCP 的運作方式：主機、用戶端與伺服器

MCP 採用用戶端—伺服器架構，但由於涉及三個部分，相關術語可能令人困惑。

MCP 主機

主機是使用者互動的 AI 應用程式。它可以是聊天助理、程式設計環境、桌面應用程式或自訂 AI 代理。

主機負責協調對話、與語言模型通訊、管理權限，並決定哪些 MCP 連線可用。

MCP 用戶端

MCP 用戶端是主機內部的元件，負責維持與 MCP 伺服器的連線。

根據官方 MCP 架構，主機通常會為每部伺服器建立獨立的用戶端連線。如果應用程式連接檔案系統伺服器與行事曆伺服器，就會管理兩個 MCP 用戶端。

MCP 伺服器

MCP 伺服器是一個向 MCP 用戶端提供特定能力的程式。它可以在使用者的裝置本機執行，也可以在另一部伺服器上遠端執行。

MCP 伺服器可以公開三種核心能力：

• 工具：可執行的函式，例如查詢資料庫、建立行事曆活動或傳送訊息。
• 資源：應用程式可以讀取的資訊，例如檔案、資料庫記錄或 API 回應。
• 提示：協助建立模型互動結構的可重複使用範本。

主機與伺服器首先會協商雙方都支援的協定功能。接著，用戶端可以請求可用能力的清單。當模型判斷某項工具相關時，主機會透過 MCP 用戶端，將結構化請求路由至正確的伺服器。

結果會回傳至 AI 應用程式，成為模型產生下一個回應時的額外上下文。

一個真實的 MCP 範例：從請求到工具結果

假設開發人員向內部 AI 助理提出要求：

“檢查我們本月的 API 支出。如果超出預算 20% 以上，請為工程團隊建立警示。”

簡化後的 MCP 工作流程可能如下：

1. AI 應用程式收到請求，並將其傳送至語言模型。
2. 其 MCP 用戶端發現，連線的財務伺服器提供 get_api_usage 與 get_budget_limit。
3. 模型選取這些工具，並提供所需的日期範圍。
4. MCP 伺服器呼叫公司的計費 API，並回傳目前支出與預算。
5. 模型計算支出是否超出上限 20% 以上。
6. 如果需要發出警示，應用程式會找出已連線的訊息工具，例如 create_alert。
7. 由於此動作會變更外部系統，應用程式可以要求使用者確認。
8. 獲得核准後，訊息伺服器會呼叫底層的訊息 API。
9. 模型會告知使用者查到的結果及採取的動作。

MCP 將此流程的中間部分標準化：探索工具、描述其輸入需求、呼叫工具，以及回傳結構化結果。

它本身不會執行計算、不會提供語言模型，也不會取代計費與訊息 API。

MCP vs API vs 函式呼叫 vs RAG

這些術語經常被描述為彼此競爭的技術。實際上，它們運作於不同層級，且經常會出現在同一個應用程式中。

MCP 會取代 API 嗎？

不會。MCP 與 API 解決的是相關但不同的問題。

API 定義特定服務的呼叫方式。例如，計費 API 可能會定義一個回傳帳戶使用量的端點。

MCP 定義 AI 應用程式如何探索及使用相容伺服器公開的能力。該伺服器可能會呼叫計費 API 來取得實際資料。

換句話說：

API 將軟體連接至服務；MCP 則協助 AI 應用程式透過通用協定與多項服務協作。

當應用程式只需要一項固定功能時，直接整合 API 仍可能更快、更簡單。當開發人員希望在多個 AI 用戶端間重複使用工具，或允許可用能力動態變更時，MCP 會更具吸引力。

MCP 與函式呼叫相同嗎？

不相同。函式呼叫通常是模型的一項能力。開發人員描述一個或多個函式，而模型在判斷應使用某個函式時，會產生結構化參數。

MCP 作用於這個流程周圍。它可以協助應用程式從已連線的伺服器探索工具定義，而不必將每項工具硬式編碼至應用程式中。

模型仍可能依賴函式或工具呼叫來選取 MCP 提供的工具。

MCP 是 RAG 的一種嗎？

不是。檢索增強生成（RAG）是一種在模型回答前擷取相關資訊，並將其加入模型上下文的方法。

MCP 伺服器可以公開文件搜尋工具，作為 RAG 系統的一部分。然而，MCP 不會決定文件如何建立索引、結果如何排序，或擷取的文字如何加入提示。

MCP 可以傳遞請求與結果，搜尋工作則由檢索系統執行。

MCP 能做什麼、不能做什麼

MCP 可以讓工具在相容應用程式之間更容易重複使用，也能讓應用程式探索可用工具及其必要輸入，而不必完全依賴硬式編碼的連線。

但有些常見說法太過誇張。

MCP 不會：

• 在應用程式沒有 MCP 用戶端支援時，讓其自動相容。
• 消除底層 API 或商業邏輯的需求。
• 自動處理所有驗證與權限要求。
• 保證模型會選取正確的工具。
• 保證工具會回傳準確資料。
• 讓第三方伺服器預設安全。
• 消除監控、更新及維護整合的需求。
• 自動在連線系統之間分享所有資料。

它也不會讓模型不受限制地存取每個已連線的服務。主機控制連線的伺服器，而伺服器能力與使用者權限則決定可讀取或變更的內容。

開發人員何時應使用 MCP？

當應用程式必須連接多個工具或資料來源，尤其是這些能力可能在不同 AI 主機之間重複使用時，MCP 值得考慮。

常見情境包括：

• 搜尋文件、資料庫及支援工單的內部助理。
• 與程式碼儲存庫、問題追蹤工具及監控系統協作的程式設計代理。
• 查詢多個即時資料來源的研究應用程式。
• 讀取記錄並在其他軟體中執行核准動作的商業代理。
• 希望服務能與多個 MCP 相容用戶端協作的工具供應商。

當應用程式只有一個狹窄的工作流程、只使用一項服務，或需要精確控制每個請求的底層細節時，直接整合 API 可能是更好的選項。加入 MCP 伺服器會引入另一個需要部署、保護、測試及觀測的元件。

MCP 可以減少部分重複的整合工作，但不會消除架構上的取捨。

MCP 安全嗎？

MCP 並非自動安全或不安全。安全性取決於主機、伺服器、底層服務、驗證流程，以及授予各項動作的權限。

已連線的伺服器可能會從 AI 應用程式接收敏感資訊。具有寫入權限的工具也可能變更檔案、傳送訊息、建立記錄或觸發其他外部動作。

官方 MCP 安全性指南涵蓋的風險包括權杖傳遞、伺服器端請求偽造、工作階段劫持、遭入侵的本機伺服器，以及混淆代理人攻擊。這些是實作風險，不會因系統採用標準協定就消失，也不是使用標準協定所能自動帶來的理論優勢。

開發人員應採取幾項基本控制措施：

• 只連接信任且能夠驗證的伺服器。
• 為每部伺服器提供其所需的最低權限。
• 將唯讀工具與會變更資料的工具分開。
• 對敏感或破壞性動作要求確認。
• 驗證工具的輸入與輸出。
• 不要將憑證放入提示或工具描述中。
• 記錄工具呼叫，以便調查與稽核。
• 檢視哪些資訊可能會傳送至遠端伺服器。

OpenAI 同樣警告，自訂 MCP 伺服器可能會接收資料並執行外部動作，並建議只連接信任的伺服器。目前的實作要求 ChatGPT 對話中的寫入動作先取得確認，但開發人員不應假設每個 MCP 用戶端都採用相同政策。OpenAI 的 MCP 文件

2026 年 MCP 有哪些變化？

截至 2026 年 7 月，最新的穩定 MCP 規範仍是 2025 年 11 月 25 日發布的版本。官方專案表示，自此之後尚未發布其他規範版本。2026 MCP 路線圖描述的是計畫中的工作，而不是穩定協定中已獲保證的功能。

目前規範定義了兩種標準傳輸方式：

• stdio，用於與本機程序通訊。
• Streamable HTTP，用於遠端 MCP 伺服器。

Streamable HTTP 已取代較舊的 HTTP+SSE 傳輸方式，但用戶端與伺服器仍可保留向後相容性。目前的傳輸規範也包含涵蓋驗證、來源驗證、本機網路繫結及工作階段處理的要求與建議。

MCP 的治理也有所變化。2025 年 12 月，該協定成為 Linux Foundation Agentic AI Foundation 的創始專案。該基金會表示，目前已發布超過 10,000 部 MCP 伺服器，並已在 ChatGPT、Claude、Gemini、Microsoft Copilot、Cursor 及 Visual Studio Code 等產品中獲得採用。Linux Foundation 公告

2026 年路線圖聚焦於四個領域：傳輸擴充性、代理通訊、治理及企業就緒度。稽核軌跡、整合 SSO 的驗證、設定可攜性及閘道行為，都是仍在解決的企業問題。

最後一點很重要。MCP 已不再只是本機開發人員工具的實驗，但其企業安全性與營運模型的部分內容仍在成熟中。

GPT Proto 在 MCP 應用程式中的定位

GPT Proto 與 MCP 屬於 AI 應用程式的不同層級。

MCP 將應用程式連接至外部工具與上下文。應用程式仍需要模型來理解請求、選擇動作並產生最終回應。

該模型可以透過模型 API 供應商存取。使用 GPT Proto 模型目錄的開發人員，可以為推理層選擇文字與推理模型，而 MCP 伺服器則負責處理與外部系統的連線。

簡化的設定可能包含：

• 作為 MCP 主機的 AI 應用程式。
• 透過 GPT Proto 存取、用於推理與生成的語言模型。
• 由主機管理的一個或多個 MCP 用戶端。
• 公開外部工具與資料的 MCP 伺服器。
• 這些伺服器在底層使用的既有 API。

這兩個層級相輔相成。共用的模型 API 可以讓應用程式更容易測試或替換其背後的模型；MCP 則能在將應用程式連接至多個工具時，減少重複工作。