MCP 官方文件 Model Context Protocol Docs

📌 30 秒摘要

MCP 是「AI 應用的 USB-C」——一套開放標準，讓 Claude、ChatGPT 這類 AI 應用用統一介面連上外部的資料、工具與工作流。核心是 Host／Client／Server 架構 ＋ JSON-RPC 資料層 ＋三大伺服器原語（Tools／Resources／Prompts）與三大用戶端原語（Sampling／Elicitation／Roots）；傳輸走 stdio（本地） 或 Streamable HTTP（遠端，OAuth 授權）。

🗺 心智圖（Canvas）

MCP 官方文件
🔌 MCP 官方文件
🧭 架構與傳輸
工具-MCP架構與資料流
🎯 什麼情境該想到我

當你想先建立 MCP 的整體心智模型——「誰跟誰連、一次連線從頭到尾怎麼跑」——再去看細節的時候。

⚙️ 怎麼用（記住三個角色＋兩層＋生命週期）

三個參與者：

Host：AI 應用本體（Claude Code、VS Code），協調多個 client。

Client：協定層元件，一個 client 對一個 server 維持連線；host 每連一個 server 就 new 一個 client。

Server：提供情境／能力的程式（可本地或遠端）。

兩層：

資料層：JSON-RPC 2.0，定義訊息與語義——生命週期、原語（tools/resources/prompts）、通知。這是最該懂的一層。

傳輸層：實際通道——stdio 或 Streamable HTTP，處理連線建立、訊息封裝、授權（見工具-選擇MCP傳輸方式）。

生命週期（一次連線怎麼開始）：client 送 initialize → 雙方做 capability negotiation（宣告支援哪些原語、是否支援 listChanged 通知）＋協商單一 protocol 版本 → client 送 notifications/initialized → 開始互動。版本不相容就終止連線。

典型資料流：initialize（握手）→ tools/list（發現）→ tools/call（執行）→ 需要時 server 發 notifications/tools/list_changed 通知 client 重新拉清單。

★ 為什麼是「一個 client 對一個 server」
Host（Claude Code / VS Code）
 ├─ Client A ──stdio──▶ Server: filesystem
 ├─ Client B ──stdio──▶ Server: git
 └─ Client C ──HTTP──▶ Server: 公司內部 API
★ 一對一的理由是「隔離」：

每個連線有獨立的生命週期（一個 server 掛掉不影響其他）

每個連線有獨立的能力協商結果（各 server 支援的原語不同）

狀態不會互相污染（通知、訂閱、會話狀態各自獨立）

★ Host 的職責是「聚合」：把多個 server 的工具彙整成一份清單交給模型
（這時就會遇到工具集設計的「幾個工具太多」問題）。

★ MCP 在整個堆疊中的位置（最常被問的區分）
┌────────────────────────────────────────┐
│ 模型層：Function Calling               │  ← 模型決定「呼叫哪個工具、帶什麼參數」
│   這是「模型的能力」，和 MCP 無關      │
└────────────────────────────────────────┘
                 ▲ 工具定義從哪來？
┌────────────────────────────────────────┐
│ 整合層：MCP                            │  ← 標準化「工具怎麼被發現、描述、呼叫」
│   Host/Client/Server + JSON-RPC        │
└────────────────────────────────────────┘
★★ MCP 不取代 function calling，它解的是「M×N 問題」：
M 個 AI 應用要接 N 個資料源 → 原本要寫 M×N 個整合，MCP 讓它變成 M+N。
模型端仍然是用 function calling 的方式決定要呼叫什麼。
（完整對照見 Function Calling 與結構化輸出。）

★ 三大原語與它們的「誰主動」

原語誰控制用途
Tools ★ 模型決定何時呼叫 有副作用的動作、查詢
Resources ★ 應用/使用者決定要附帶什麼 檔案內容、資料庫 schema、文件
Prompts ★ 使用者主動選擇 預先寫好的提示模板（slash command）

★ 這個「誰主動」的區分是 MCP 設計的核心：

不是所有情境都該由模型決定。
Resources 讓應用決定附帶什麼情境（避免模型亂抓）；
Prompts 讓使用者選擇工作流（可預測、可重複）。
把該給使用者的控制權還給使用者，而不是全部丟給模型自己判斷。

