2026-07-18

MCP 協定是什麼：讓AI連接企業系統的標準介面

MCP 協定是什麼？它是 Anthropic 推出的開放標準，解決 AI 模型與企業系統整合的 N×M 複雜度問題。本文拆解 Host/Client/Server 三層架構、JSON-RPC 訊息機制、Resources/Prompts/Tools 三大能力原語，以及 Stdio 與 HTTP+SSE 的傳輸取捨，幫助工程師快速理解 MCP 的設計邏輯與落地路徑。

MCP 是什麼：一句話定義與類比

先給一個工程向的定義：MCP（Model Context Protocol）是一套開放協議，規定了 LLM 應用與外部資料來源、工具、服務之間如何建立連接、交換上下文、呼叫能力。它不是某家廠商的私有 SDK，而是一個協議層標準——任何遵循該協議的客戶端和服務端，都能即插即用地完成整合。

為什麼需要一個「協議層」

做過企業系統整合的工程師都清楚一個痛點：每串接一個新系統，就要寫一套專用適配程式碼——鑑權方式不同、資料格式不同、呼叫約定不同。當 AI Agent 需要同時訪問程式碼倉庫、監控系統、工單平台、知識庫時，這種點對點的整合方式會讓維護成本隨著系統數量線性甚至二次增長。

MCP 要解決的正是這個問題：把「LLM 應用如何與外部系統對話」這件事抽象成統一規範。服務端按協議暴露能力，客戶端按協議發起請求，兩端獨立演進、互不耦合。

一個準確的類比：協議層而非產品層

官方用「USB-C 介面」來比喻 MCP 的定位——一套物理與電氣規範定義好之後，任何裝置只要符合規範就能互聯，不需要為每種外設單獨設計埠。這個類比點出了核心價值：一次實現，多端複用。某個團隊為內部知識庫寫了一個 MCP Server，不管後續接入的是編碼助手、維運 Agent 還是客服機器人，都能直接呼叫，無需重複適配。

但 USB-C 畢竟是硬體類比，對軟體工程師來說更直觀的參照是網路協議棧裡的 HTTP，或者郵件體系中的 SMTP：

• HTTP 讓任意瀏覽器能訪問任意 Web 服務，瀏覽器廠商和網站開發者各自迭代、互不阻塞；
• SMTP 讓任意郵件客戶端能向任意郵件伺服器投遞訊息，不需要 Outlook 和 Gmail 之間做專屬串接。

MCP 在 LLM 生態中扮演的角色與此一致：它定義了一組傳輸格式、能力發現機制和生命週期管理規則，讓「AI 客戶端」與「能力提供方」之間的整合變成純粹的協議串接，而非逐一編寫膠水程式碼。

開放協議意味著什麼

強調「開放」二字有具體的工程含義：

• 無廠商鎖定——協議規範公開，任何組織都可以實現自己的 Client 或 Server，不依賴特定執行時或雲平台。
• 生態可組合——社群或企業各自發布的 Server 能被不同 Client 發現並呼叫，形成網路效應。
• 漸進式採納——企業可以先為一個內部系統實現 MCP Server，驗證價值後逐步擴展，不需要一次性改造全部基礎設施。

總結成一句話：MCP 把 AI Agent 與外部世界的整合問題，從「寫 N 套客製適配」降維成「遵循一份協議規範」。後續章節會拆解它的三層架構、訊息格式和傳輸機制，看看這套協議具體如何落地到工程實現中。

架構拆解：Host、Client、Server三層模型

MCP的架構設計遵循經典的客戶端-伺服器模式，但在傳統C/S架構基礎上增加了一層抽象：Host作為頂層容器，內嵌Client來管理與多個Server的連接。這種三層模型的核心價值在於分離關注點——Host專注LLM互動體驗，Client處理協議層通訊，Server封裝具體系統能力。

Host：承載LLM的應用程式

