MCP（Model Context Protocol，模型情境協定）是讓 AI 應用接上外部工具與資料的開放標準。官方把它比喻成 AI 世界的 USB-C：Host 是你正在用的 AI 應用，Client 負責連線，Server 負責提供能力，三方用 JSON-RPC 2.0 交換訊息。目前最新規範版本是 2026-07-28，官方 Tier 1 SDK 每月下載量已接近 5 億次（來源：MCP 官方部落格，2026-07-28）。
MCP 是什麼？先看官方怎麼定義
官方文件的說法是：MCP 是一個開放原始碼標準，用來把 AI 應用連接到外部系統，包含本機檔案、資料庫與各種遠端服務。它把過去每一家廠商各寫一套的工具整合，換成一套共同語言，因此也被形容為「AI 應用的 USB-C 連接埠」。
對使用者最直接的差別是：同一個 Server 寫一次，Claude、ChatGPT、VS Code、Cursor 這類 Host 都能接。官方入門文件直接點名了這幾類已經支援 MCP 的應用（來源：modelcontextprotocol.io 入門文件）。
如果你還在確認大模型本身的運作原理，可以先看站上的 大模型是什麼？2026 最新白話入門與選型重點，再回來讀 MCP 會更順。
三層架構：Host、Client、Server 各自負責什麼
MCP 的架構刻意切成三層，原因是把「誰負責安全把關」與「誰負責連線」分開。Host 是使用者信任的邊界，所有授權與同意都發生在這裡；Client 只負責與某一個 Server 建立一對一連線；Server 則是把外部系統包成標準介面的一方。
| 層級 | 角色 | 負責什麼 | 常見例子 |
|---|---|---|---|
| Host | 宿主程式 | 跑 AI 模型、管理多個 Client、取得使用者同意、把工具結果餵回模型 | Claude Desktop、Claude Code、ChatGPT、VS Code、Cursor |
| Client | 連接器 | 與單一 Server 建立一對一連線，送出請求與接收結果 | 各 Host 內建的 MCP client 實作 |
| Server | 能力提供者 | 把外部系統包成 Tools、Resources、Prompts 三種標準介面 | 檔案系統、資料庫、GitHub、Slack、內部 API |
一個 Client 只連一個 Server
這是 MCP 常見的誤解。Host 可以同時開很多 Client，但每個 Client 只對應一個 Server。你要接三個工具，就是三個連線，Host 負責把它們的工具清單彙整成一份給模型看。
Server 能提供什麼：Tools、Resources、Prompts
三大原語（primitive）的分工要看「誰決定何時使用」。Tools 由模型決定要不要呼叫，Resources 由應用決定要不要讀進來，Prompts 則由使用者主動挑選。
| 原語 | 由誰提供 | 做什麼 | 典型用途 |
|---|---|---|---|
| Tools 工具 | Server | 可以被模型呼叫、真正執行並改變狀態的動作 | 查資料庫、寄信、發文、跑腳本、呼叫內部 API |
| Resources 資源 | Server | 可被讀取的內容，像檔案或紀錄，讀取本身沒有副作用 | 讀設定檔、資料表欄位說明、日誌片段 |
| Prompts 提示 | Server | 預先寫好的模板工作流，讓使用者一鍵套用 | 固定格式的週報、程式碼審查清單 |
| Elicitation 詢問 | Client | Server 需要補資料時，由 Client 反問使用者 | 補齊參數、執行前的二次確認 |
傳輸方式：本機用 stdio，遠端用 Streamable HTTP
傳輸層決定 Client 怎麼找到 Server。本機工具走標準輸入輸出（stdio），Server 就是 Host 啟動的子程序；遠端共享的 Server 走 Streamable HTTP，單一端點收 POST，需要串流時再升級為 Server-Sent Events。早期版本的 HTTP 加 SSE 傳輸已經被取代，官方對舊功能設有最短 12 個月的棄用期（來源：2026-07-28 規範變更說明）。
| 傳輸方式 | 適用場景 | 連線維持 | 認證 |
|---|---|---|---|
| stdio | 本機子程序，單一使用者自己的工具 | 常駐執行，跟隨 Host 的生命週期 | 繼承本機權限，通常不需要額外認證 |
| Streamable HTTP | 遠端共享 Server，新專案的建議首選 | 單一端點 POST，可升級為 SSE 串流 | 以 OAuth 2.1 為基礎，強制使用 PKCE |
| 舊版 HTTP + SSE | 既有部署還在用，新專案不建議 | 長連線 Event Stream | 多為自帶 token 的手工做法 |
2026-07-28 規範改了什麼
這一版把協定往「無狀態、好部署」的方向推，對工程團隊最實際的變化有這幾項：
- 逐請求能力宣告：每個請求都在
_meta裡帶上協定版本與 client 能力，不再靠開場握手。舊版的initialize握手與 session 機制因此退場，改成無狀態、每個請求自帶完整資訊。 - 多輪往返請求（Multi Round-Trip Requests）：當 Server 需要使用者補資料時，回傳
input_required的中間結果，Client 補完後重送原請求。每個結果都新增必填的resultType欄位。 - 探索機制：新增
server/discover，讓 Client 先問清楚 Server 支援哪些版本與能力。 - 錯誤碼分段：JSON-RPC 的 server error 區間被切成實作自訂與規範保留兩段，方便生態系共用。
- 官方擴充（extensions）：Tasks、MCP Apps、Skills over MCP 等能力以擴充形式發布，Server 與 Client 各自宣告要不要支援。
- 生命週期政策：正式採用功能生命週期與棄用政策，棄用期最短 12 個月，並維護一份棄用清單。
如果你的程式中還留著舊版寫法，先確認 SDK 版本再升級，官方在每個 SDK 的 release note 都會標註破壞性變更。
官方 SDK 有哪些語言
官方用分層制管理 SDK，語言清單以 modelcontextprotocol.io 的 SDK 頁面為準。分層不代表功能閹割，而是反映維護資源與回應速度。
| 層級 | 語言 | 維護狀況 |
|---|---|---|
| Tier 1 | TypeScript、Python、C#、Go | 官方主要資源投入，約 40 位維護者；這一層每月下載量接近 5 億次 |
| Tier 2 | Java、Kotlin、PHP、Ruby、Swift | 功能完整但規模較小；Ruby 官方 SDK 已發布 1.0 並達到 Tier 2 標準 |
| Tier 3 | 其餘語言 | 由社群或廠商自行維護，官方不保證回應速度 |
依照官方在 2026-07-28 發布時公布的數字，TypeScript 與 Python SDK 都已跨過累計 10 億次下載。
該不該自己寫 MCP Server？
多數人其實不需要寫 Server。先確認需求，再決定要不要動協定層，可以省下大量時間。
- 先找現成的。官方 Registry與下游市集已經收錄大量 Server，涵蓋 GitHub、Slack、資料庫、瀏覽器自動化等常見需求。Registry 要求發布者驗證命名空間（GitHub、DNS 或 HTTP 驗證），找的時候仍要看維護時間與授權。
- 只有本機自己用，就寫 stdio。不需要處理 OAuth 與部署，程式碼通常幾十行就能跑。
- 要給團隊或產品用，寫 Streamable HTTP。必須實作授權與 token 驗證，並且把 Server 當成正式服務維運。
- 先確認是不是提示詞就能解。如果只是想要固定輸出格式，寫一段提示或做一個自訂 GPT 往往比寫 Server 快。
要接的是程式碼代理工作流的話，站上已經有實戰教學：OpenAI Codex CLI 上手教學與 AI 編程工具四強比較可以先看一輪，再回來決定要不要讓代理接上你自己的服務。
安全與治理：四件事一定要知道
- 工具就是程式碼。官方安全章節把工具執行視為任意程式碼執行，Host 必須在使用者同意下才呼叫，並且在執行前顯示要跑什麼。
- Token 不可以透傳。遠端授權的規範明確禁止把上游取得的 token 直接交給下游 Server，Server 必須驗證 token 是發給自己（audience 檢查）。
- 應用層 API 金鑰不等於授權。用自家 API key 冒充 OAuth 授權流程，不符合規範，也難以稽核。
- 治理走向成熟。官方在這一版正式採納功能生命週期與棄用政策，社群也在討論把專案放進中立的基金會架構，讓標準不被單一廠商綁住。
常見問題 FAQ
MCP 是 Anthropic 專屬的嗎？
不是。MCP 由 Anthropic 在 2024 年底開源，之後成為跨廠商的開放標準，OpenAI、Google、微軟等陣營的產品都陸續支援，規範與 SDK 由社群維護者共同推進。官方文件列的 Host 例子就包含 Claude 與 ChatGPT 兩邊的應用。
MCP 和直接把工具寫進 function calling 有什麼差別？
function calling 是「模型怎麼回傳結構化的呼叫意圖」，MCP 是「工具怎麼被發現、被授權、被執行」的整條流程。只用一家廠商的模型與自家函式時，直接寫 function calling 比較省事；要跨多個 Host、多個工具、還要處理權限時，MCP 的標準化才划算。
不會寫程式也能用 MCP 嗎？
可以。大多數 Host 都支援圖形介面安裝現成 Server，你只需要在設定裡填入 token 或授權，不需要寫程式。真正需要寫程式的時機，是你要把內部系統或自己的服務開放給 AI 使用。
MCP 會讓 AI 亂動我的檔案或帳號嗎？
風險來自你裝了什麼 Server，以及你同意了多少權限。實務上建議只裝來源可查的 Server、先用最小權限的 token、把有寫入能力的工具額外確認一次，並且定期檢查 Host 的連線清單。規範要求 Host 在執行工具前取得使用者同意，但最終把關仍在你自己身上。
延伸閱讀：站上 AI 工具系列
- Claude Code vs Codex CLI vs Antigravity：三大 AI Coding CLI 比較（2026）
- AI 編程工具怎麼選？Claude Code、Codex、Cursor、Gemini CLI 四強比較（2026）
- 大模型 API 怎麼挑？價格、上下文、工具呼叫比較（2026）
- AI 訂閱費怎麼算？2026 主流 AI 訂閱與 API 計費圖解對照
資料來源與查證時間
- MCP 官方入門文件與架構說明：modelcontextprotocol.io/docs/getting-started/intro（查證於 2026-10-19）
- MCP 規範首頁與最新版本 2026-07-28：modelcontextprotocol.io/specification/latest（查證於 2026-10-19）
- 2026-07-28 規範變更說明（逐請求能力宣告、resultType、錯誤碼分段、棄用政策）：modelcontextprotocol.io/specification/2026-07-28/changelog
- 官方部落格〈The 2026-07-28 Specification〉與〈The Official Ruby SDK for MCP Reaches 1.0〉：blog.modelcontextprotocol.io（2026-07-28）
- 官方 SDK 分層與語言清單：modelcontextprotocol.io/docs/sdk
- MCP Registry 的命名空間驗證與信任機制：modelcontextprotocol.io/registry/about
協定版本與 SDK 支援狀況變動頻繁，實作前請以官方文件當下版本為準。