跳轉到

MCP 生態系指南：Server 類型、Local vs Remote、Auth 與 Security Boundary

整理自 MCP 官方規格與 Anthropic 文件（見文末），2026-06-20。本頁是「概念地圖」，幫你在接 MCP 時判斷：要接什麼類型的 server、放本地還是遠端、怎麼授權、信任邊界在哪。實作細節以官方規格為準。

實證標記：〔規格〕= 出自 MCP 官方 spec；〔Anthropic〕= 出自 Anthropic 官方文件；〔實務〕= 業界慣例/本人整理，未必是規範。預設 under-claim，拿不準的地方會明講。

一句話定義

MCP（Model Context Protocol）是一個開放協定，讓 LLM 應用以統一介面連到外部工具與資料源。 它用 JSON-RPC 2.0 做 client–server 通訊，把「模型要用的能力」標準化，避免每個整合都自己造輪子。〔規格〕

三方角色

角色 是什麼 例子
Host 跑 LLM、決定要連哪些 server 的應用 Claude Desktop、Claude Code、IDE 外掛
Client Host 內部，與單一 server 維持 1:1 連線的元件 Host 為每個 server 開一個 client
Server 暴露能力（工具/資料/提示）給 client 的程式 GitHub server、檔案系統 server、資料庫 server

一個 Host 可同時連多個 Server；這個「單一 client、多個 server」的部署型態，是後面 auth 安全考量的關鍵。〔規格〕

Server 能暴露什麼（三種 primitives）

MCP server 對外提供的能力分三類，理解這個分類比理解「server 種類」更實用：〔規格〕

Primitive 是什麼 誰主導呼叫 類比
Tools 可被模型呼叫、會產生副作用的函式（查 API、寫檔、下單） 模型決定何時呼叫 函式呼叫
Resources 唯讀的結構化資料/檔案內容，供模型讀取 應用/模型挑選載入 GET 資源
Prompts 預先寫好的提示樣板，使用者可主動套用 使用者觸發 指令模板

實務上多數人講「MCP server」時指的是 Tools 型；但 Resources / Prompts 在「給模型餵 context」上同樣重要。〔實務〕

Local vs Remote：核心是 Transport

MCP 規格定義兩種標準傳輸方式，這就是「本地 server」與「遠端 server」的技術分界：〔規格〕

面向 Local（stdio） Remote（Streamable HTTP）
傳輸 Host 把 server 當子行程啟動，用 stdin/stdout 收發 JSON-RPC（換行分隔） server 是獨立行程，用 HTTP POST/GET，可選用 SSE 串流多則訊息
部署 跟 Host 同一台機器 可在任意主機，多 client 連同一 server
認證 通常靠本機行程權限，無網路 auth 需要正式的網路授權（見下節 OAuth）
適合 存取本機檔案、跑本地工具、低延遲、私密資料不出機器 SaaS 整合、團隊共用、集中維運
風險面 子行程能做的事 = Host 帳號能做的事 網路曝險、token 外洩、跨 server mix-up

規格是 transport-agnostic 的：除 stdio 與 Streamable HTTP 外，client/server 也可自訂傳輸，只要支援雙向訊息交換即可。〔規格〕

〔實務〕選型口訣：資料/工具只在本機、且只有你自己用 → local stdio；要跨人、跨機、跨團隊共用 → remote HTTP。 別為了「看起來專業」把單機工具硬包成遠端服務，徒增 auth 與維運成本。

Security Boundary（信任邊界）

這是接 MCP 最容易出事、也最值得先想清楚的部分。

1. Host 對 Server 的信任

連一個 MCP server，等於把「該 server 宣稱的工具」放進模型可呼叫的範圍。惡意或被攻陷的 server 可以：回傳帶有 prompt injection 的工具輸出、宣告誤導性的工具描述、誘導模型做出未授權動作。〔實務〕

→ 對策：只連可信來源的 server；把高風險工具（寫入、刪除、外送、轉帳）設成需人工確認再執行。〔Anthropic〕

2. 工具輸出 = 不可信輸入

工具/Resource 回傳的內容會進入模型 context，可被當成 prompt injection 載體。把模型看到的所有外部文字都當「使用者可能偽造的輸入」處理，不要讓工具輸出直接觸發特權動作。〔實務〕

3. 憑證不該進入執行沙箱

在受管代理（如 Anthropic Managed Agents / vault 模式）的設計裡，MCP 憑證不放進 sandbox：沙箱內的程式（含模型寫的程式）看到的是占位符，真正的 secret 由平台側 proxy 在請求離開沙箱後（at egress）才注入。這讓 prompt injection 也偷不到金鑰。〔Anthropic〕

→ 自建時的對應原則：別把 API key 寫進 system prompt 或對話訊息——那會被永久存進 session 歷史、被 events.list 讀到、被 compaction 摘要帶走。〔Anthropic〕

4. 跨 server mix-up

MCP 是「單一 client、多 server」型態，比一般 OAuth 場景更易遭 mix-up 攻擊。規格因此要求 client 依 RFC 9207 驗證授權回應中的 iss 參數，作為低成本緩解。〔規格〕

Auth（授權）

MCP 不綁單一身分系統，而是遵循 OAuth 2.1 的慣例。〔規格〕

兩種授權粒度

模式 行為 適用
Per-server 整台 server 連線時就要 auth，每個請求都要帶有效 token 所有工具都敏感時，較簡單
Per-tool 只有特定工具需要 auth；公開工具免 token，呼叫受保護工具時才觸發 OAuth flow 同一 server 想混合公開與受保護工具

規格層面的硬性安全要求〔規格〕

  • Client 必須依 RFC 9207 驗證授權回應的 iss（緩解 mix-up）。
  • Access token 應作為 JWT 對 IdP 的 JWKS 端點驗證。
  • 近期規格用多個 SEP 把授權對齊 OAuth 2.0 / OpenID Connect 的實務部署方式（含 client registration 演進、企業託管授權）。

一個常見大坑：MCP token ≠ 服務的 API key〔Anthropic〕

託管型 MCP server（如 mcp.notion.com、mcp.linear.app）通常要的是 OAuth bearer token，不是該服務的原生 API key。例：Notion 的 ntn_ integration token 能打 Notion REST API，但不能當 Notion MCP server 的憑證——兩者是不同的 auth 系統。接託管 MCP 卡 401 時，先確認你給的是不是對的那種 token。

接 MCP 前的檢查清單〔實務〕

  1. 我要的是 Tool、Resource 還是 Prompt？（決定怎麼用）
  2. 資料/工具該放 local（stdio）還是 remote（HTTP）？（決定 transport 與 auth 成本）
  3. 這個 server 來源可信嗎？高風險工具有沒有設人工確認？
  4. 憑證怎麼保管？有沒有不小心寫進 prompt / 對話？
  5. 託管 MCP 要的是 OAuth token 還是 API key？拿對了嗎？

延伸閱讀（本站）

來源