Host是使用者直接互動的應用層，典型例子包括Claude Desktop、IDE外掛、或企業自研的AI助手。Host的職責是雙向翻譯：把使用者意圖轉化為對LLM的查詢，再將LLM返回的工具呼叫請求路由到對應的MCP Client。你可以把Host理解為「AI應用的殼」，它決定了使用者體驗的形態（桌面應用、Web介面、命令列工具），但不關心後端系統如何實現——這正是MCP 協定要解耦的部分。

一個Host內部可能同時執行多個MCP Client實例，每個Client獨立維護與一個Server的連接。當LLM需要呼叫某個工具，Host通過內部路由機制定位到管理對應連接的Client，由該Client執行實際的RPC呼叫。這種設計讓Host保持輕量，避免在主應用內堆砌各種第三方系統的SDK和適配邏輯。

Client：協議層的連接管理器

MCP Client是協議實現的核心，負責與Server建立連接、維護會話狀態、處理訊息序列化。每個Client實例與一個Server形成一對一的強繫結關係——這是MCP架構的關鍵約束。Client不是傳統意義上的「HTTP客戶端」那樣可以隨意連接任意服務端，而是在初始化時就鎖定目標Server，整個生命週期內只與該Server通訊。

這種設計簡化了協議複雜度。Client無需實現服務發現、負載均衡等分散式系統特性，只需專注兩件事：連接建立時的能力協商（通過initialize握手獲取Server支援的Resources、Prompts、Tools列表），以及執行時的訊息收發（把Host的呼叫請求轉為JSON-RPC格式，將Server響應解析後回傳）。

從工程師角度看，Client是MCP SDK提供的現成元件。無論用什麼語言實現Host，都可以直接引入官方Client庫，通過幾行配置程式碼完成Server連接：

const client = new Client({
  name: "github-integration",
  version: "1.0.0"
}, {
  capabilities: {} // 宣告Client支援的協議特性
});

await client.connect(transport); // transport可以是stdio或HTTP

Server：能力的標準化暴露層

MCP Server是整個架構中最靈活的部分，每個Server通常對應一個外部系統或資料來源。比如連接程式碼託管平台的Server暴露搜尋程式碼、建立工單等工具；連接資料庫的Server提供執行查詢、獲取表結構等能力。Server的核心職責是把異構系統的原生API翻譯成MCP 協定定義的三種原語（Resources、Prompts、Tools，下一節詳述）。

關鍵的工程優勢在於：Server是獨立程序，與Host應用解耦部署。一個企業可以用不同語言編寫連接不同內部系統的Server，Host端只需通過統一的MCP 協定呼叫，無需關心後端語言棧。這種架構讓系統整合的複雜度從「Host內部的N×M適配程式碼」降維到「N個標準化Server的獨立實現」。

Server的生命週期管理也很直接：通過stdio模式時，Host啟動Server子程序；HTTP模式下，Server作為常駐服務獨立執行。無論哪種方式，Server在收到Client的initialize請求後進入就緒狀態，開始響應後續的能力呼叫。當連接斷開時，Server可以選擇立即退出或繼續執行等待下次連接——這由Server實現者根據實際場景決定。

分層的工程價值

這種三層模型的核心優勢是關注點分離。Host開發者專注AI互動邏輯和使用者體驗，不必深入每個外部系統的API細節；Server開發者只需實現特定系統的能力封裝，無需考慮如何嵌入各種Host應用；Client作為協議層由SDK統一提供，遮蔽了傳輸細節和狀態管理。

對比傳統做法：如果要讓AI助手同時訪問GitHub、Slack、內部資料庫，要麼在Host內部整合三個SDK（導致依賴膨脹、版本衝突），要麼為每個Host-系統組合編寫專用介面卡（N×M的組合爆炸）。MCP通過標準化Server介面，把問題簡化為「實現N個Server + Host整合一次MCP Client」，大幅降低了系統整合的邊際成本。

協議底層：JSON-RPC訊息與連接生命週期

