MCP（Model Context Protocol）是什么？一文看懂

MCP（Model Context Protocol）是什么？一文看懂 – AI百科知識

Model Context Protocol (MCP) 是 Anthropic 推出的開放協議，旨在統一大型語言模型 (LLM) 與外部數據源和工具之間的通信。它如同 AI 應用的“USB-C 接口”，提供標準化的接口，使 LLM 能夠靈活地訪問和交互各種數據與服務，從而促進 AI 的廣泛應用和生態發展。

想要了解 Model Context Protocol（MCP）嗎？它是由前沿人工智能公司 Anthropic 于 2024 年推出的一項開放協議。MCP 的目標是統一大型語言模型（LLM）與外部世界——各種數據源和工具——的溝通方式。設想一下，如果 AI 應用也有一個“通用接口”，能夠像 USB-C 一樣方便地連接不同的設備，那會怎樣？MCP 正是為此而生，它為 AI 模型提供了一個標準化的“接口”，讓它們可以輕松訪問和調用各種數據和服務，極大地推動了 AI 技術的普及和應用。

MCP 是什么？

MCP 是一種由 Anthropic 提出的開放協議，它定義了 LLM 與外部數據源和工具交互的標準。通過提供統一的接口，MCP 使得 LLM 能夠靈活地訪問和利用各種數據和服務。

背景故事

隨著 LLM 在人工智能領域的崛起，它們展現出了強大的能力，比如理解自然語言、生成文本、編寫代碼以及解決復雜問題。然而，LLM 的知識通常局限于它們所接受訓練的數據，這些數據是靜態的，并且停留在某個特定的時間點。這意味著 LLM 無法獲取實時的信息，也無法直接訪問和操作外部的私有數據源或工具。為了彌補這些不足，開發者需要將 LLM 與各種外部數據源（例如數據庫、API、文件系統）和工具（例如計算器、代碼執行環境、專業軟件）集成。傳統的集成方式，往往需要針對每個特定的數據源或工具進行定制化的接口開發，這不僅耗時費力，而且成本高昂。

舉例來說，如果一個應用需要 LLM 同時訪問數據庫、調用外部 API 并讀取本地文件，開發者可能需要編寫三套不同的接口代碼，分別處理不同的認證授權機制、數據格式和通信協議。這種“點對點”的集成模式，就像“M×N 問題”一樣，即 M 個模型需要與 N 個工具集成，理論上需要 M×N 個連接器，導致系統變得復雜且難以維護。

這種定制化的集成方式也帶來了安全風險，比如數據泄露、未經授權的訪問和惡意代碼執行等，因為每次新的集成都可能引入新的安全漏洞。因此，行業亟需一種標準化的、統一的協議來簡化 LLM 與外部世界的連接，降低集成的復雜度和成本，并提高系統的安全性和可維護性。

起源

Anthropic 將 MCP 設計為一個開放標準，積極推動其成為行業規范，鼓勵社區參與和貢獻，而非將其局限于單一廠商的技術棧。從最初發布開始，MCP 提供了詳細的規范文檔、軟件開發工具包（SDK）以及一系列參考實現，幫助開發者快速上手并參與到 MCP 生態的建設中。Anthropic 的這一舉措得到了業界的積極響應，包括 Block（前身為 Square）和 Apollo 在內的公司在其發布初期就將其集成到自身的系統中，而 Zed、Replit、Codeium 和 Sourcegraph 等開發者工具提供商也開始與 MCP 合作，增強其平臺的功能。MCP 的推出，標志著 LLM 應用開發進入了一個新的階段，通過提供一種通用的“語言”和“接口”，極大地簡化了 AI 模型與外部環境的交互，為構建更強大、更智能、更易于集成的 AI 應用奠定了堅實的基礎。

MCP 的核心目標

簡化集成流程

通過統一的協議規范，減少開發者需要編寫的定制化代碼量，從而簡化集成流程。

提升開發效率

開發者可以復用已有的 MCP 服務器實現，或者基于標準快速開發新的 MCP 服務器，加快 AI 應用的開發周期。

