聯繫我

如果有任何問題或建議，歡迎隨時聯繫我：

• Email

前言

Day 22 講 Claude Code 怎麼管理 MCP 伺服器的 token 開銷，但沒解釋 MCP 本身是什麼。今天把它補上——這是一個你會在 Claude Code、claude.ai，甚至自己寫的 API 整合裡反覆遇到的名詞。

先講白話版定義：MCP（Model Context Protocol）是一套讓 AI 存取外部工具與資料的通用協定。 沒有 MCP 之前，你想讓 Claude 查資料庫、串 Slack、讀 GitHub issue，每一種服務都要自己寫一套客製化的工具定義（Day 9 提過，工具定義本身就要算 token，還要自己維護）。MCP 的價值在於：服務提供者只要照著這套協定實作一次伺服器，任何支援 MCP 的 AI 應用都能直接接上，不用重新發明輪子。

本篇 MCP connector 的規格與範例，於 2026 年對照 MCP connector 官方文件 查證。

這篇對你的意義：你正在授權，不只是「接功能」

如果你用 Claude Code，你可能已經接過 MCP 伺服器了——裝一個 GitHub 的、裝一個資料庫的，然後 Claude 就會用了。很方便。

但這裡有一件事值得停下來想三秒鐘：

接上一個 MCP 伺服器，不只是「給 Claude 多一個能力」，同時也是「給它存取那個服務的權限」。

接了 GitHub 的伺服器，Claude 就能讀你的 repo——也可能能開 issue、關 PR、推 commit，取決於那個伺服器提供哪些工具、你開放了哪些。接了資料庫的，它能查資料——也可能能改資料、刪資料。

這不是要嚇你，MCP 本身是好東西。但多數人接 MCP 時只想著「它能幫我做什麼」，很少想「它被允許做什麼」——而這正是 Day 29 要講的那類盲區：你沒問的問題，對 AI 來說就不存在，它不會主動提醒你「你剛剛給了我刪除權限」。

所以今天的重點順序會跟你預期的不太一樣：先講怎麼控制權限（第二、三節），再講技術原理與怎麼自己接（第四節之後）。 如果你只是 Claude Code 使用者、不打算自己寫 API 整合，看完第三節就可以了。

目錄

一、什麼時候它才會真的動手？

先講一個會讓你安心一點的機制——接了伺服器，不代表 Claude 每次都會去動它。

"Claude does not call an MCP tool for general knowledge questions about a connected service. Asking 'how do Notion databases work?' with a Notion server attached is answered directly; asking 'what's in my Projects database?' triggers the tool."

問「Notion 資料庫怎麼運作」這種一般知識問題，它直接用自己的知識回答；問「我的 Projects 資料庫裡有什麼」這種需要實際查詢的，才會真的伸手。

這件事有兩層意義：成本上，接了伺服器不會讓每次對話都多付工具呼叫的錢（呼應 Day 9）；安全上，它不會沒事去翻你的東西——但一旦你的問題暗示需要外部資料，它就會動手，而且不會先問你。

如果你希望它更保守或更積極，Day 19 講過的 system prompt 技巧可以調整這個傾向。

二、控制它能做什麼：兩種權限模式

這是本篇最該記住的一節，而且它是一個安全決策，不是設定技巧。

MCP 的權限有兩種設計方向，差別在於**「預設是開還是關」**：

官方對拒絕清單給了一個很具體的使用建議：

"Denylisting write or destructive tools is recommended when building read-only assistants, or when you want a human confirmation step before state changes."

（建立唯讀助理時，或當你希望狀態變更前有人工確認步驟時，建議把寫入或破壞性的工具列入拒絕清單。）

這句話值得翻譯成白話：如果你接一個伺服器只是想「查東西」，那就把所有會改動、會刪除的工具關掉。你沒有損失任何你真正需要的能力，但你把「AI 誤判情況、執行了一個不可逆操作」這個風險整個移除了。

一個實用的判斷習慣：接上任何 MCP 伺服器之後，問自己一句——

「這裡面有哪個工具，如果它在錯誤的時機被呼叫，我會很想哭？」

有的話，關掉它。等你真的需要那個能力時再開。

在 Claude Code 裡，用 /mcp 可以看到目前接了哪些伺服器並管理它們。Day 22 提過「停用沒在用的伺服器」能省 context——現在你知道那個動作同時也在縮小你的授權範圍，一舉兩得。

三、如果你只是使用者，看到這裡就夠了

前兩節是每個接 MCP 的人都該知道的。接下來是給要自己寫 API 整合的人看的——如果你只是在 Claude Code 或其他工具裡用現成的 MCP 伺服器，可以直接跳到最後一節「什麼時候該接 MCP」。

四、兩種接法：MCP Connector vs 自己管理 Client

官方文件開宗明義點出兩條路，選哪一條取決於你的伺服器在哪裡：