MCP在傳輸層做了一個務實的選擇：基於JSON-RPC 2.0構建整個訊息協議。這不是重新發明輪解析器，而是站在成熟標準的肩膀上——JSON-RPC 2.0已經在RPC場景經過長期驗證，規範清晰、庫支援完備、除錯工具成熟。對工程師來說，這意味著不需要為每個AI工具自定義訊息格式，除錯時看到的訊息體結構是統一的，日誌排查有現成規範可依。

三種訊息型別的職責邊界

MCP定義了三種基本訊息型別，每種都對映到JSON-RPC 2.0的標準結構：

請求（Requests）：客戶端或伺服器發起的需要響應的呼叫。訊息必須包含id欄位用於關聯響應，method指定呼叫的方法名，params承載參數。典型場景是客戶端呼叫tools/call執行工具，或伺服器通過sampling/createMessage請求LLM生成內容。

響應（Responses）：對請求的返回結果。必須包含與請求相同的id，通過result欄位返回成功資料，或通過error欄位返回標準錯誤對象（包含code、message和可選的data）。這種嚴格的請求-響應配對讓非同步通訊的狀態追蹤變得簡單。

通知（Notifications）：單向訊息，不需要也不會有響應。關鍵特徵是沒有id欄位。用於事件廣播場景，比如伺服器通過notifications/resources/updated告知客戶端某個資源已更新，客戶端可以選擇重新拉取，但不需要對通知本身做出應答。

這種分類的工程價值在於明確了通訊模式：需要確認的用請求，單向通知的用通知，避免了「這個訊息要不要回」的設計糾結。

連接的三階段生命週期

MCP連接不是建立就能直接幹活的，而是需要經歷規範的三階段握手：

初始化階段：連接建立後的第一件事是能力協商。客戶端傳送initialize請求，宣告自己的協議版本（protocolVersion）、支援的能力（capabilities）和客戶端資訊（clientInfo）。伺服器響應時同樣宣告自己的版本和能力，這是個雙向的能力對齊過程——客戶端可能支援取樣（sampling），但如果伺服器的capabilities.sampling未宣告，客戶端就不應該發起取樣請求。協商完成後，客戶端必須傳送initialized通知表示準備就緒，此時連接進入執行狀態。

這個初始化握手解決了版本相容性問題。當協議演進到2.0、3.0時，雙方在初始化時就能發現不相容的版本組合，而不是在執行中遇到無法解析的訊息才報錯。

執行階段：雙方按照協商的能力進行正常通訊。客戶端可以列舉資源（resources/list）、讀取資源內容（resources/read）、呼叫工具（tools/call）、獲取Prompt模板（prompts/list）。伺服器可以請求LLM取樣（sampling/createMessage）、傳送進度通知（notifications/progress）、廣播資源變更（notifications/resources/updated）。所有訊息都遵循JSON-RPC 2.0的格式約定。

關閉階段：任何一方都可以發起關閉。規範做法是傳送close通知（注意是通知不是請求），然後終止底層傳輸連接。接收方應該清理相關資源，不再接受新訊息。這種顯式的關閉訊號讓資源清理有章可循，避免了連接突然斷開時的狀態不一致。

工程實踐中的統一性

這套協議設計帶來的最直觀好處是除錯體驗的統一。無論是Stdio傳輸還是HTTP+SSE傳輸，抓包或日誌裡看到的都是結構相同的JSON-RPC訊息。開發者可以用通用的JSON-RPC除錯工具檢查訊息格式，錯誤碼遵循JSON-RPC標準的預留範圍（協議錯誤和伺服器自定義錯誤各有專屬區間），不需要為每個MCP伺服器學習不同的錯誤處理規範。

對庫開發者而言，可以複用現有的JSON-RPC客戶端/伺服器實現，只需要在上層封裝MCP特定的方法名和參數結構。這降低了生態工具的開發成本——你不需要從零實現一個RPC協議棧，只需要把MCP的語義對映到JSON-RPC的呼叫約定上。