增強安全性，MCP 規范中包含了安全相關的考量，比如基于 OAuth 2.1 的授權機制，有助于構建更安全的 AI 應用。

促進生態發展

通過開放標準和社區協作，鼓勵更多的開發者和組織參與到 MCP 生態的建設中，開發出更多功能豐富、用途各異的 MCP 服務器，豐富 AI 模型的能力邊界，推動 AI 技術的廣泛應用和創新。

MCP 的形象比喻——“AI 應用的 USB-C 接口”

Model Context Protocol （MCP）被其創造者 Anthropic 以及業界廣泛比喻為 “AI 應用的 USB-C 接口”。這個比喻生動地揭示了 MCP 在 AI 生態系統中的核心作用和價值。正如 USB-C 接口通過其標準化、可逆、多功能的特性，極大地簡化了各種電子設備（如筆記本電腦、智能手機、平板電腦、外圍設備等）之間的連接和數據傳輸，取代了以往多種不同且互不兼容的接口（如 USB-A、Micro-USB、HDMI、VGA 等）

在 MCP 出現之前，AI 模型（尤其是大型語言模型）與外部世界的連接往往是零散的、定制化的，每個新的集成都需要開發特定的適配器和接口，就像在 USB-C 普及之前，用戶需要為不同的設備準備不同的線纜和轉換器一樣不便。

MCP 的出現，如同為 AI 世界引入了 USB-C 標準，允許 AI 模型通過一種通用的協議去“即插即用”地訪問各種 MCP 服務器（這些服務器封裝了對特定數據或工具的訪問能力）。正如 USB-C 接口能支持數據傳輸、視頻輸出、電力輸送等多種功能，MCP 也支持資源訪問、工具調用、提示管理、啟發式交互等多種核心功能，能適應多樣化的 AI 應用場景。深刻地說明了 MCP 在推動 AI 技術普及和應用創新方面所具有的潛力，有望成為連接 AI 模型與現實世界的關鍵橋梁。

MCP 的核心組件

Host（宿主）

Host 是用戶與 AI 模型進行交互的界面或應用程序。它負責接收用戶的輸入（例如問題、指令），并將這些輸入傳遞給 AI 模型進行處理。Host 也負責展示 AI 模型生成的回復或執行操作的結果給用戶。在 MCP 的交互流程中，Host 扮演著協調者的角色，理解用戶意圖，決定何時以及如何調用 MCP Client 來獲取外部數據或執行工具操作。

一個典型的 Host 例子是 Claude Desktop 應用程序，用戶可以在其中直接與 Claude 模型對話，通過 MCP 訪問本地文件系統或網絡資源。Host 需要能管理 MCP Client 的生命周期，處理與用戶交互相關的邏輯，例如權限請求、錯誤提示等。

Client（客戶端）

MCP Client 是 Host 與 MCP Server 之間的橋梁。它負責與一個或多個 MCP Server 建立連接，將 AI 模型的請求（例如，獲取特定資源、調用某個工具）封裝成符合 MCP 規范的請求消息發送給相應的 Server。Client 也負責接收來自 Server 的響應消息，將結果返回給 Host 或直接傳遞給 AI 模型。MCP Client 需要實現 MCP 協議規范，包括消息的編碼解碼、傳輸協議（如 HTTP、WebSockets、gRPC 或 stdio）的處理、以及必要的安全機制（如 OAuth 2.1 認證）。在某些實現中，MCP Client 可能內置于 Host 應用程序中，或者作為一個的庫被 Host 調用。

Server（服務器）

MCP Server 是實際提供數據或執行工具操作的組件。每個 MCP Server 封裝了對特定數據源（如數據庫、文件系統、API）或工具（如代碼解釋器、計算器、專業軟件）的訪問能力。當 MCP Server 收到來自 Client 的請求后，會根據請求的類型和參數，執行相應的操作（例如，查詢數據庫、讀取文件、調用外部 API），將結果封裝成符合 MCP 規范的響應消息返回給 Client。MCP Server 也需要實現 MCP 協議規范，對外暴露其支持的能力（Capabilities），例如提供了哪些資源、哪些工具、以及哪些提示模板。開發者可以根據 MCP 規范開發自定義的 MCP Server，以擴展 AI 模型的能力。