① MCP Connector（今天的主角）：直接在 Messages API 請求裡宣告要連的 MCP 伺服器，不需要你自己實作一套 MCP client。適用條件很明確——伺服器必須是遠端、可透過 URL 存取的。

② Client-side 輔助工具：如果你要接的是本機執行的 stdio 伺服器，或需要用到 MCP 的 prompts、resources 功能，或想對連線有更細的控制，才需要自己管理 MCP client，官方 SDK 提供轉換函式（例如 Python 的 async_mcp_tool、TypeScript 的 mcpTools）省去手動轉換的工夫。

五、基本設定：兩個陣列各司其職

MCP Connector 用兩個獨立的參數協同運作：

response = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=1000,
    messages=[{"role": "user", "content": "What tools do you have available?"}],
    mcp_servers=[
        {
            "type": "url",
            "url": "https://example-server.modelcontextprotocol.io/sse",
            "name": "example-mcp",
            "authorization_token": "YOUR_TOKEN",
        }
    ],
    tools=[{"type": "mcp_toolset", "mcp_server_name": "example-mcp"}],
    betas=["mcp-client-2025-11-20"],
)

mcp_servers 定義連線細節——URL、名稱、認證權杖；tools 裡的 mcp_toolset 則定義「這個伺服器裡的哪些工具要開放」。這個設計把「連到哪裡」跟「能用什麼」分開，正是第二節那套權限控制在 API 層的實作位置。

三條驗證規則：每個 mcp_server_name 必須有對應的 server 定義、每個 server 都必須被剛好一個 toolset 引用、一個 server 不能被兩個 toolset 重複引用。

注意版本：目前是 mcp-client-2025-11-20。如果你看到教學把工具設定直接寫在 mcp_servers 裡的 tool_configuration 欄位，那是已棄用的舊版。

第二節那兩種權限模式，寫成設定長這樣：

// 允許清單：預設關閉，只開兩個
{
  "type": "mcp_toolset",
  "mcp_server_name": "google-calendar-mcp",
  "default_config": { "enabled": false },
  "configs": {
    "search_events": { "enabled": true },
    "create_event": { "enabled": true }
  }
}

// 拒絕清單：預設開放，關掉破壞性的
{
  "type": "mcp_toolset",
  "mcp_server_name": "google-calendar-mcp",
  "configs": {
    "delete_all_events": { "enabled": false },
    "share_calendar_publicly": { "enabled": false }
  }
}

延遲載入（defer_loading）：設成 true 的工具，一開始只有名稱進 context，完整描述要等真正被搜尋到才載入。這正是 Day 22 那句「MCP 工具定義預設延遲載入」的 API 端原始出處。

六、目前的限制：只支援工具呼叫，伺服器必須公開

官方明確列出兩條限制：

• MCP 規格裡只有「工具呼叫（tool calls）」這部分目前受 Connector 支援，其他 MCP 功能（prompts、resources）要用 client-side 輔助工具。
• 伺服器必須透過 HTTP 公開曝露（支援 Streamable HTTP 與 SSE 兩種傳輸方式）。本機執行的 stdio 伺服器沒辦法直接用 Connector 連上——這是第四節那「兩條路」分岔的根本原因。

七、認證：OAuth Bearer Token

需要認證的 MCP 伺服器，透過 authorization_token 欄位傳入 OAuth 存取權杖：

{
  "mcp_servers": [{
    "type": "url",
    "url": "https://example-server.modelcontextprotocol.io/sse",
    "name": "authenticated-server",
    "authorization_token": "YOUR_ACCESS_TOKEN_HERE"
  }]
}

取得與更新這個權杖的責任在你這邊——官方明講：「API consumers are expected to handle the OAuth flow and obtain the access token prior to making the API call, and to refresh the token as needed.」如果只是想先測試，官方推薦用 MCP Inspector（npx @modelcontextprotocol/inspector）跑一次 OAuth 流程，拿到測試用的權杖。

八、計價與資料保留：兩件容易被忽略的事

計價：MCP 工具呼叫跟一般 Messages API 請求用同一套計價方式，而且 Batch API（Day 10）也支援 mcp_servers——批次請求裡的 MCP 工具呼叫，計費方式跟即時請求一致，沒有額外的價差。

資料保留：官方明確標記 MCP connector 不符合零資料保留（ZDR）資格——跟 MCP 伺服器交換的資料，包含工具定義與執行結果，會依照 Anthropic 標準資料保留政策處理。如果你的應用場景對資料保留有嚴格要求，這是設計架構前就該確認的一項限制，不是事後才發現的意外。

九、什麼時候該接 MCP，什麼時候不需要

Day 22 提過一個實務建議：「優先用 CLI 工具而非 MCP」。今天知道了 MCP 的完整機制之後，可以把這個判斷原則講得更完整。