連接生命週期的標準化同樣關鍵。它確保了客戶端和伺服器對「何時可以傳送什麼訊息」有共同理解。比如在初始化完成前呼叫tools/call是違反協議的，客戶端應該返回協議錯誤而不是嘗試執行。這種顯式的狀態機設計讓異常處理路徑更清晰，減少了模稜兩可的邊界情況。

從API整合的歷史看，訊息格式的標準化往往比功能介面的標準化更難達成——每家都想用自己習慣的格式。MCP選擇JSON-RPC 2.0這個既有標準，避免了「又一個RPC格式」的生態碎片化，讓工程師可以把精力放在實現MCP的Resources、Prompts、Tools這些語義層能力上，而不是糾結訊息該怎麼序列化、錯誤碼該怎麼定義。

Server三大能力原語：Resources、Prompts、Tools

MCP Server通過三種能力原語向Client暴露功能，它們分別對應 AI Agent與企業系統互動的三個層次：讀取資料、規範提示、執行操作。理解這三者的設計差異，是正確選擇整合方案的前提。

Resources：只讀的結構化資料介面

Resources是MCP中的「資料層」，每個資源擁有唯一的URI標識（如file:///project/README.md或database://users/table），本質上是只讀的、結構化的資料訪問介面。它不同於傳統REST API的地方在於：Resources強調資料的語義描述而非傳輸協議，Server在返回資料時會附帶MIME型別和後設資料，讓LLM理解「這是一份配置檔案」還是「這是一張資料表」。

典型場景是文件檢索或資料庫查詢：當用戶問「上季度銷售資料是多少」，Claude App會先通過resources/list獲取可用資源列表，找到database://sales/quarterly這個URI，再通過resources/read拉取實際資料。這種設計讓LLM可以「按需獲取」資訊，避免在初始提示詞中塞入大量上下文。

工程上的限制是Resources是pull模式：資料始終由Client主動請求，Server無法推送更新。這意味著即時性要求高的場景（如監控告警）需要配合Tools實現主動查詢邏輯。

Tools：LLM真正「做事」的入口

Tools是當前生態中支援最廣泛的能力，因為它直接對應「Agent執行動作」這個核心需求。一個Tool就是一個可執行函式，包含：

• JSON Schema定義的參數：LLM根據這個Schema決定如何傳參
• 執行邏輯：Server端的實際程式碼實現
• 返回結果：可以是文本、JSON或錯誤資訊

與傳統API的差異在於Tools的自描述性：Server通過tools/list返回所有可用工具及其參數說明，LLM通過tools/call按需呼叫。這種「發現-呼叫」模式讓Agent無需硬編碼整合邏輯，新增一個企業系統的MCP Server，Claude就能自動學會使用它的所有工具。

實際落地時，Tools是企業寫業務邏輯的主戰場——從傳送郵件、建立工單到執行SQL查詢，都封裝成Tool。Cursor僅支援Tools也印證了這一點：對程式碼編輯器而言，「修改檔案」「執行命令」這些操作性功能比資料讀取更關鍵。

Prompts：標準化的任務模板

Prompts是最容易被誤解的原語。它不是讓Server直接給LLM下指令，而是預定義的提示詞模板，用於標準化常見任務的組織方式。

舉例說明：一個程式碼審查的MCP Server可以暴露code-review這個Prompt，模板內容是「請審查以下程式碼的安全性、效能和可維護性：{{code}}」。當用戶在Claude App中選擇這個Prompt，Client會填充{{code}}參數後將完整提示詞發給LLM。這避免了使用者每次都手動輸入相同的指令字首。

工程價值在於複用和一致性：企業可以把最佳實踐固化成Prompt模板，確保所有員工使用相同的提示詞結構來完成標準化任務。但需要注意，Prompt的執行權在Client，Server只負責提供模板，不參與LLM推理。

被忽略的第四原語：Sampling