這種三組件架構清晰地將用戶交互、協議通信和具體功能實現分離開來，使 MCP 系統具有很好的模塊化和可擴展性。Host 專注于用戶界面和體驗，Client 處理協議層面的通信，Server 提供具體的業務邏輯和數據訪問能力。

MCP 的交互流程示例

為了更好地理解 MCP 架構中 Host、Client 和 Server 三個組件是如何協同工作的，我們可以通過一個具體的交互示例來說明。

假設用戶在 Claude Desktop（Host）中提出了一個問題：“我桌面上有哪些文檔？”。以下是處理這個請求的典型 MCP 交互流程：

用戶輸入 (User Input)：用戶在 Claude Desktop 的界面中輸入問題“我桌面上有哪些文檔？”并發送。Host（Claude Desktop）接收到這個用戶請求。
Host 處理 (Host Processing)：Host 將用戶的原始問題傳遞給其內部的 AI 模型（例如 Claude 模型）進行分析和理解。AI 模型需要判斷這個問題是否需要訪問外部資源或工具來獲取答案。
模型分析 (Model Analysis)：AI 模型分析問題后，識別出用戶意圖是獲取本地文件系統信息。模型決定需要調用一個能訪問文件系統的外部工具。在 MCP 框架下，這意味著模型會生成一個請求，指示需要調用一個特定的 MCP Tool（例如，一個封裝了文件系統瀏覽能力的 MCP Server 提供的工具）。
Client 請求 (Client Request)：Host 內部的 MCP Client 接收到 AI 模型發出的調用外部工具的指令。MCP Client 會根據指令，查找預先配置好的、能提供文件系統訪問服務的 MCP Server。然后，Client 會按照 MCP 協議規范，將模型的請求（例如，請求列出用戶桌面上的文件）封裝成一個標準的 MCP 請求消息，通過指定的傳輸方式（例如 HTTP、WebSockets 或 stdio）發送給目標 MCP Server。
Server 執行 (Server Execution)：目標 MCP Server（例如，一個專門的文件系統 MCP Server）接收到來自 Client 的請求。Server 解析請求，驗證權限（如果需要），然后執行相應的操作——在這個例子中，就是掃描用戶指定的桌面目錄，獲取文件列表。執行完畢后，MCP Server 將獲取到的文檔列表（例如，一個包含文件名、路徑等信息的 JSON 對象）封裝成一個標準的 MCP 響應消息，通過相同的傳輸方式返回給 MCP Client。
模型響應 (Model Response)：MCP Client 接收到來自 MCP Server 的響應，將其中的結果數據（即桌面文檔列表）提取出來，傳遞給 AI 模型。AI 模型接收到這些上下文信息后，結合原始問題，生成一個自然語言的回復，例如“您桌面上有以下文檔：report.docx， budget.xlsx， image.png”。
Host 展示 (Host Display)：Host（Claude Desktop）接收到 AI 模型生成的最終回復，將其在用戶界面上展示給用戶。

MCP 的核心功能

Resource（資源）

Resource 功能允許 MCP Server 向 AI 模型提供只讀的上下文信息或數據。這些資源可以是靜態數據，也可以是動態生成的數據。例如，一個 MCP Server 可以提供對公司內部知識庫的訪問，或者提供實時股票行情數據。AI 模型可以通過 MCP Client 請求這些資源，獲取完成任務所需的信息。

Resource 的設計強調只讀性，確保了數據源的安全性，防止 AI 模型意外修改原始數據。MCP 規范定義了資源發現、訂閱和通知等機制，使模型能有效地獲取和利用這些外部信息。

Prompt（提示）

Prompt 功能允許 MCP Server 提供預置的提示模板。模板可以幫助 AI 模型生成特定格式或內容的輸出，或者引導模型以特定的方式執行任務。例如，一個 MCP Server 可以提供用于生成特定類型郵件的提示模板，或者用于代碼生成的模板。