★ 能力協商（capability negotiation）在協商什麼
// client → server
{ "method": "initialize", "params": {
    "protocolVersion": "2025-xx-xx",
    "capabilities": { "roots": { "listChanged": true }, "sampling": {} }
}}
// server → client
{ "result": {
    "protocolVersion": "2025-xx-xx",          // ★ 協商出單一版本，不相容就終止
    "capabilities": {
      "tools":     { "listChanged": true },   // ★ 我會在工具變動時通知你
      "resources": { "subscribe": true },     // ★ 我支援訂閱資源變更
      "prompts":   {}
    }
}}
★ 協商的是「雙方各自支援哪些可選功能」，而不只是版本號。
→ 所以 client 不能假設 server 支援 listChanged，要看協商結果再決定要不要監聽通知。

★ 通知（notification）：為什麼需要它

JSON-RPC 的 notification 是「不需要回應的訊息」，MCP 用它做動態更新：

通知意思
notifications/tools/list_changed ★ 工具清單變了，請重新 tools/list
notifications/resources/updated 你訂閱的資源變了
notifications/resources/list_changed 資源清單變了
notifications/initialized client 告訴 server「握手完成，可以開始了」

★ list_changed 讓 server 可以在執行期改變它提供的工具——
例如「使用者登入後才出現管理員工具」。
沒有這個機制，工具清單就只能在連線時固定。

★ 典型的完整資料流
① initialize            client → server   （含 capabilities）
② initialize result     server → client   （協商結果）
③ notifications/initialized  client → server
   ───────── 握手完成 ─────────
④ tools/list            client → server   （發現有哪些工具）
⑤ ★ host 把工具定義餵給模型（此時進入 function calling 的世界）
⑥ tools/call            client → server   （模型決定呼叫後）
⑦ result / error        server → client
⑧ notifications/tools/list_changed  server → client  （必要時）
   → 回到 ④
★ ⑤ 是 MCP 與模型的交界：MCP 只負責「拿到工具定義」與「執行呼叫」，
「決定呼叫什麼」完全是模型的事。

🧪 我實際套用的紀錄

2026-07-26：（待填）

⚠️ 注意 / 什麼時候不適用

★★ 每個 MCP server 都是一個信任邊界。第三方 server 看得到你餵進去的內容，
而且它的工具描述會進入你的 prompt（注入載體，見提示注入與分層防禦、工具-MCP安全防護要點）。

★ 工具太多會讓模型選錯。接了五個 server = 可能有四十個工具 →
要做工具篩選或動態載入（見工具集設計）。

★ 協定版本會演進。要優雅處理不相容，不要假設對方和你同版本。

不要假設 server 支援所有可選能力。看協商結果，不要看文件上寫的。

server 的錯誤要能被模型理解。回傳的錯誤訊息會進入模型的上下文——
寫成「模型看得懂並能修正」的形式（見工具集設計的回傳設計）。

★ MCP 不是通用 RPC。服務之間的一般通訊用 gRPC/HTTP；MCP 是為「AI 應用取得情境與能力」設計的。

stdio server 的 stdout 只能傳協定訊息（見工具-選擇MCP傳輸方式）。

🔗 相關工具

Function Calling 與結構化輸出 —— ★ MCP 與 function calling 在不同層

工具-MCP三大伺服器原語 —— Tools/Resources/Prompts 的細節

工具-MCP用戶端原語 —— sampling、roots、elicitation

工具-選擇MCP傳輸方式 —— 傳輸層

工具-MCP安全防護要點 —— 信任邊界

工具集設計 —— 工具數量與描述的設計

提示注入與分層防禦 —— 工具描述作為注入載體

MCP 官方文件
工具-選擇MCP傳輸方式
🎯 什麼情境該想到我

當你要決定 MCP server「怎麼跟 client 通訊」——本地程序還是網路服務、單人還是多人、要不要認證——的時候。

⚙️ 怎麼用（二選一）

stdio transport（本地）：

用標準輸入/輸出跟同一台機器上的程序直接溝通，無網路開銷、效能最好。

典型服務單一 client（host 直接啟動它，如 Claude Desktop 起 filesystem server）。

適合：本地檔案/工具、個人用、不需跨網路。

Streamable HTTP transport（遠端）：

client→server 用 HTTP POST，回應可用 Server-Sent Events 串流。

支援遠端、可同時服務多個 client。

支援標準 HTTP 認證（bearer token、API key、自訂 header），MCP 建議用 OAuth 取得 token。