官方文件提到的Sampling原語在當前資料池中鮮有討論，但它代表了一個顛覆性的設計：Server反向請求Client完成LLM推理。

標準流程是Client呼叫LLM，然後LLM通過MCP呼叫Server的Tools。而Sampling允許Server在執行Tool時，反過來請求Client「幫我呼叫一次LLM」——比如Server需要生成一段文本摘要，或者需要LLM幫忙分析一段資料後再決定下一步操作。

這在工程上引入了遞迴呼叫的複雜性：如果Server A的Tool觸發了Sampling，Client呼叫LLM，LLM又呼叫了Server B的Tool，而Server B又觸發Sampling……這種巢狀呼叫鏈的錯誤處理和超時控制是尚未成熟的工程實踐。當前客戶端對Sampling的支援度極低，生產環境中基本不可用，但它預示了未來「多Agent協作」場景的技術方向。

能力支援的現實差異

揭示了一個關鍵現實：不同客戶端對三大原語的支援程度不同。Claude App是全能型（Resources+Prompts+Tools），而Cursor作為專用開發工具只支援Tools。這種差異源於產品定位：Claude App需要通用的資料訪問能力，Cursor只需要操作型功能。

企業選擇實施方案時，這個差異意味著：如果目標是讓AI接入資料庫做查詢分析，必須確認客戶端支援Resources；如果只是執行自動化腳本，Tools已經足夠。不要假設「實現了MCP Server就能被所有客戶端完整支援」——協議標準化了介面，但能力覆蓋度仍取決於客戶端實現。

傳輸機制的工程取捨：Stdio vs HTTP+SSE

MCP 協定在訊息格式上統一使用 JSON-RPC 2.0，但訊息如何從 Host/Client 送達 Server，取決於底層傳輸層的選擇。MCP 目前支援兩種主要傳輸機制：Stdio（標準輸入/輸出）和 HTTP with SSE（伺服器傳送事件）。這兩種機制並非一優一劣的簡單替換關係，而是針對不同部署拓撲的工程取捨——理解它們的差異，是企業落地 MCP 時繞不開的選型決策。

Stdio：本機程序間通訊的最小信任模型

Stdio 傳輸的工作方式極為直接：MCP Host 以子程序的方式啟動 MCP Server，雙方通過標準輸入（stdin）和標準輸出（stdout）交換 JSON-RPC 訊息，stderr 保留給日誌輸出。整個通訊鏈路完全封閉在本機作業系統的程序間通訊（IPC）機制內。

安全性是 Stdio 最核心的工程優勢。資料從不離開本機，不經過任何網路棧，也不存在監聽埠——這意味著沒有中間人攻擊面，沒有 TLS 配置負擔，網路層的信任邊界問題在架構上被直接消除。對於處理敏感資料的場景（如原生代碼庫分析、本地檔案讀寫、訪問本機金鑰鏈），Stdio 提供了作業系統級別的隔離保障，這是任何遠端方案都無法複製的屬性。

生命週期管理同樣簡潔：Host 啟動子程序即連接建立，子程序退出即連接終止，不存在連接池、心跳檢測或重連邏輯，故障模型與普通命令列工具一致，維運複雜度接近於零。

但 Stdio 的約束同樣結構性地明顯：

• 單客戶端限制：一個 Server 程序對應一個 Host 程序，無法被多個 Agent 或多個使用者會話同時複用。
• 本機資源消耗：每個 MCP Server 都是獨立程序，大量 Server 並行執行時，記憶體和 CPU 開銷線性疊加，全部壓在使用者本機。
• 不可遠端訪問：無法將 Stdio Server 部署到雲端或共享伺服器，跨機器呼叫在架構上不可行。

這些約束直接劃定了 Stdio 的適用邊界：單使用者、單機、敏感資料場景。

HTTP+SSE：面向分散式部署的雙通道設計

HTTP+SSE 傳輸採用了一個非對稱的雙通道架構：