通過使用標準化的提示模板，可以提高模型輸出的質量和一致性，減少在應用程序中硬編碼提示的需求。MCP 允許服務器聲明其提供的提示模板，客戶端可以查詢并使用這些模板。

Tool（工具）

Tool 功能是 MCP 的核心特性之一，允許 AI 模型調用外部的 API 或工具來執行具體的操作。工具可以執行各種任務，例如執行計算、查詢數據庫、發送郵件、控制外部設備等。MCP Server 可以聲明提供的工具，包括工具的名稱、描述、參數列表和預期的輸出格式。AI 模型在分析用戶請求后，如果判斷需要調用某個工具，可以通過 MCP Client 向相應的 Server 發送工具調用請求。Server 執行工具并返回結果，模型再根據結果生成回復。Tool 功能極大地擴展了 AI 模型的能力邊界，不再局限于文本生成，能與現實世界進行更深入的交互。

Elicitation（啟發）

Elicitation 允許 MCP Server 在交互過程中主動向用戶請求更多信息或澄清模糊的輸入。在傳統的交互模式中，如果模型或工具需要額外的信息才能繼續執行任務，只能返回一個錯誤或提示用戶重新提問。

Elicitation 提供了一種更結構化的方式來處理這種情況。當 Server 端（通過 LLM 分析）發現當前請求缺少必要參數或意圖不明確時，可以返回一個 elicitationRequest，其中包含需要用戶提供的信息的描述或表單。Host 接收到這個請求后，可以向用戶展示相應的界面（例如，一個包含輸入框的表單），收集用戶輸入，然后通過 continueElicitation 請求將信息發送回 Server。使交互更加靈活和智能，能處理更復雜的、需要多輪對話才能完成的任務，例如交互式表單填寫、用戶意圖澄清等。

Structured Output（結構化輸出）

Structured Output 功能要求 MCP Server 以結構化的格式（例如 JSON）返回工具調用的結果。與返回非結構化的文本相比，結構化的輸出更易于 AI 模型解析和理解。MCP 規范支持為工具的輸出定義 JSON Schema，使模型可以預期返回數據的結構和類型，更準確地進行后續處理。

例如，一個查詢天氣的工具可能會返回一個包含溫度、濕度、風速等字段的 JSON 對象，而不是一段描述天氣的自然語言文本。

這種結構化的輸出提高了模型處理結果的效率，增強了系統的可靠性和可維護性。

最新的 MCP 規范（如 2025-06-18 版本）進一步強化了對結構化內容和輸出模式的支持，引入了類型化、經過驗證的結果以及靈活的 Schema 哲學和 MIME 類型清晰度。

MCP 的特點

靈活性

MCP 支持多種傳輸協議和通信方式。雖然 MCP 規范本身是于傳輸層的，明確支持包括 Streamable HTTP、WebSockets、gRPC 以及 stdio（標準輸入輸出，常用于本地進程間通信）在內的多種通信機制。多樣性使得 MCP 可以適應不同的部署環境和性能要求。

例如，對于需要低延遲、雙向實時通信的場景，WebSockets 或 gRPC 可能是更好的選擇；對于簡單的本地工具調用，stdio 更為輕量級和便捷。Streamable HTTP 允許以流式方式傳輸數據，適用于處理大量數據或需要逐步展示結果的場景。

擴展性

協議本身定義了一套核心的消息類型和交互模式，但同時也允許通過擴展（Extensions）來引入新的功能或特性。MCP 使用基于能力協商（Capability Negotiation）的機制，客戶端和服務器在初始化連接時會聲明各自支持的功能（Capabilities）。如果雙方都支持某個擴展功能，那么就可以在會話中使用該功能。機制確保了協議的向前兼容性和向后兼容性，新的功能可以在不破壞現有實現的基礎上逐步引入。

模塊化設計

MCP Server 是輕量級的程序，每個 Server 只負責暴露特定的功能或數據源。使開發者可以按需開發和部署 MCP Server，構建一個分布式的、可組合的 AI 能力網絡。

