Model Context Protocol 是什麼?MCP 一次搞懂

官方文件的定義很直白:MCP 是一個開放原始碼標準,用來把 Claude、ChatGPT 這類 AI 應用連上資料來源(本機檔案、資料庫)、工具(搜尋引擎、計算機)與工作流程(特製提示詞)。官方自己下的比喻是 USB-C 埠——USB-C 統一了裝置的接頭,MCP 統一了 AI 應用接外部系統的方式。

MCP 由 Anthropic 於 2024 年 11 月 25 日開源發表,創作者為 David Soria Parra 與 Justin Spahr-Summers。發表當時就同步釋出規格、SDK、Claude 桌面版的本機伺服器支援,以及一批預先寫好的伺服器(Google Drive、Slack、GitHub、Git、Postgres、Puppeteer)。現在專案已交由 Linux Foundation 旗下的 LF Projects 治理,Claude、ChatGPT、VS Code、Cursor 等主流用戶端都已支援。

沒有 MCP 的世界長什麼樣

想像你有 3 個 AI 應用,要接 5 個資料來源。沒有共同協定的話,理論上要寫 15 套整合,每套都得各自處理認證、錯誤、格式。這就是官方說的「每個新資料源都要自己的客製實作」。

有了 MCP,資料源只要實作一次伺服器端,任何支援 MCP 的 AI 應用都能接;AI 應用只要實作一次用戶端,就能吃到整個伺服器生態。這是把 M×N 的整合成本壓成 M+N——這才是 MCP 真正的價值,而不是「多了幾個好用外掛」。

🏗️ 架構:主機、用戶端、伺服器

MCP 走的是典型的主從式架構,但有三個角色要分清楚(很多人把後兩個搞混):

角色	是什麼	例子
MCP Host(主機)	協調、管理多個用戶端的 AI 應用本體	Claude Desktop、VS Code
MCP Client(用戶端)	主機為「每一台」伺服器各建一個的連線元件	VS Code 內部替 Sentry 伺服器開的連線物件
MCP Server(伺服器)	提供上下文與工具的程式	檔案系統伺服器、Sentry 伺服器

關鍵觀念:主機連幾台伺服器,就在內部生出幾個用戶端,一對一專線。而所謂「本機/遠端伺服器」講的是它跑在哪、用什麼傳輸,不是它的身分。

協定本身分兩層:

資料層(Data layer):以 JSON-RPC 2.0 為基礎的訊息協定,定義生命週期管理與核心原語。
傳輸層(Transport layer):定義通訊機制。目前兩種——stdio(本機行程間標準輸入輸出,沒有網路開銷)與 Streamable HTTP(HTTP POST 搭配可選的 SSE 串流,支援 bearer token、API key 等標準 HTTP 認證,官方建議用 OAuth 取得權杖)。

🔧 三大伺服器原語:Tools、Resources、Prompts

原語(primitives)是 MCP 最重要的概念,決定了雙方能提供什麼。伺服器可以對外暴露三種:

Tools(工具):AI 可以呼叫來「做事」的可執行函式——查資料庫、呼叫 API、動檔案。
Resources(資源):提供上下文的資料來源——檔案內容、資料庫紀錄、API 回應。
Prompts(提示詞):可重複使用的互動範本——系統提示、few-shot 範例。

每種原語都有對應的方法:*/list 用來探索、*/get 用來取用,工具另有 tools/call 可執行。用戶端先呼叫 tools/list 拿到清單,再決定要不要 tools/call。

反過來,用戶端也能對伺服器暴露原語,讓伺服器作者寫出更豐富的互動:

Sampling:伺服器反過來請主機的 LLM 產生回應(sampling/createMessage),好處是伺服器不必自己綁一家模型 SDK。
Elicitation:伺服器向使用者要更多資訊或請求確認(elicitation/create)。
Logging:伺服器把 log 訊息送給用戶端,供除錯與監控。