• Client → Server：Client 將 JSON-RPC 訊息傳送至 Server 的訊息端點。
• Server → Client：Server 通過持久化的連接將響應、通知和進度事件推送給 Client。

這種設計充分利用了 HTTP 的既有基礎設施——負載均衡、反向代理、CDN、API閘道器都可以直接複用，無需為MCP 部署專用的網路元件。SSE 基於標準 HTTP，在受限網路環境中具有實用性。

多客戶端併發是 HTTP+SSE 的決定性優勢。一個 MCP Server 實例可以同時服務多個 Host/Client 連接，支援跨團隊共享、跨應用複用，服務端資源可以集中管理和彈性擴展。這是構建企業級共享 MCP 服務（如統一資料庫查詢服務、統一 CRM 介面）的必要條件。

然而，「資料經過遠端 Server」這一事實引入了 Stdio 完全不存在的工程問題：

信任邊界問題：請求和響應資料在網路上傳輸，Server 部署在什麼位置、由誰營運、是否記錄日誌，都成為需要明確回答的安全問題。企業在接入第三方 MCP Server 時，必須將其視為外部服務來審計，而非透明的工具呼叫。身份驗證（AuthN）和授權（AuthZ）機制需要顯式設計，OAuth 2.0 或 API Key 管理成為必要的基礎設施。

網路延遲：相比 Stdio 的本地IPC，HTTP+SSE 引入了網路往返時延（RTT）。具體延遲數字高度依賴部署拓撲（同VPC 內部、跨資料中心、公網），現有公開資料暫未提供標準化的量化基準。工程團隊在選型時應針對自身部署環境實測，而非依賴理論估算。

連接可靠性：長連接 SSE 流在網路抖動時可能中斷，需要客戶端實現重連邏輯；負載均衡器的超時配置需要與 SSE 長連接的特性匹配，否則會導致連接被提前終止。

企業選型的經驗法則

綜合上述分析，實踐中形成了一條相對清晰的經驗法則：

內部工具用 Stdio，跨團隊跨雲用 HTTP+SSE。

具體而言：

Stdio 的典型場景：開發者本機的程式碼分析 Agent、訪問本地檔案系統或資料庫的個人工具、需要處理不能出域資料的合規敏感場景。

HTTP+SSE 的典型場景：企業統一提供給多個業務團隊使用的 MCP 服務（如統一的ERP 查詢介面、統一的知識庫檢索服務）、需要橫向擴展的高併發場景、跨雲或混合雲部署中需要統一接入點的場景。

值得注意的是，兩種傳輸機制並非互斥。成熟的 MCP 實現可以讓同一個 Server邏輯同時支援兩種傳輸，在本機除錯時走 Stdio，部署到生產環境時切換到 HTTP+SSE，業務邏輯層不感知傳輸差異。這種解耦設計也是 MCP 協定分層架構帶來的工程紅利之一。

傳輸層的選擇，本質上是信任模型與部署拓撲的對映。在進入下一節討論 MCP 如何解決傳統整合的 N×M 問題之前，這一點值得工程團隊在架構評審階段明確鎖定。

核心對比——MCP如何解決傳統API整合的N×M問題

先把問題說清楚：N×M是什麼炸彈

設想一個典型的企業AI平台建設場景：你有多個AI應用（客服Bot、程式碼助手、資料分析Agent、文件生成器、維運巡檢助手），需要接入多個內部系統（CRM、ERP、GitLab、Confluence、Prometheus、MySQL、S3、釘釘通知）。

傳統做法下，每一對「AI應用 × 企業系統」的組合，幾乎都要寫一套專屬的呼叫程式碼。原因不復雜：

• CRM的REST API有自己的鑑權方式、參數命名規範和錯誤碼體系；
• ERP可能是不同風格的介面，需要單獨的序列化方式和超時策略；
• 程式碼託管平台的API有自己的認證方式和分頁邏輯；
• 監控系統往往有獨立的查詢語義，完全獨立於REST規範。