適合：雲端託管、多使用者、需授權的 server。

決策捷徑：本地／單人／要快 → stdio；遠端／多人／要認證 → Streamable HTTP + OAuth。傳輸層對資料層透明，換傳輸不影響 JSON-RPC 訊息格式。

★ 決策表

問題 stdio Streamable HTTP
server 在哪 ★ 同一台機器 本地或遠端皆可
誰啟動它 ★ host 直接 spawn 子程序 獨立部署的服務
服務幾個 client ★ 一個（一對一） ★ 多個
認證 ★ 不需要（同一個使用者的程序） ★ 需要（bearer / OAuth）
延遲 ★ 最低（無網路）有網路開銷
部署與更新隨 host 走 ★ 可獨立部署、集中更新
存取本機資源 ★ 天然可以（檔案、git、本機工具） ❌ 看不到使用者的機器
觀測與稽核難（散在各使用者的機器上） ★ 集中、可稽核

★ 一句話判準：

要碰使用者機器上的東西 → stdio；要集中管理、多人共用、需要授權 → HTTP。

★ stdio 的實務細節（容易踩的地方）
★★ stdout 只能傳 MCP 訊息 —— 任何 print/log 寫到 stdout 都會破壞協定
   → 所有日誌一律寫 stderr
// ❌ 會把協定搞爛
fmt.Println("server started")
 
// ✅
fmt.Fprintln(os.Stderr, "server started")
slog.SetDefault(slog.New(slog.NewTextHandler(os.Stderr, nil)))
★ 這是寫 MCP server 最常見的第一個 bug，而且症狀是「client 完全連不上但沒有錯誤訊息」。

其他細節：

環境變數是傳設定的主要途徑（host 啟動時注入）

子程序的生命週期由 host 管——要正確處理 SIGTERM 並清理資源

不要假設有 TTY，也不要做互動式提示

★ HTTP 的實務細節

事項說明
★ 授權 MCP 建議用 OAuth 取得 token；簡單情境可用 bearer token / API key
★ 多租戶隔離 一個 server 服務多個使用者 → 每個請求都要驗證身分並隔離資料
（見權限感知檢索與引用歸因）
串流回應可用 SSE（見 AI 工程 Coding 題型的 SSE 解析器）
可觀測性 ★ 集中式的日誌與追蹤——這是 HTTP 相對 stdio 的主要優勢
限流多使用者 → 需要 per-tenant 配額（見工具-限流器設計）

★ 安全考量（兩種傳輸都適用）

★★ MCP server 是一個新的信任邊界，而且是雙向的。

風險說明
★ server 看得到你餵進去的內容 第三方 server = 把資料交給第三方。內部資料要用自己部署的
★ 工具描述是注入載體 工具的 description 會進入模型的 prompt → 惡意 server 可以在描述裡藏指令（見提示注入與分層防禦）
★ 遠端 server 的可用性 它掛了你的 agent 就少一半能力 → 要有降級
本地 server 的權限 stdio server 以使用者的身分執行 → 它能做的事和使用者一樣多

★ 實務建議：

第三方 MCP server 當成不可信的外部依賴，不要給它超出必要的資料

自己部署的 server 才用在敏感資料上

工具描述要 review（尤其自動安裝的 server）

🧪 我實際套用的紀錄

2026-07-26：（待填）

⚠️ 注意 / 什麼時候不適用

★★ stdio 的 stdout 絕對不能寫非協定內容（見上）。

★ 不要為了「看起來比較專業」而用 HTTP。本地工具用 stdio 更簡單、更快、不用處理認證。

HTTP server 要處理並行。多個 client 同時呼叫 → 狀態不能存在全域變數裡（見工具-Go全域狀態的判準）。

★ 協定版本會演進。initialize 時要協商版本並優雅地處理不相容，不要假設對方版本和你一樣。

★ 工具描述的品質決定一切。不管哪種傳輸，模型選不選得對工具取決於描述（見工具集設計）。

不要把 MCP 當成通用的 RPC。它是給「AI 應用取得情境與能力」設計的；
服務之間的一般通訊還是用 gRPC/HTTP。

🔗 相關工具

工具-MCP架構與資料流 —— 協定層的完整說明

工具-MCP安全防護要點 —— 安全的完整討論

工具-建一個MCP-server的起手式 —— 實作