一個 tools/list 回應長這樣(官方範例節錄),inputSchema 是 JSON Schema,讓模型知道參數怎麼填:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "weather_current",
        "title": "Weather Information",
        "description": "Get current weather information for any location worldwide",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": { "type": "string" }
          },
          "required": ["location"]
        }
      }
    ]
  }
}

重點摘要:

伺服器三原語 = Tools(做事)/ Resources(給料)/ Prompts(範本)。
用戶端三原語 = Sampling(借模型)/ Elicitation(問使用者)/ Logging(送 log)。
探索用 */list、執行用 tools/call,清單可動態變動並以通知推播。
工具描述與 inputSchema 寫得好不好,直接決定模型會不會用錯。

🆚 MCP、Function Calling、Agent Skills 差在哪

這是本文最想釐清的一件事,三者常被混為一談,但它們在不同層次:

	解決什麼問題	誰定義	層次
Function Calling	模型如何「決定呼叫哪個函式、參數怎麼給」	各家模型 API 各自定義	模型 API 層
MCP	工具與資料源如何「被任何 AI 應用接上」	跨廠開放協定	應用整合層
Agent Skills	把工作流程與知識打包成 AI 可載入的技能	SKILL.md 開放標準	能力封裝層

白話講:Function Calling 是模型「怎麼開口叫工具」,MCP 是「工具怎麼被插上來」,而 Agent Skills 是「把做事的方法教給 AI」。三者不是互斥,實務上常常同時存在:一個 MCP 伺服器暴露的 Tools,最後仍是透過模型的 function calling 機制被呼叫。

同樣地,MCP 也不等於 RAG——RAG 是「先檢索再回答」的方法論,MCP 是「檢索得到的管道」怎麼標準化。

🔄 2026-07-28 新版規格:MCP 變成無狀態

先講結論:這是 MCP 發表以來最大幅度的改版,而且含破壞性變更。

依官方部落格(2026-05-21 鎖定 RC),下一版規格 2026-07-28 的候選版本已釋出,最終規格將於 2026 年 7 月 28 日發布;在此之前的穩定版是 2025-11-25。核心變更:

協定層無狀態化:initialize/initialized 交握被移除(SEP-2575),協定版本、用戶端資訊與能力改成隨每個請求放在 _meta 裡;新增 server/discover 方法讓用戶端主動抓伺服器能力。Mcp-Session-Id 標頭與協定層 session 也一併移除(SEP-2567)。實務效果:遠端 MCP 伺服器不再需要 sticky session 與共用 session store,任何請求可以落在任何一台實例上。
Extensions 成為一級公民:擴充以反向 DNS ID 識別、獨立於規格版號演進。本次隨附兩個官方擴充——MCP Apps(伺服器可提供在沙箱 iframe 中渲染的互動式 HTML 介面)與 Tasks(長時間工作,由 tasks/get、tasks/update、tasks/cancel 驅動)。
可路由、可快取、可追蹤:Streamable HTTP 要求帶 Mcp-Method 與 Mcp-Name 標頭,負載平衡器不必拆封包就能路由;清單與資源讀取結果新增 ttlMs 與 cacheScope;W3C Trace Context 傳播鍵名固定下來。
授權強化:六個 SEP 讓授權規格更貼近 OAuth 2.0 / OpenID Connect 實務,包含要求用戶端依 RFC 9207 驗證授權回應的 iss 參數。
Roots、Sampling、Logging 標為棄用:僅為註記層級的棄用,方法與能力旗標在本版與後續至少一年內仍可運作;替代方案分別是工具參數/資源 URI、直接串接 LLM 供應商 API、以及 stderr 與 OpenTelemetry。
治理:新的功能生命週期政策規定每個功能都有 Active / Deprecated / Removed 三階段,棄用到最早可移除之間至少間隔十二個月。

⚠️ 如果你已經照 2025-11-25 的實驗性 Tasks API 寫好東西,官方明講:必須遷移到新的生命週期。另外,資源不存在的錯誤碼從 MCP 自訂的 -32002 改為 JSON-RPC 標準的 -32602,有寫死判斷的用戶端記得改。

