MCP 完整圖解：
從基礎概念到 2026-07-28 第五版

這篇原本是兩篇獨立的文章。第一篇寫於 2026 年 7 月 27 日，把 MCP（Model Context Protocol）的基礎概念、跟 API 的分工、還有協定架構整個講了一輪。文章才寫完隔天，官方就發布了 2026-07-28 的第五版規範，把當時花最多篇幅稱讚的 sampling 設計直接標成廢棄，連「MCP 是有狀態協定」這個定義都翻新了。這篇把兩篇合成一份完整教學：前半（第一部）從頭教基礎概念，凡是後來被 0728 版改掉的說法都會標注清楚，不會讓你學到已經過期的東西；後半（第二部）整理 0728 第五版具體改了什麼、為什麼要這樣改。

先把結論放前面：MCP 是一套公開的連線標準，讓 AI 應用程式連到外部的資料、工具跟流程，官方的定義是「an open-source standard for connecting AI applications to external systems」,Claude、ChatGPT、VS Code、Cursor 這些都已經支援。它沒有取代 API，底下多半還是在打 API，但它處理的是 API 本來就沒有在處理的那一段。

USB-C 比喻，成立在哪裡

官方文件開頭就丟了一個比喻，把 MCP 想成 AI 應用的 USB-C 埠，就像 USB-C 統一了電子設備的連接方式，MCP 統一了 AI 應用連外部系統的方式。

我覺得這個比喻好用的地方，在於它同時講了兩件事。第一件是形狀統一，同一個孔可以接螢幕、接硬碟、接電源，你不用為每個裝置準備一條專屬的線。第二件比較少人注意，插上去之後兩邊會自己協商，筆電跟螢幕會互相確認彼此支援什麼、能吃多少瓦、要不要走影像訊號，這個協商是規格的一部分，不是廠商各自實作的。

換成餐廳的說法可能更有畫面。過去每家供應商都有自己的後門，各自的開門方式、各自的驗貨流程、各自的搬運規則，你的廚房要進二十種食材，就要記二十套規矩。MCP 做的事是把後門統一改成同一種規格的卸貨碼頭，貨車開過來，接上去，倉庫會先問一句「你今天載了什麼、我這邊能收哪些」，雙方對完才開始搬。

這個「接上去之後會先互相報到」的動作，是 MCP 跟一般 API 最不一樣的地方，等一下會拆開講。

跟 API 差在哪

API 是程式對程式的介面，這件事存在幾十年了，Google Calendar 有 API、Notion 有 API、你們公司的 CRM 大概也有 API，工程師照著文件把參數組好、把回傳的 JSON 接住，功能就串起來了。

MCP 沒有要取代這件事。你去看任何一個 MCP server 的原始碼，裡面十之八九還是在打對方的 REST API。差別在於中間多了誰、還有誰在讀說明書——API 的說明書是寫給人看的，MCP 的說明書是寫給模型看的。這句話展開來，整理成表格是這樣：

表格裡「版本管理」那一列刻意寫得比較籠統，因為版本協商的具體做法，0728 版整個換了一套——以前是連線第一步做一次協商，之後整條線都算數；現在是每個請求自己帶著版本資訊。這件事跟「反向能力」那一列的 MRTR 一樣，都留到第二部拆開講，先把 server 到底能提供哪些東西看完，這部分 0728 版完全沒動。

Server 提供的三種東西

Server 端可以提供三種東西，官方文件把它們叫做 building blocks，並且明確標示了各自由誰控制：

Resources 這一塊值得多講一句。每個 resource 有自己的 URI，像 calendar://events/2024 或 file:///Documents/Travel/passport.pdf，也可以是帶參數的模板，像 travel://activities/{city}/{category}，讓應用程式能動態組出要拿的資料，輸入 Bar 的時候還可以自動補成 Barcelona。

這個三分法我覺得是 MCP 設計裡最值得學的部分。API 只有一種東西，就是端點，讀資料跟改資料在協定層級沒有區別，權限控管全靠實作的人自己拿捏。MCP 直接在規格裡分了控制權：模型可以自己決定用的（tools）、應用程式決定要不要餵進去的（resources）、只有使用者能觸發的（prompts）。這對企業內部導入的意義很大，因為你可以在介面上針對不同層級做不同的核准設計，官方文件也列了幾種做法，像是逐次跳核准視窗、對安全操作預先授權、保留完整的執行紀錄。

Client 端能力（以及後來被送走的兩個）