Function Calling 與結構化輸出 —— ★ MCP 與 function calling 在不同層

工具集設計 —— 工具描述怎麼寫

提示注入與分層防禦 —— 工具描述作為注入載體

MCP 官方文件
🧱 原語
工具-MCP三大伺服器原語
🎯 什麼情境該想到我

當你要做 MCP server、卻分不清「該把某個能力做成 tool、resource 還是 prompt」的時候。關鍵是問「誰控制它」。

⚙️ 怎麼用（按「誰控制」對號入座）

Tools（模型控制）：LLM 主動決定何時呼叫的動作——寫資料庫、呼叫 API、改檔案。用 JSON Schema 定義 typed 輸入/輸出；tools/list 發現、tools/call 執行；執行前通常需使用者同意。例：searchFlights、createCalendarEvent。

Resources（應用控制）：唯讀的情境資料——檔案內容、DB schema、API 文件。每個有唯一 URI（file:///...）與 MIME type；支援固定 URI 與帶參數的 Resource Template（travel://activities/{city}）。resources/list、resources/read、resources/subscribe。由應用決定要塞多少進脈絡。

Prompts（使用者控制）：可重用的指令模板，需使用者明確叫用（非自動觸發），可帶參數、可引用 tools/resources。prompts/list、prompts/get。例：「Plan a vacation」帶 destination/duration/budget。

設計法則：一個 tool 只做一件事、schema 清楚；把「AI 要採取的行動」放 tools、「AI 需要知道的資料」放 resources、「引導使用者的流程」放 prompts。

🧪 我實際套用的紀錄

2026-07-26：（待填）

⚠️ 注意 / 什麼時候不適用

Tools 由模型自動叫用，風險最高——務必留人類同意/核准的關卡（見工具-MCP安全防護要點）。

別把唯讀資料硬做成 tool；resource 才是給脈絡的正解。

🔗 相關工具

工具-MCP用戶端原語 —— 反方向的三個能力（Sampling/Elicitation/Roots），是 client 提供給 server 的，配成一組看才完整

工具-MCP架構與資料流 —— 上位圖，先知道 Host/Client/Server 怎麼連，才知道這三個原語掛在哪一層

工具-建一個MCP-server的起手式 —— 實作面：決定好暴露什麼之後，照這張的步驟把它做出來
工具-MCP用戶端原語
🎯 什麼情境該想到我

當你的 MCP server「需要 LLM、需要問使用者、或需要知道能碰哪些檔案」，但又想保持乾淨、把控制權留給 client 的時候。這三個是 client 反過來提供給 server 的能力。

⚙️ 怎麼用（三選一，對應需求）

Sampling（借用 LLM）：server 用 sampling/createMessage 請 client 幫忙做 LLM 補全——這樣 server 不必自帶模型 SDK、不必自付 API 費、保持模型無關。可帶 modelPreferences（cost/speed/intelligence 權重）、systemPrompt、maxTokens。設計上是 human-in-the-loop：使用者可審核/修改請求與回應。例：findBestFlight 把 47 個航班丟給 LLM 選最佳。

Elicitation（向使用者要資訊）：server 用 elicitation/create 帶一個 JSON schema，在流程中動態要輸入或要確認（別一開始就逼使用者填完所有欄位）。使用者可提供/拒絕/取消，client 會依 schema 驗證。絕不可用來要密碼或 API key。

Roots（限定檔案範圍）：client 用 file:// URI 告訴 server「你該聚焦哪些目錄」；可隨使用者切換專案動態更新（roots/list_changed）。這是協調機制、不是安全邊界——真正的隔離要靠 OS 權限/sandbox。

先確認 client 有沒有宣告：能力協商（capability negotiation）

依 MCP 規格整理（查證 2026-10-15；目前最新規格版本 2026-07-28，來源筆記寫的是當時的 2025-11-25）。

這三個原語都是選配：client 支援才可以用，server 不可以假設對方一定有。

規格 2025-11-25（握手式，多數既有實作）：連線一開始 client 送 initialize，在 capabilities 裡宣告自己支援哪些——例如 "roots": {"listChanged": true}、"sampling": {}、"elicitation": {"form": {}, "url": {}}。規格要求雙方「只使用協商成功的能力」。sampling 的子能力也要另外宣告：client 沒宣告 sampling.tools，server 就不可送帶 tools 的 sampling 請求。