對一般使用者的意義其實不大——你不會摸到 _meta。真正有感的是遠端 MCP 伺服器會更好部署、更便宜,長期來看等於更多服務願意端出官方 MCP 伺服器。

🔐 資安:接上去之前一定要知道的事

MCP 讓 AI 有能力「動你的東西」,風險自然跟著來。以下依官方《Security Best Practices》整理,這些是規格文件明列的攻擊向量,不是危言聳聽:

本機伺服器 = 在你電腦上跑別人的程式

官方直白寫著:本機 MCP 伺服器是下載到你機器上執行的二進位檔,沒有適當沙箱與同意機制的話,攻擊者可以在用戶端設定裡塞入惡意啟動指令、或把惡意載荷直接包在伺服器裡。風險包含任意程式碼執行、資料外洩、資料損毀,而且使用者對執行了什麼指令毫無可見度。

官方要求用戶端在一鍵設定本機伺服器前,必須完整顯示即將執行的指令(不得截斷)、明確標示這是危險操作、並取得明確同意。

站長的實務建議:

只安裝來源可信、原始碼可讀的伺服器;npx 一行指令看起來很方便,但你有看過它跑什麼嗎?
本機伺服器優先用 stdio 傳輸——官方明說這能把存取限制在 MCP 用戶端。
別給不必要的目錄權限。檔案系統伺服器指到整顆 C 槽,跟指到一個專案資料夾,風險天差地遠。

遠端伺服器的三個經典坑

Confused Deputy(混淆代理人):MCP 代理伺服器對第三方授權伺服器使用靜態 client ID、又允許用戶端動態註冊時,攻擊者可利用既有的同意 cookie 跳過同意畫面,把授權碼導到自己的網址。緩解方式是每個 client_id 各自的同意流程加上嚴格的 redirect_uri 完全比對。
Token Passthrough(權杖直通):伺服器收下不是發給自己的權杖就往下游 API 丟。規格明文禁止:MCP 伺服器不得接受未明確發給自己的權杖。
SSRF:惡意伺服器在 OAuth 中繼資料裡塞內網位址(例如雲端 metadata 端點 169.254.169.254),誘導用戶端去打。緩解:強制 HTTPS、封鎖私有 IP 區段、驗證轉址目標。

📌 給非開發者的一句話:把「安裝一個 MCP 伺服器」想成「安裝一個有你帳號權限的桌面軟體」,而不是「裝一個瀏覽器外掛」。用這個標準去審視來源,大致就不會出事。

❓ 常見問題

Q:MCP 是 Anthropic 的專有標準嗎?
不是。它由 Anthropic 於 2024-11-25 開源提出,現由 Linux Foundation 旗下的 LF Projects 治理,ChatGPT、VS Code、Cursor 等非 Anthropic 的用戶端都支援。

Q:我不寫程式,需要懂 MCP 嗎?
需要懂的是「它會給 AI 什麼權限」。不必懂 JSON-RPC,但要看得懂你按下「連接」時,那台伺服器要求的存取範圍。

Q:MCP 伺服器一定要跑在雲端嗎?
不用。用 stdio 傳輸的本機伺服器就跑在你自己的電腦上,不經網路。

Q:Sampling 被棄用了,那伺服器還能借主機的模型嗎?
2026-07-28 版把 Sampling 標為棄用(annotation-only),方法仍可運作至少一年;官方建議的替代是伺服器直接串接 LLM 供應商 API。

🔗 延伸閱讀

📚 參考資料來源

第一級(官方)

What is the Model Context Protocol (MCP)? — MCP 官方文件 — 2026-07-10 查證
Architecture overview — MCP 官方文件 — 2026-07-10 查證
The 2026-07-28 MCP Specification Release Candidate — MCP 官方部落格 — 2026-07-10 查證
Security Best Practices — MCP 官方規格文件 — 2026-07-10 查證
Introducing the Model Context Protocol — Anthropic 官方公告(2024-11-25) — 2026-07-10 查證