結果：每對應用與系統的組合都需要「讀文件 → 寫適配層 → 處理邊界case → 維護」，組合數量隨兩端數量的乘積增長。新增一個AI應用，需要為每個已有系統各寫一個介面卡；新增一個企業系統，每個已有應用也要各加一個介面卡。這就是N×M組合爆炸——不是比喻，是真實的維護負債。

MCP的解法：把M維坍縮為M個Server

MCP的核心架構決策是：把所有整合複雜度封裝進Server側，對Client側暴露統一語義介面。

具體來說，CRM的MCP Server負責把OAuth流程、參數轉換、錯誤碼對映全部處理掉，對外只暴露標準的Tools列表——比如search_customer、create_opportunity。AI應用側的Client程式碼只需要呼叫tools/call這一個標準動作，傳入JSON Schema約束下的參數，拿回結構化結果。

此後，無論你新增第6個還是第10個AI應用，接CRM這件事的成本是：配置指向CRM Server的連接，零行新增適配程式碼。新增一個企業系統？實現或部署一個對應的MCP Server，所有已有AI應用立刻可用。

數學結構從N×M變成了N+M：N個Client各自只與MCP 協定互動，M個Server各自封裝一個系統的複雜性，中間由協議標準連接。這正是所描述的開發時間與複雜度的系統性降低——它不是靠某個功能，而是靠架構分層實現的。

MCP真正標準化了什麼

對工程師而言，「標準化」這個詞經常被過度使用，必須具體化。

MCP確實統一的部分：

1. 參數Schema描述：所有Tools的輸入參數必須用JSON Schema定義。AI應用呼叫任何工具前，通過list_tools拿到完整的參數結構描述，無需閱讀外部文件，客戶端可以自動構造呼叫參數，甚至讓LLM自主決定參數填充。這是傳統REST整合完全缺失的能力——傳統API描述規範是可選的，不是協議強制項。

1. 呼叫語義：tools/call、resources/read、prompts/get——無論背後是資料庫還是SaaS API，呼叫動作的語義是固定的。錯誤格式也有標準定義（isError欄位+content陣列），而非各家自定義HTTP狀態碼。

1. 自描述與自動發現：list_tools、list_resources、list_prompts是協議級要求。傳統整合靠工程師「讀文件+手寫適配層」，MCP靠Server的自描述能力讓客戶端在執行時動態發現可用能力，這一機制是替代文件驅動整合的關鍵。

MCP尚未真正統一的部分：

這是大多數MCP科普文章沒有講清楚的短板：認證與鑑權（AuthN/AuthZ）的標準化程度遠弱於參數呼叫層。

MCP規範對傳輸安全有基本要求，但並未強制規定：

• Server如何驗證Client身份（OAuth？API Key？mTLS？）
• 多租戶場景下的權限隔離粒度；
• Token的生命週期管理與重新整理機制；
• 審計日誌的格式與儲存要求。

對比成熟的API閘道器方案，這些能力早已形成事實標準甚至成為託管服務。MCP目前在這一層的做法是：留給Server實現者自行決策，規範僅提供建議性描述。

這意味著在企業落地時，兩個來自不同廠商的MCP Server可能使用完全不同的認證機制，Client側仍然需要針對每個Server維護認證配置邏輯——N×M問題在介面呼叫層被解決了，但在認證層還殘留著N×M的影子。這是選型時必須直視的工程現實，而非可以忽略的細節。

傳統整合 vs MCP：工程師的日常視角

小結

MCP解決N×M問題的本質是一次分層解耦：將整合複雜度從「每對應用-系統組合」集中到「每個系統的Server實現」，同時用協議標準取代文件約定，用自描述能力取代手工適配。這對 AI Agent大規模接入企業系統具有真實的工程價值。

但工程師需要清醒認識：MCP目前是一個介面呼叫層的標準，在認證鑑權、權限管理、審計合規等企業級安全需求上，它不是API閘道器的替代品，而是需要與之配合使用的上層語義層。理解這條邊界，是企業AI整合架構設計的前提。