這部分是我覺得最容易被忽略、但價值很高的一段。除了 server 提供東西給 client,MCP 也定義了 client 可以提供給 server 的能力——原本這裡有三種，0728 版把其中兩種標成了廢棄，現在只剩一種是現行做法，但為了理解全貌，三種都還是講一遍。

誰是 host、誰是 client、誰是 server

這三個詞很多文章混著用，官方的定義很清楚。

MCP Host 是那個 AI 應用程式本身，Claude Desktop、Claude Code、VS Code 都是 host，它負責整體的使用者體驗，也負責管理底下所有的連線。

MCP Client 是 host 內部的一個元件，負責維持跟某一個 server 的連線。重點在這裡：一個 client 只服務一個 server,host 每連一個新的 server，就多開一個 client 物件。

MCP Server 是提供 context 的那支程式，可以跑在你的電腦上（例如檔案系統 server），也可以跑在別人的雲端上（例如 Sentry 官方的 server）。

官方舉的例子是 VS Code。它連上 Sentry 的 MCP server 時，執行環境會生一個 client 物件去維持這條線；接著它又連上本機的檔案系統 server，就再生一個 client 物件維持第二條線。本地跟遠端還有一個實務差別：走 stdio 的本地 server 通常只服務一個 client，走 Streamable HTTP 的遠端 server 則會同時服務很多 client。

兩層架構：一層管內容，一層管怎麼送

MCP 分成兩層，官方說資料層是內圈、傳輸層是外圈。

Data layer（資料層）定義的是訊息長什麼樣、講什麼內容，底下用的是 JSON-RPC 2.0。連線的生命週期管理、剛剛講的那三種 server 能力跟 client 能力、還有通知跟進度追蹤，都在這一層。

Transport layer（傳輸層）定義的是這些訊息怎麼送過去，目前有兩種。stdio 用標準輸入輸出直接在同一台機器上做程序間通訊，沒有網路開銷，速度最好，本機工具都走這個。Streamable HTTP 則是 client 用 HTTP POST 送訊息，需要串流的時候搭配 Server-Sent Events，遠端 server 走這個，驗證可以用標準的 HTTP 方式（bearer token、API key、自訂 header），官方建議用 OAuth 來取得 token。

先講清楚一件事：上面這張圖畫的是資料層跟傳輸層怎麼分工的整體框架，這個框架本身沒有變。但圖裡「生命週期管理」那格畫的 initialize 握手，在 0728 版已經整個拿掉了，改成每個請求自己帶版本資訊——這是第二部的重頭戲，先把基礎架構看完，細節留到第 9 節。

一次連線實際跑起來

官方文件原本給了一個完整的四步驟握手範例，不過要先說在前面：那套四步驟握手是 2025-11-25 版的做法，0728 版把它整個換掉了。所以這裡先看新版怎麼跑，舊版流程放在後面當一段簡短回顧就好。

新流程是這樣：client 可以先送一個可選的 server/discover，問一聲這個 server 支援哪些版本、有什麼能力（不問也可以，不是必要步驟）；接著直接送 tools/call，把版本跟能力資訊包在請求自己的 _meta 欄位裡帶過去，server 看這個欄位就知道怎麼處理，不需要事先握手。第二部的第 9 節會把 _meta 長什麼樣子、server/discover 怎麼回覆，拆開講清楚。

舊版做法：四步驟握手回顧

以下是舊版教的四步驟，現在已經被上面的新流程取代，放在這裡是因為理解舊版在做什麼，能幫你看懂新版省掉了哪些步驟。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": { "elicitation": {} },
    "clientInfo": { "name": "example-client", "version": "1.0.0" }
  }
}

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": {}
    },
    "serverInfo": { "name": "example-server", "version": "1.0.0" }
  }
}

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": { "location": "San Francisco", "units": "imperial" }
  }
}

多個 server 一起跑的時候

官方用一個旅遊規劃的情境把所有東西串起來，這個例子值得完整看一遍。假設有三個 server 同時連著：旅遊 server（航班、飯店、行程）、天氣 server（預報）、行事曆與郵件 server。

使用者先叫出一個 prompt，帶著參數：目的地 Barcelona、去程 6/15、回程 6/22、預算 3000、兩個人。接著挑選要納入的 resources：六月的行事曆、歐洲旅遊偏好、去年西班牙那趟的紀錄。

AI 先把這些 resources 讀進來當背景，知道哪幾天有空、偏好哪家航空、上次喜歡哪些地方，然後開始跑工具：searchFlights() 查航班、checkWeather() 查天氣，接著在需要使用者核准的地方停下來，再往下 bookHotel()、createCalendarEvent()、sendEmail()。