例如，一個公司可以開發一個專門訪問內部 CRM 系統的 MCP Server，另一個團隊可以開發一個連接特定數據庫的 MCP Server。

AI 應用（Host）可以通過 MCP Client 動態發現和使用這些 Server 提供的功能，像搭積木一樣組合出復雜的應用。

開放性和社區驅動

作為一個開放協議，MCP 鼓勵社區參與和貢獻，意味著會有更多的開發者為其開發新的 MCP Server、Client 庫、工具和文檔。能更快地響應市場需求，催生出更多創新的應用場景。

MCP 的安全機制

基于 OAuth 2.1 的安全機制

Model Context Protocol (MCP) 在安全方面采取基于 OAuth 2.1 授權框架。OAuth 2.1 是 OAuth 2.0 的演進版本，整合了 OAuth 2.0 最佳實踐和安全建議，提供更強大、更易用的授權解決方案。在 MCP 的交互流程中，當 MCP Client 需要訪問受保護的 MCP Server（即提供敏感數據或執行敏感操作的 Server）時，需要進行 OAuth 2.1 認證和授權。意味著 Client 需要先從授權服務器（Authorization Server）獲取一個訪問令牌（Access Token），然后在向 MCP Server 發起請求時攜帶該令牌。MCP Server 會驗證令牌的有效性（例如，通過 introspection endpoint 或 JWKS endpoint 驗證簽名和有效期），檢查令牌是否包含執行所請求操作所需的權限（scopes）。

MCP 規范特別強調了 OAuth 2.1 中的一些關鍵安全特性，如 PKCE (Proof Key for Code Exchange) 用于防止授權碼攔截攻擊，以及 令牌受眾綁定 (Token Audience Binding – RFC 8707) 用于確保訪問令牌僅能被預期的 MCP Server 使用。有效地防止了令牌的跨服務器濫用，提升了整體系統的安全性。

安全最佳實踐

Model Context Protocol (MCP) 的生態系統強調了一系列安全最佳實踐，確保在日益復雜的 AI 應用場景中維護數據安全、隱私和系統完整性。

MCP 服務器安全加固與部署實踐：部署 MCP 服務器時，應遵循最小權限原則，僅開放必要的服務和端口。操作系統應進行加固，并考慮使用安全增強工具。所有傳入的輸入（如用戶提示、工具參數）必須進行嚴格的驗證和凈化，以防止常見的 Web 攻擊，如提示注入 (prompt injection) 和參數污染。對于本地運行的 MCP 服務器，建議將其運行在容器（如 Docker，以非 root 用戶運行）或虛擬機中，以實現與主機系統的隔離。網絡訪問控制也應嚴格配置，避免將 MCP 服務器直接暴露在公共互聯網，優先使用 localhost 或私有子網進行綁定。
MCP 客戶端與工具交互安全：MCP 客戶端應基于 MCP 對 OAuth 2.1 的支持，使用短期、范圍受限的令牌進行認證。所有交互都應進行身份驗證。在工具設計方面，應為每個 Tool 提供清晰的元數據，包括其功能描述、輸入參數、預期輸出以及可能產生的副作用。對于可能修改數據或產生重大影響的工具，應使用如 readOnlyHint 和 destructiveHint 這樣的注解進行明確標記，幫助運行時環境采取適當的安全措施。
憑證和密鑰管理：是基本要求，絕對避免在配置文件中硬編碼憑證或 API 密鑰。應使用環境變量或專門的密鑰管理服務來存儲和訪問敏感信息，定期輪換密鑰。
啟用詳細日志記錄與監控：對于事后審計、異常行為檢測和安全調查至關重要。應配置 MCP 服務器和客戶端記錄所有操作日志，包括請求、響應、錯誤以及用戶交互。特別地，記錄所有發送給 AI 模型的提示 (prompts) 有助于檢測和防范提示注入攻擊。
建立 MCP Server 的治理流程：組織應建立一個正式的審批流程，用于將新的 MCP Server 添加到環境中，包括安全審查和源代碼驗證。維護一個已批準的 MCP Server 清單，考慮建立一個內部審查過的 MCP Server 倉庫，降低引入惡意或存在漏洞的 Server 的風險。