企業落地視角：生態支援與安全邊界

協議本身再優雅，落到企業環境裡就是一連串維運和治理問題。這一節把常見疑問拆開，給出可操作的判斷。

MCP和傳統REST API是互相替代還是可以共存？

共存是常態，替代是誤解。MCP 解決的是「AI Agent 怎麼發現並呼叫後端能力」這個標準化發現層的問題；而 REST API 是底層資料通道，大多數 MCP Server 的實現本身就是在內部呼叫已有的 REST/gRPC 介面。兩者是互補關係：MCP負責能力發現和呼叫規範化，REST/gRPC負責底層資料傳輸。企業不需要把現有 API 推倒重來，而是在其上加一層 MCP Server 做能力註冊和呼叫規範化。

企業要接入MCP，第一步該怎麼做？

建議從一個低風險、高頻呼叫的只讀場景切入——比如把內部知識庫或監控面板暴露為 MCP Server，讓編碼助手能查詢文件或檢視告警。理由有三：

• 只讀操作不涉及寫入權限，安全邊界最簡單；
• 開發團隊日常就有使用 AI 編碼工具的習慣，能快速驗證價值；
• 暴露出來的能力原語只需要用到 Tools（函式呼叫），相容性最好——目前主流客戶端對 Tools 原語的支援最為一致。

注意：如果你的場景依賴 Resources（資料訂閱）或 Prompts（提示模板注入），需要先確認目標客戶端是否支援。舉例來說，Cursor 當前僅支援 Tools 這一項能力原語，而 Claude 桌面端則覆蓋 Resources、Prompts、Tools 三項。多客戶端相容測試是選型階段容易被忽略的坑——能力原語支援不一致會導致同一個 Server 在不同客戶端上表現差異很大。

MCP現在的安全性夠不夠支撐企業生產環境？

協議層面提供了基礎框架，但企業級安全需要自己補課。具體來說：

• 訪問控制：MCP 本身不內建 RBAC 或 OAuth 流程。Server 暴露了哪些 Tools、誰能呼叫、呼叫參數是否合規——這些都需要企業在 Server 實現層自建鑑權中介軟體。「哪些內部系統對 Server 開放」這個問題本質上是在重新劃分信任邊界，相當於給 AI Agent 發一張權限工牌。
• 多租戶隔離：當多個業務團隊共享同一組 MCP Server 時，租戶間的資料隔離、呼叫上下文隔離不在協議規範範圍內，需要在 Server 閘道器層處理。
• 審計與限流：生產環境必須有呼叫審計日誌（誰在什麼時間通過哪個 Agent 呼叫了什麼 Tool、傳了什麼參數）和頻率限制。這些維運能力目前社群幾乎沒有現成方案，企業需要自行在 Server 前置一層閘道器來實現。

總結：協議安全性是「夠用但不夠完整」。把 MCP 直接暴露在生產網路、不加任何閘道器管控就上線，等同於把資料庫埠裸露在公網——技術上能跑，工程上不可接受。

接入MCP需要多大的開發成本？

分兩層看：

• 單個 Server 開發：如果只是把一個已有 REST 介面包裝成 MCP Server，核心工作量很輕——定義 Tool schema、實現呼叫轉發、處理錯誤即可。生態處於快速擴張期，社群已有大量開源 Server 實現可參考。
• 企業級治理體系：這是真正的成本大頭。包括：統一的 Server 註冊與版本管理、權限策略配置、審計日誌採集與告警、多環境部署流水線、客戶端相容性迴歸測試。這些工程投入和你管理內部微服務閘道器的成本量級相當。

一個務實的判斷：寫 Server 不難，治理 Server 才難。如果團隊有成熟的 API 閘道器維運經驗，遷移認知成本不高；如果連內部 API 管理都還沒規範化，建議先補這塊基礎設施，再考慮 MCP 接入。