我覺得這才是 MCP 值得投資的地方，價值在於多個 connector 可以在同一段對話裡組起來用，單看一個 connector 會低估它。

第二部 · 2026-07-28 第五版改了什麼

2026 年 7 月 27 日才寫完上面這些基礎教學，照著當時最新的 2025-11-25 規範。文章寫完隔天，2026 年 7 月 28 日一早，官方就發布了 MCP 規範的第五個版本，前面花了不少篇幅稱讚的 sampling 設計，這一版直接標成廢棄，連「MCP 是有狀態協定」這個定義都被打掉重練。以下整理 0728 版具體改了哪些地方。

從有狀態變無狀態

前面把 MCP 比喻成跟供應商拉一條專線保持通話，連線第一步握手，之後這條線就活著，server 記得你是誰、你支援什麼，工具異動了會主動通知你。這個比喻在 0728 版之後不成立了。

新的畫面比較像每次去櫃檯辦事都自帶名片跟需求單。不需要櫃檯記得你是誰，每次遞出去的東西本身就帶齊了所有資訊，櫃檯看一眼就知道怎麼處理，辦完這次，下次再來又是重新遞一次名片，沒有誰欠誰的記憶。

具體改了什麼，規範異動紀錄列了好幾條。拿掉了整個 initialize 握手流程，也拿掉了 Mcp-Session-Id 這個連線標識用的 header。取而代之的是每一個 request 的 _meta 欄位自己帶協定版本跟 client 能力，版本不合會回一個新的 UnsupportedProtocolVersionError 錯誤。一個請求範例大概長這樣：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": { "location": "Taipei" }
  },
  "_meta": {
    "protocolVersion": "2026-07-28",
    "clientCapabilities": { "elicitation": {} }
  }
}

以前的版本協商、能力盤點是連線第一步做一次，之後整條線都算數（就是第一部第 7 節看到的舊版四步驟）。現在每一個請求都自己講清楚，這個請求跑完，這些資訊就沒有用了，下一個請求要自己重講一次。

新增了一個所有 server 都必須實作的 server/discover，用來廣播這個 server 支援哪些協定版本、有什麼能力、它是誰，client 可以在其他請求之前先問一聲，或者用它來做 STDIO 環境下的相容性探測。回應大概長這樣：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "supportedVersions": ["2026-07-28", "2025-11-25"],
    "capabilities": { "tools": {}, "resources": {} },
    "serverInfo": { "name": "example-server", "version": "2.0.0" }
  }
}

這套新流程，就是第一部第 7 節那張新舊握手比較圖畫的樣子：舊版要四步才能動手，新版一步就能動手，而且那一步(server/discover)還是可選的。

如果真的需要跨幾次呼叫記住一件事（比如一個分批上傳的任務進度到哪了），新版的做法是 server 自己發一個「handle」，當成一個普通的工具參數傳回去，下次呼叫帶著這個 handle 過去就好，不再靠協定本身幫你維持連線狀態。

原本靠長連線做的即時通知，也改用 subscriptions/listen 取代，這是一個單一的長連線 POST 回應串流，client 可以選訂自己想聽的項目，工具清單變了(toolsListChanged)、prompt 清單變了(promptsListChanged)、resource 清單變了(resourcesListChanged)，或是某個資源本身有更新(resourceSubscriptions)，各自獨立訂閱。原本的 HTTP GET 端點跟 resources/subscribe、unsubscribe 都拿掉了，連線中斷後也不再用 Last-Event-ID 這類機制去接續，直接用新的 request ID 重新送一次就好。

順帶一提一個對使用者有感的小改動，規範現在建議 tools/list 回傳的順序要固定，同樣的清單每次問到的排列都一樣。這聽起來瑣碎，但對模型來說固定順序能提升 prompt 快取的命中率，換算到使用者身上就是回應更快、消耗的 token 更少。

server 要問你事情的新方式：MRTR

第一部第 4 節提過，elicitation 這個機制在 0728 版之後走 MRTR，這裡把完整運作方式攤開講。elicitation 做的事沒變：server 執行到一半可以停下來問使用者，訂房訂到最後需要確認座位偏好，server 送一個請求過去，client 把它渲染成表單。變的是底層的實作方式。

舊版是 server 主動發起一個新請求(roots/list、sampling/createMessage、elicitation/create)，這需要 server 能夠反過來呼叫 client，等於連線得是雙向的。新版拿掉了這種 server 主動發起請求的模式，改成一套叫做 MRTR（Multi Round-Trip Requests，多輪往返請求）的做法。這個機制原本是設計來取代三種 server 主動發起的請求，不過 roots 跟 sampling 這一版直接被標成廢棄了（下一段會講），實際上會用到這個機制的場景就只剩 elicitation。