MCP 的行業應用情況

Model Context Protocol (MCP) 自推出以來，迅速獲得了業界的廣泛關注和積極采用。Anthropic 作為 MCP 的發起者，在其產品線中率先集成和支持 MCP，例如在其 Claude Desktop 應用和 Claude 模型中。

OpenAI 在 2025 年初宣布在其 Agents SDK、ChatGPT 桌面應用和 Responses API 中支持 MCP，

微軟 (Microsoft) 積極參與 MCP 生態，推出了 Playwright-MCP 服務器，使 AI 代理能像人類一樣瀏覽網頁并與網站交互。

Google 在產品中采用 MCP。

Docker 推出了 MCP Toolkit，通過提供一鍵部署、包含超過 100 個安全 MCP 服務器的目錄等功能，簡化了 MCP 服務器的部署和管理。

MCP 的應用案例

金融科技領域應用

在金融科技（FinTech）領域，幫助金融機構和科技公司構建更智能、更高效的解決方案。例如，可以用 MCP 將 LLM 連接到實時的市場數據源、客戶數據庫、風險評估模型以及交易執行系統。

智能投顧：MCP 可以使 AI 投顧系統實時獲取最新的股票價格、財經新聞、公司財報等信息（通過 Resource 功能），分析客戶的風險偏好和投資目標（可能通過 Elicitation 功能與用戶交互），然后調用交易執行工具（Tool 功能）為客戶提供個性化的投資建議并執行交易。
反欺詐分析：通過連接各種數據源（如交易記錄、用戶行為日志、黑名單數據庫），LLM 可以輔助識別可疑交易模式。
客戶服務：MCP 可以使機器人能回答常見問題，能查詢用戶的賬戶信息（在獲得授權后）、處理簡單的業務請求（如轉賬、賬單查詢），提供個性化的理財建議。通過 MCP 的標準化接口，金融機構可以更安全、更便捷地利用 LLM 的強大能力，確保數據的安全性和合規性。

醫療健康領域應用

在醫療健康領域，MCP 有潛力革新患者護理、醫學研究和醫療管理。LLM 可以通過 MCP 連接到電子健康記錄 (EHR) 系統、醫學文獻數據庫、醫學影像分析工具以及患者監測設備。

臨床決策支持：醫生可以向 AI 助手描述患者的癥狀和病史，AI 助手通過 MCP 查詢相關的醫學知識庫（Resource）、最新的臨床指南（Resource），調用診斷輔助工具（Tool），為醫生提供診斷建議和治療方案參考。MCP 的 Elicitation 功能可以用于在診斷過程中向醫生詢問更多細節，或確認關鍵信息。
個性化醫療：MCP 可以幫助整合患者的基因組數據、生活習慣數據等，為患者提供定制化的健康管理建議和疾病預防方案。
醫學研究：MCP 可以加速文獻綜述過程，幫助研究人員快速從海量文獻中提取關鍵信息，或者輔助分析臨床試驗數據。
患者監護系統：通過連接可穿戴設備和傳感器數據，實時分析患者的健康狀況，在出現異常時及時預警。MCP 的安全機制，特別是基于 OAuth 2.1 的授權，對于處理敏感的醫療數據至關重要，可以確保只有經過授權的用戶和應用才能訪問患者信息。

科技行業應用

在科技行業，MCP 的應用幾乎可以滲透到軟件開發生命周期的各個環節以及各種技術驅動的產品和服務中。