適合用 MCP 的情境：你要接的服務沒有現成的指令列工具，或是你需要跨多個服務統一管理權限（今天第四節的允許清單／拒絕清單機制，能在同一套設定邏輯下管理不同服務的存取範圍）。企業內部系統、SaaS 服務的官方或社群 MCP 伺服器，通常就是為了填補「沒有 CLI、只有網頁介面或私有 API」的空缺。

不一定需要 MCP 的情境：如果目標服務已經有維護良好的 CLI 工具（例如 gh、aws、gcloud），直接讓 Claude 呼叫這些工具，通常比接一個 MCP 伺服器更省事——不用管連線、認證權杖更新、伺服器是否公開暴露這些額外的維運負擔，而且 Day 22 提過 CLI 工具不會有任何「工具清單」的 context 開銷。

一個簡單的判斷句：先問「這個服務有沒有好用的 CLI？」有,優先用 CLI；沒有,才考慮接 MCP。 兩者不是互斥的——同一個工作流裡，同時用 CLI 工具處理一部分、MCP 伺服器處理另一部分（例如今天第七節的 Before/After 範例接的 Jira，多數團隊不會有 Jira 的官方 CLI），是很常見的組合。

Before / After：接一個外部工具的兩種寫法

❌ Before：自己寫一套客製化工具定義，手動維護

tools = [{
    "name": "search_jira_issues",
    "description": "手動維護的 Jira 搜尋工具描述……",
    "input_schema": {...},  # 手動對照 Jira API 文件自己寫
}]
# 每次 Jira API 改版，這裡都要跟著手動更新

✅ After：接上官方或第三方提供的 MCP 伺服器

response = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=1000,
    messages=[{"role": "user", "content": "有哪些未解決的 Jira bug？"}],
    mcp_servers=[{
        "type": "url",
        "url": "https://your-jira-mcp-server.example.com/sse",
        "name": "jira-mcp",
        "authorization_token": JIRA_TOKEN,
    }],
    tools=[{"type": "mcp_toolset", "mcp_server_name": "jira-mcp"}],
    betas=["mcp-client-2025-11-20"],
)

Before 版本每接一個新服務就要重新設計一套工具 schema，服務改版你也要跟著改。After 版本把「工具長什麼樣子」的維護責任交給 MCP 伺服器本身——你只負責決定要不要接、開放哪些工具，這正是 MCP 作為「通用協定」的價值所在。

本篇自我挑戰

• 今日挑戰：如果你的團隊有內部系統（例如工單系統、內部知識庫），評估一下有沒有現成的 MCP 伺服器可以接，或者接一個公開的 MCP 伺服器（例如官方範例的 example-mcp）試跑一次今天的基本範例，觀察回應裡的 mcp_tool_use 與 mcp_tool_result 區塊長什麼樣子。

• 反思：MCP 的核心價值是「一次實作、到處能用」的協定思維，這跟 Day 18 講的 XML 標籤、Day 17 的 prompt 骨架其實是同一種精神——用標準化的結構，換取跨場景的可重複使用性。 你在自己的工作裡，有沒有類似「每次都重新客製化，卻其實可以標準化一次就好」的地方？

總結

MCP 是一套讓 Claude 存取外部工具的通用協定，今天講的 MCP Connector 是 API 層級最直接的接法——不用自己管理 MCP client，只要伺服器公開暴露在 HTTP 上。mcp_servers 定義連線、tools 裡的 mcp_toolset 定義權限，允許清單、拒絕清單、延遲載入三種模式可以組合使用。

記住兩個容易被忽略的限制：目前只支援工具呼叫，其他 MCP 功能要靠 client-side SDK；不符合 ZDR 資格，資料保留採標準政策。計價上是好消息——跟一般請求同一套費率，批次 API 也能用。

本日關鍵字回顧

• MCP（Model Context Protocol）：讓 AI 存取外部工具與資料的通用協定，服務提供者實作一次，任何支援 MCP 的應用都能接上。
• MCP Connector：API 層級直連遠端 MCP 伺服器的方式，透過 mcp_servers 與 mcp_toolset 兩個參數設定。
• 智慧觸發：Claude 只在真正需要外部資料時才呼叫 MCP 工具，一般性知識問題直接回答，不產生額外呼叫成本。
• 允許清單 / 拒絕清單 / 延遲載入：三種常見的工具配置模式，拒絕清單適合唯讀或需人工確認的場景。
• 限制：僅支援工具呼叫（不含 prompts/resources）、伺服器須公開於 HTTP、不符合零資料保留資格。

明天從 Claude Code 這種現成工具，回到最基礎的一層——自己寫程式呼叫 Claude API。第一支 Messages API 請求，以及為什麼你不該在瀏覽器裡直接呼叫它。

Day 24，Messages 端點入門。