運作邏輯是這樣，server 收到請求，發現資訊不夠，不會另外開一個新請求去問，而是直接把原本那個請求的結果標成「還需要補資訊」，退回去給 client。

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "resultType": "input_required",
    "prompt": "要幫這趟訂房選哪個座位偏好?",
    "schema": {
      "type": "object",
      "properties": {
        "seatPreference": { "type": "string", "enum": ["window", "aisle"] }
      }
    }
  }
}

client 看到 resultType 是 input_required，就知道這不是最終答案，跳出對應的表單讓使用者填，填完帶著補充資訊，重新送出同一個請求，重試一次。等 server 資訊齊了，回傳的 resultType 就變成 complete。

所有的結果現在都要帶這個 resultType 欄位，舊版寫的 server 如果沒有帶這個欄位，client 這邊就直接當成 complete 處理，這是為了讓舊 server 不會整個掛掉的相容設計。順帶一提，前一版（2025-11-25）才剛加的 URL 模式 elicitation 用的 elicitationId，還有配套的 notifications/elicitation/complete 通知，這一版也一起拿掉了，因為 MRTR 改成直接重試原始請求，不再需要一個額外的 ID 去追蹤那個「還沒問完」的請求。

這個改法跟前一章的無狀態邏輯是同一套思路，server 不需要記得「之前問過什麼、你答到哪」，因為每次重試都是重新帶著完整資訊的獨立請求，狀態全部裝在請求裡帶著走，不裝在連線裡。

三個功能被送走了：Roots、Sampling、Logging

第一部花了不少篇幅講 sampling，覺得這是 MCP 設計裡很聰明的一段，server 端不用自己整合 LLM SDK、不用自己付模型的錢，需要模型幫忙判斷的時候，透過 client 去請求。結果 0728 版直接把它跟 roots、logging 一起標成廢棄，官方文件把這件事編號為 SEP-2577。

替代方案官方也講了。Sampling 原本讓 server 透過 client 請求語言模型，現在改成 server 直接整合自己選的 LLM provider API，你的 server 想要模型幫忙判斷，就自己去接 Claude 或其他模型的 API，不繞道透過 client。Roots 原本是 client 告訴 server「該專注在這幾個目錄」，改成用工具參數、resource URI 或 server 自己的設定去表達同樣的意思。Logging 原本走協定裡的 logging/setLevel，改成走 stderr 輸出或串接 OpenTelemetry。

官方的取捨邏輯是核心瘦身。這三個功能都需要 server 反過來呼叫 client，或者需要協定層級持續維持一個雙向的狀態，跟這一版全面無狀態化的主軸是衝突的。與其把它們硬塞進無狀態的框架裡搞出一堆特例，官方選擇直接移出核心，讓真的需要這些能力的人自己接現成的方案。

自己看下來，sampling 那個設計思路（不用自己整合模型、決定權留在 client）確實漂亮，但漂亮跟能不能撐住無狀態這個更大的架構目標，是兩件事。規範的取捨常常是這樣，單一功能好不好用，要讓位給整個系統扛不扛得住。

核心變小了，長出了擴展層

把 sampling、roots、logging 拿掉之後，核心協定確實變小了，但這些能力對應的需求（互動式 UI、長時間工作、結構化的操作指引）並沒有消失，官方把它們接到一個新的地方，叫 Extensions（版本化擴展框架）。

這裡的比喻可以想成主機板跟擴充卡。核心協定是主機板，規格穩定，不會因為想加一張顯卡就重新設計整片主機板的線路。Extensions 是插進主機板的擴充卡，各自處理專門的工作，卡片本身可以獨立升級、獨立版本化，主機板完全不用動。

官方目前確認的 Extensions 有三個。Tasks 處理長時間執行的工作，這件事其實在 2025-11-25 版就以實驗性功能出現過，讓耗時的請求先回應、之後再輪詢結果。0728 版把它轉正，變成正式的擴展 io.modelcontextprotocol/tasks，用 tasks/get 加 tasks/update 這組輪詢機制，取代原本會卡住整條連線的 tasks/result，原本的 tasks/list 也拿掉了。

MCP Apps 是對話裡直接渲染互動式 UI 的擴展，圖表、表單、影片播放器這類東西不用再靠文字描述，可以直接在對話裡長出來給你操作。這也是無狀態核心跟擴展框架分離之後才做得到的事，UI 這種需要持續互動的東西被劃到擴展層去處理，不用逼核心協定去背這個包袱。