軟件開發：集成開發環境 (IDE) 可以用 MCP 將 LLM 的強大編碼能力與本地開發環境、版本控制系統（如 Git MCP Server）、調試工具、API 文檔等無縫集成。開發者可以通過自然語言指令讓 AI 助手編寫代碼、解釋代碼、生成測試用例、查找并修復 bug，部署應用。例如，開發者可以問：“在我的當前分支上運行測試，并總結失敗的原因”，AI 助手可以通過 MCP 調用 Git 工具獲取代碼，調用測試工具執行測試，然后分析日志并生成報告。
IT 運維與支持：AI 運維助手可以連接到監控系統、日志服務器、配置管理數據庫 (CMDB) 等，通過自然語言交互幫助運維人員診斷問題、執行維護任務、自動化故障排除流程。例如，AI 助手可以根據警報信息，自動查詢相關服務器的日志（通過 MCP Server 提供的日志查詢工具），分析錯誤原因，建議修復方案。
技術文檔助手：幫助用戶快速找到所需的技術信息，或者根據用戶需求生成代碼片段和配置示例。科技公司可以用 MCP 將其內部的知識庫、API 服務等封裝成 MCP Server，供內部員工或外部開發者通過 LLM 方便地訪問和使用，提高工作效率和創新能力。

MCP 的最新協議更新日志

移除 JSON-RPC 批處理支持：為了簡化規范并避免歧義，特別是在實現 Streamable HTTP 傳輸時，未發現批處理的實際需求，且 JSON-RPC 的通知/響應模型難以滿足實時性和并發調用需求，因此移除此功能。
增強工具調用結果，新增結構化輸出功能：引入了 outputSchema 和 structuredContent 字段。這一改進旨在不破壞現有 content 結構的前提下，為簡單的 JSON 輸出場景提供一個輕量級、可驗證的格式化通道。對于提升與不受信任服務器交互時的數據安全性與可靠性尤為重要，使客戶端可以更精確地解析和驗證來自工具的響應。例如，一個網絡設備狀態檢索工具可以定義一個包含設備 ID、狀態、運行時間等字段的輸出模式，確保返回數據的結構化和可驗證性。
將 MCP 服務器歸類為 OAuth 資源服務器：并添加受保護資源元數據（遵循 RFC 9728）以便發現對應的授權服務器。有助于客戶端自動發現授權服務器，避免濫用訪問令牌，提升整體安全性與部署一致性。
要求 MCP 客戶端實現遵循 RFC 8707 的 Resource Indicators：以防止惡意服務器獲取訪問令牌。通過在授權請求和令牌請求中包含 resource 參數，客戶端可以明確指定令牌所針對的目標 MCP 服務器，增強了 OAuth 2.0 授權的安全性。
支持 “Elicitation” 功能：允許服務器在交互過程中向用戶動態請求額外信息。MCP 此前缺乏標準化的方式來支持這種運行時交互，開發者往往需要依賴多步驟工具調用或自定義協議。Elicitation 機制的引入，為工作流中的確認、澄清、登錄跳轉等場景提供了結構化的輸入機制，完善了模型、用戶與服務器三者之間的雙向交互閉環。例如，在執行一個刪除操作前，服務器可以通過 elicitation 請求用戶確認；或者在需要用戶特定信息（如時區、組織名稱）時，動態向客戶端發起請求。
工具調用結果中新增資源鏈接（Resource Links）類型：為了支持工具返回對外部或大型資源的引用，不是直接嵌入其內容，引入了新的 ResourceLink 類型。解決了在交互流中直接嵌入內容不可行或效率低下的場景需求，例如延遲加載、處理大文件或臨時資源。
澄清安全注意事項及最佳實踐：在授權規范中增加了相關說明，新增了“安全最佳實踐”頁面，指導開發者構建更安全的 MCP 應用。

MCP 的發展前景

Model Context Protocol (MCP) 作為標準化 AI 模型與外部系統和數據源交互的開放協議，未來發展將聚焦于推動更廣泛的行業標準化、持續增強核心功能與安全性，以及不斷擴展其生態系統和提升互操作性。隨著人工智能技術的飛速發展和應用場景的不斷深化，MCP 致力于解決當前 AI 集成面臨的碎片化、復雜性和安全隱患等挑戰，為構建更強大、更可靠、更易于集成的 AI 應用提供堅實的基礎。社區和開發者正積極推動 MCP 的演進，適應日益增長的需求和不斷變化的技術格局。

閱讀原文