規格 2026-07-28（目前最新）：拿掉了 initialize 握手，改成 client 在每一個請求的 _meta["io.modelcontextprotocol/clientCapabilities"] 裡宣告能力。server 要 sampling／elicitation 時，不再主動發請求，而是在回應裡回傳 InputRequiredResult（resultType: "input_required"），把要問的東西放進 inputRequests，client 處理完再帶著 inputResponses 重送原請求（Multi Round-Trip Requests）。規格明訂：client 沒宣告的能力，server 不可放進 inputRequests（例：沒宣告 elicitation 就不能塞 elicitation/create）；elicitation 還要看模式，client 只宣告 form 就不能送 url 模式。

2026-07-28 已把 Sampling 與 Roots 標為 Deprecated（SEP-2577；最早可移除的時間是 2027-07-28 之後發布的版本）：新實作不應再採用。官方遷移路徑——Sampling → server 直接串 LLM 供應商 API；Roots → 改由工具參數、resource URI 或 server 設定傳目錄。Elicitation 沒有被棄用。

server 端的退路（fallback）怎麼設計（自寫範例，非規格原文）：

想用的能力 client 沒宣告時的退路
Sampling 改用 server 自己的模型 API key（失去「模型無關、不付費」的好處）；或不靠 LLM 做確定性的處理（例：航班照價格＋轉機次數排序取前 3）；或把候選結果整包回傳，讓 host 那邊的 LLM 在主對話裡挑
Elicitation 把需要的欄位直接寫進工具的 input schema 設成必填，一開始就要；缺了就回一個清楚說明「缺哪個參數」的錯誤，讓 host 的 LLM 回頭問使用者
Roots 讓使用者在 server 設定或工具參數裡明確給路徑；沒給就拒絕操作，不要自己猜一個目錄

實務上很多 client 從沒實作 sampling（推測：sampling 一直是選配、也是需要 UI 審核的重功能；2026-07-28 被棄用也印證採用度有限），所以依賴 sampling 才能運作的 server，等於只在少數 client 上能用——一定要有上面的退路。

最小 sampling/createMessage 請求骨架（2025-11-25 的 JSON-RPC 形式，依規格範例精簡）：
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "sampling/createMessage",
  "params": {
    "messages": [
      { "role": "user", "content": { "type": "text", "text": "從下列 47 個航班挑出最划算的 3 個：..." } }
    ],
    "modelPreferences": { "costPriority": 0.3, "speedPriority": 0.5, "intelligencePriority": 0.8 },
    "systemPrompt": "你是訂票助理。",
    "maxTokens": 300
  }
}
client 回傳的 result 形如 {"role":"assistant","content":{"type":"text","text":"..."},"model":"<實際用的模型>","stopReason":"endTurn"}；使用者在審核關卡按拒絕時，client 應回錯誤碼 -1（“User rejected sampling request”），server 要能接住這個錯誤走退路。在 2026-07-28 裡，同一份 {"method": "sampling/createMessage", "params": {...}} 不帶 jsonrpc／id，而是包在 InputRequiredResult.inputRequests 裡以自訂鍵名（例 "pick_flights"）回給 client。

🧪 我實際套用的紀錄

2026-07-26：（待填）

⚠️ 注意 / 什麼時候不適用

Roots 只是「請 server 自律」，不能當防線；不受信任的 server 仍可能越界。

Sampling/Elicitation 都應保留使用者審核關卡，避免 server 藉此偷渡敏感操作。

沒先檢查能力就直接用：server 對沒宣告 sampling／elicitation 的 client 發請求，是違反規格的；輕則請求失敗，重則整個工具呼叫卡住沒回應（推測）。寫 server 時先讀 client 宣告的能力再決定走哪條路。

新專案別再把 Sampling、Roots 當核心依賴（查證 2026-10-15）：兩者在規格 2026-07-28 已被棄用，最早 2027-07-28 之後的版本就可能移除。

🔗 相關工具

工具-MCP三大伺服器原語 —— 對稱的另一半，server 端的 Tools/Resources/Prompts，兩張配成完整的能力表

工具-MCP架構與資料流 —— 上位圖，解釋為什麼這三個能力是 client 反過來提供給 server 的

工具-AI-Agent設計 —— Sampling 的實際用途：讓 server 借用 client 的模型做多步推理，就落在 agent 這一塊
🛠 實作與安全
工具-建一個MCP-server的起手式
🎯 什麼情境該想到我