Skills over MCP 是一個社群工作小組正在推的項目，讓 AI 能透過 MCP 去發現、使用結構化的 agent 工作指引，概念上跟前面熟悉的 Agent Skill 有點像，走的是 MCP 這條線去傳遞。

核心變小、擴展變多，這個方向對開發 MCP server 的人意義比較大。對使用者來說，感受到的差異會是接下來要講的 MCP Apps 跟 Tasks 這些功能在 Claude 裡實際能用了。

認證這塊終於長大了

第一部沒有花太多篇幅講認證，因為當時的重點在協定本身怎麼運作。0728 版在這塊補了很多，而且是朝著企業真的能用的方向補。

規範把認證對齊到生產級的 OAuth 2.0 跟 OIDC（OpenID Connect，一套在 OAuth 之上加了身分驗證的標準），可以串接 Microsoft Entra、Okta 這類企業身分系統。這代表一家公司要導入 MCP 的時候，不用另外幫每個 connector 建一套帳號系統，直接沿用公司原本的身分驗證機制就能管控誰能用哪個工具。

授權回應現在要求帶一個 iss 參數（對應 RFC 9207）,client 必須驗證這個欄位，目的是防範一種叫「授權碼混淆」的攻擊，簡單說就是防止有心人拿一個授權伺服器發出的授權碼，冒充成另一個授權伺服器的回應去騙過 client。

原本用來讓應用程式自己註冊成 OAuth client 的機制（Dynamic Client Registration,RFC 7591）被標成廢棄，官方改推「Client ID Metadata Documents」，同時保留向下相容，舊的 DCR 流程還能跑。新的做法是把 client 的身分資訊放在一份可以公開存取的文件裡，讓授權伺服器直接去讀，不用走一次額外的註冊來回。連帶著，client credentials 現在也規定要綁定發行它的那個授權伺服器，避免一組憑證被拿去別的地方冒用。

這幾件事合起來看，方向很一致，讓 IT 部門敢把 MCP 接進正式環境，而不是只能在個人試用階段用用看。

這些改變在 Claude 裡長什麼樣子

規範改了，實際用起來會不會有感覺，要看產品端有沒有跟上。Claude 這邊，官方 blog 列出幾件已經在做的事。

官方 blog 也引用了幾個合作夥伴的說法，包括 Figma、Intuit、Netlify、PostHog、Xero、Zoom，這些公司都已經或正在把自己的產品接上 MCP。

版本時間軸與新舊對照表

整理一張表，把第一部教的基礎說法跟 0728 版對照一遍，方便直接查。

看這張表會發現，第一部裡講得最起勁的幾段（有狀態連線的設計、sampling 的巧思、握手協商的四步驟），剛好是這次改動最大的地方。規範本身在一年多內從 2024-11-05 一路改到 2026-07-28，已經是第五版，寫協定類的說明文章大概都得習慣這種被迭代甩在後面的風險。

如果你不寫程式，這件事跟你的關係

看到這裡如果覺得細節很多，可以只留幾句話。

MCP 是一條標準化的線，讓 AI 應用接得到你的資料跟工具。這件事從頭到尾沒變，變的是接線的方式——以前比較像跟供應商拉一條專線保持通話，現在比較像每次都帶齊資料上門，不需要誰記得你是誰。

它跟 API 的分工是，API 負責讓程式拿得到資料，MCP 負責讓模型知道有這些資料、知道什麼時候該用、知道用之前要不要問你一聲。

對用 Claude 的人來說，實際感受到的會是 connector 更多（950 個以上）、對話裡開始能看到互動式的圖表跟表單、企業版的帳號管理更貼近公司原本的身分系統。這些都是規範改動之後產品端跟著做出來的東西，不用理解底層的無狀態設計，也用得到。

在你自己的工具裡，這件事的名字可能叫 connector 或整合，打開一個就是多一條線，多一條線就是多一批模型看得見的工具。下一次評估要不要開某個 connector，可以直接問兩個問題：這條線接上去之後，模型會多看到哪些東西，而那些東西我願不願意讓它看到；還有，這個 connector 需不需要問補充資訊，問的時候是不是走一個清楚的表單流程，而不是卡住整個對話乾等——這是 MRTR 這個新機制想解決的體驗問題，也是實際會摸到的地方。

規範迭代到第五版了，一年多內改了五次，0728 這一版動的刀最深。這篇大概也撐不了太久，下一次改版再看要不要繼續追。比較實際的做法可能是，往後這類文章不追單一版本的細節，改成盯著「核心變動」跟「棄用清單」這兩塊就好，畢竟這兩塊才是真的會讓手上接的 connector 失效或改行為的地方。