當你想把「自己的 API／資料源／工具」包成 MCP server，讓 Claude 這類 AI 應用能即插即用地呼叫的時候。

⚙️ 怎麼用（從零到能被呼叫）

選 SDK：官方提供 Python / TypeScript / Java / Kotlin / C# / Ruby / Rust / Go；挑你熟的語言，SDK 會把 JSON-RPC、生命週期等細節抽象掉。

決定要暴露什麼：依工具-MCP三大伺服器原語對號入座——動作放 Tools、唯讀資料放 Resources、引導流程放 Prompts。（多數 server 從 Tools 開始，如教學的 get_alerts、get_forecast。）

定義 Tool：給 name、description、inputSchema（JSON Schema，標好 properties 與 required）；讓描述清楚到模型能自己判斷何時呼叫。

實作協定方法：tools/list（回傳工具清單與 schema）、tools/call（執行並回結果）；SDK 通常用 decorator/註冊即可。

選傳輸：本地自用先走 stdio（見工具-選擇MCP傳輸方式）。

接到 host：在 host（如 Claude for Desktop）的設定檔登記你的 server 啟動指令，重啟後即可被呼叫。

測試除錯：用 MCP Inspector（互動式測試工具）逐一叫 tools/list/tools/call 驗證；問題多時看 Debugging 頁與 log。

要上遠端/多人：改用 Streamable HTTP + OAuth，並過一遍工具-MCP安全防護要點。

🧪 我實際套用的紀錄

2026-07-26：（待填）

⚠️ 注意 / 什麼時候不適用

一個 tool 只做一件事、schema 寫清楚，模型才叫得準；別把十件事塞進一個 tool。

上線前務必補上使用者同意關卡與授權（tool 會實際改資料/呼叫外部）。

🔗 相關工具

工具-MCP架構與資料流 —— 動手前先看，建立 Host / Client / Server 的整體圖，才知道自己寫的是哪一塊、一次連線怎麼跑

工具-MCP三大伺服器原語 —— 第 2 步「決定暴露什麼」的判準：用「誰控制它」把能力分到 Tools / Resources / Prompts

工具-選擇MCP傳輸方式 —— 第 5 步選傳輸時看，本地 stdio 與遠端 Streamable HTTP 的取捨與認證需求

工具-MCP安全防護要點 —— 要開放給別人用之前的檢查清單，授權、同意關卡與攻擊面一次過完

工具-MCP安全防護要點
🎯 什麼情境該想到我

當你要發布一個遠端 MCP server，或串接別人的 MCP server，想確認授權與攻擊面有沒有顧好的時候。

⚙️ 怎麼用（發布/串接前的檢查清單）

授權用 OAuth、全程 HTTPS：遠端 server 用 OAuth 取得 token；授權 URL 只允許 http:///https:// scheme 並必須用 https://、驗證 redirect/authorization URL，別接受任意 URL。

別拿 session 當身分驗證：MUST NOT use sessions for authentication；session ID 要不可預測（non-deterministic）並綁定使用者資訊，防 session 劫持/冒充。

禁止 Token Passthrough：server 不可把「不是發給自己」的 token 直接轉發給下游 API——這會繞過授權邊界（Confused Deputy）。

執行動作前先取得同意：MUST implement proper consent mechanisms prior to executing commands；tool 由模型自動叫用，務必留人類核准關卡。

防 SSRF：server 若會依輸入去打 URL，要驗證/白名單目標，避免被誘導打內網。

最小權限（Scope Minimization）：只要必要的 scope 與資源存取；Roots 只是協調非強制邊界，真正隔離靠 OS 權限/sandbox。

本地 server 也有風險：本地 MCP server 若被植入惡意程式會直接在你機器上執行；MUST NOT 用未信任輸入去組裝 shell 指令。只裝可信/審過的 server。

🧪 我實際套用的紀錄

2026-07-26：（待填）

⚠️ 注意 / 什麼時候不適用

這是要點清單；正式實作請對照官方 Authorization 規格與 Security Best Practices 全文。

安全不是單點——授權、傳輸、同意、範圍要一起做才有效。

🔗 相關工具

工具-選擇MCP傳輸方式 —— 安全需求直接影響傳輸選型：走遠端 HTTP 才需要認證與授權那一整套

工具-MCP用戶端原語 —— 攻擊面主要在這裡：Sampling 會用到 LLM、Roots 決定能碰哪些檔案，都需要同意關卡

工具-服務容錯設計 —— 補上可用性那一面：安全顧的是「不被打」，容錯顧的是「下游掛了不要雪崩」
Link to original

原語	誰控制	用途
Tools	★ 模型決定何時呼叫	有副作用的動作、查詢
Resources	★ 應用/使用者決定要附帶什麼	檔案內容、資料庫 schema、文件
Prompts	★ 使用者主動選擇	預先寫好的提示模板（slash command）

通知	意思
`notifications/tools/list_changed`	★ 工具清單變了，請重新 `tools/list`
`notifications/resources/updated`	你訂閱的資源變了
`notifications/resources/list_changed`	資源清單變了
`notifications/initialized`	client 告訴 server「握手完成，可以開始了」

問題	stdio	Streamable HTTP
server 在哪	★ 同一台機器	本地或遠端皆可
誰啟動它	★ host 直接 spawn 子程序	獨立部署的服務
服務幾個 client	★ 一個（一對一）	★ 多個
認證	★ 不需要（同一個使用者的程序）	★ 需要（bearer / OAuth）
延遲	★ 最低（無網路）	有網路開銷
部署與更新	隨 host 走	★ 可獨立部署、集中更新
存取本機資源	★ 天然可以（檔案、git、本機工具）	❌ 看不到使用者的機器
觀測與稽核	難（散在各使用者的機器上）	★ 集中、可稽核

事項	說明
★ 授權	MCP 建議用 OAuth 取得 token；簡單情境可用 bearer token / API key
★ 多租戶隔離	一個 server 服務多個使用者 → 每個請求都要驗證身分並隔離資料（見權限感知檢索與引用歸因）
串流	回應可用 SSE（見 AI 工程 Coding 題型的 SSE 解析器）
可觀測性	★ 集中式的日誌與追蹤——這是 HTTP 相對 stdio 的主要優勢
限流	多使用者 → 需要 per-tenant 配額（見工具-限流器設計）

風險	說明
★ server 看得到你餵進去的內容	第三方 server = 把資料交給第三方。內部資料要用自己部署的
★ 工具描述是注入載體	工具的 `description` 會進入模型的 prompt → 惡意 server 可以在描述裡藏指令（見提示注入與分層防禦）
★ 遠端 server 的可用性	它掛了你的 agent 就少一半能力 → 要有降級
本地 server 的權限	stdio server 以使用者的身分執行 → 它能做的事和使用者一樣多

想用的能力	client 沒宣告時的退路
Sampling	改用 server 自己的模型 API key（失去「模型無關、不付費」的好處）；或不靠 LLM 做確定性的處理（例：航班照價格＋轉機次數排序取前 3）；或把候選結果整包回傳，讓 host 那邊的 LLM 在主對話裡挑
Elicitation	把需要的欄位直接寫進工具的 input schema 設成必填，一開始就要；缺了就回一個清楚說明「缺哪個參數」的錯誤，讓 host 的 LLM 回頭問使用者
Roots	讓使用者在 server 設定或工具參數裡明確給路徑；沒給就拒絕操作，不要自己猜一個目錄

🎯 為什麼存這套文件 / 未來想拿它做什麼

想把自己的 API／資料源包成 MCP server，讓 AI 應用即插即用時的權威依據。
搞懂「tools / resources / prompts / sampling / elicitation / roots」到底各自幹嘛、誰控制。
決定本地(stdio) vs 遠端(HTTP) 傳輸、以及遠端授權與安全防護怎麼做。

🧰 這套文件給我的工具（連到 tools/）

工具-MCP三大伺服器原語 — 想搞懂 MCP server 能對外提供什麼、該暴露哪些東西時
工具-MCP用戶端原語 — server 想借用 LLM、向使用者要資訊、或限定檔案範圍時
工具-MCP架構與資料流 — 想理解 Host/Client/Server 怎麼連、一次連線怎麼跑時
工具-選擇MCP傳輸方式 — 不確定 MCP 要用 stdio 還是 HTTP、本地還是遠端時
工具-MCP安全防護要點 — 要串接／發布 MCP server、想顧好授權與攻擊面時
工具-建一個MCP-server的起手式 — 想從零做出一個能被 AI 呼叫的 MCP server 時

🗂 文件涵蓋範圍（已收錄 16 頁）

Get started：What is MCP?（總覽、USB-C 比喻）
About MCP：Architecture（架構總覽）、Servers（伺服器概念）、Clients（用戶端概念）、Versioning（版本管理，YYYY-MM-DD、目前 2025-11-25）
Develop：Connect to local servers、Connect to remote servers、Build with Agent Skills、Build an MCP server、Build an MCP client、Client best practices、SDKs
Developer tools：MCP Inspector、Debugging
Security：Understanding Authorization（OAuth）、Security Best Practices（攻擊面與緩解）

✨ 關鍵重點

三個參與者：Host（AI 應用，如 Claude Code）為每個 server 建立一個 Client，每個 Client 對一個 Server 維持連線。
兩層：資料層（JSON-RPC 2.0：生命週期、原語、通知）＋ 傳輸層（stdio 或 Streamable HTTP；HTTP 建議用 OAuth）。
生命週期：連線先 initialize 握手做 capability negotiation（雙方宣告支援哪些原語與通知），協商出單一 protocol 版本才建立 session。
伺服器原語：Tools（模型控制的動作）、Resources（應用控制的唯讀資料）、Prompts（使用者控制的模板）；用 */list 發現、*/get/*/read 取得、tools/call 執行。
用戶端原語：Sampling（server 借用 client 的 LLM）、Elicitation（server 向使用者要結構化輸入）、Roots（client 告知 server 可存取的檔案目錄，屬協調非強制安全邊界）。

💬 原文摘錄

「Think of MCP like a USB-C port for AI applications.」
「MCP defines three core primitives that servers can expose: Tools（executable functions）, Resources（data sources）, Prompts（reusable templates）.」
「Roots serve as a coordination mechanism between clients and servers, not a security boundary.」
「Elicitation never requests passwords or API keys.」

🔗 相關

工具-AI-Agent設計（《AI工程》）——MCP 正是「讓 agent 安全地用外部工具／取得情境」的標準協定，兩者互補
LLM Course 課程文件——互補的另一半：MCP 管「怎麼安全接工具」，那份管「模型本身怎麼練、怎麼跑得快」

Quartz 5

Explorer

MCP 官方文件 Model Context Protocol Docs

📌 30 秒摘要

🗺 心智圖（Canvas）

MCP 官方文件

🔌 MCP 官方文件

🎯 什麼情境該想到我

⚙️ 怎麼用（記住三個角色＋兩層＋生命週期）

★ 為什麼是「一個 client 對一個 server」

★ MCP 在整個堆疊中的位置（最常被問的區分）

★ 三大原語與它們的「誰主動」

★ 能力協商（capability negotiation）在協商什麼

★ 通知（notification）：為什麼需要它

★ 典型的完整資料流

🧪 我實際套用的紀錄

⚠️ 注意 / 什麼時候不適用

🔗 相關工具

🎯 什麼情境該想到我

⚙️ 怎麼用（二選一）

★ 決策表

★ stdio 的實務細節（容易踩的地方）

★ HTTP 的實務細節

★ 安全考量（兩種傳輸都適用）

🧪 我實際套用的紀錄

⚠️ 注意 / 什麼時候不適用

🔗 相關工具

🎯 什麼情境該想到我

⚙️ 怎麼用（按「誰控制」對號入座）

🧪 我實際套用的紀錄

⚠️ 注意 / 什麼時候不適用

🔗 相關工具

🎯 什麼情境該想到我

⚙️ 怎麼用（三選一，對應需求）

先確認 client 有沒有宣告：能力協商（capability negotiation）

🧪 我實際套用的紀錄

⚠️ 注意 / 什麼時候不適用

🔗 相關工具

🎯 什麼情境該想到我

⚙️ 怎麼用（從零到能被呼叫）

🧪 我實際套用的紀錄

⚠️ 注意 / 什麼時候不適用

🔗 相關工具

🎯 什麼情境該想到我

⚙️ 怎麼用（發布/串接前的檢查清單）

🧪 我實際套用的紀錄

⚠️ 注意 / 什麼時候不適用

🔗 相關工具

🎯 為什麼存這套文件 / 未來想拿它做什麼

🧰 這套文件給我的工具（連到 tools/）

🗂 文件涵蓋範圍（已收錄 16 頁）

✨ 關鍵重點

💬 原文摘錄

🔗 相關

Graph View

Table of Contents

Backlinks