把公司內部系統、資料庫、SaaS 包成 AI 可呼叫的工具，是讓 AI 從「會聊天」變「會動手」的關鍵水管工程。 Model Context Protocol（MCP）就是這條水管的標準——它標準化了「AI 怎麼連工具」，就像 REST 標準化 web service、Docker 標準化部署。2025-12 Anthropic 把 MCP 捐給 Linux Foundation 底下的 Agentic AI Foundation（Anthropic、Block、OpenAI 共同創辦，Google/Microsoft/AWS/Cloudflare 支持），確立它的中立標準地位（官方公告）。
核心架構
- 三層參與者：MCP Host（Claude Code、Cursor、VS Code 等 AI 應用）為每個要連的 server 建一個 MCP Client，各與對應 MCP Server 維持專屬連線。
- 兩層協定：Data layer（JSON-RPC 2.0，處理生命週期、能力協商、primitives）+ Transport layer（Stdio 本機高效／Streamable HTTP 遠端 + OAuth 認證）。
- 三大 primitives：Tools（模型主動決定呼叫，執行動作）／Resources（應用決定何時附加，唯讀情境資料）／Prompts（使用者選用的模板）。把該用 Resource 的唯讀資料硬包成 Tool，是常見設計失誤——會讓模型多一次不必要的「要不要呼叫」推理。
何時用 MCP vs 直接 API
- 用 MCP：三個以上服務要餵給同一工作流；需 runtime 動態工具探索；需跨多 agent 集中治理（一次更新 server，所有 agent 受惠）。
- 用直接 API：只對一個已知服務打固定端點；需要「精確、可重放、不容 AI 詮釋」的場景——金融交易、法規申報、審計（這類要確定性程式路徑）；機器對機器大量批次處理。
- 多數生產系統兩者並用。
Best practices：工具描述是投報比最高的優化（一手 Anthropic）
出自 Writing effective tools for AI agents：
- 把描述當成「跟新同事解釋」：情境依賴、術語、格式、資源關係都要講清楚，別假設模型「應該知道」。
- 命名消歧義：用
user_id而非user（後者三種歧義會讓模型猜錯）。prefix/suffix 命名法實測有可測量差異，要對真實任務跑過測試。 - 參數別暴露底層技術細節（UUID、MIME type），給高訊號、語意可解讀的欄位。
- 回應格式可調：加
response_format（detailed/concise）——官方 Slack 案例讓單次回應從 206 token 降到 72 token。 - 錯誤訊息要具體可行動：引導模型走向更有效率的策略（如「改用多次小範圍搜尋」）。
- 高槓桿優先：做能大幅擴展能力的工具，而非對既有 API 逐一薄包裝；能把多個離散操作整併於單次呼叫。
- 開發流程 Prototype → Evaluate → Collaborate：設計需要多步工具鏈的真實評測任務，再把完整 transcript 餵回 Claude 當「工具稽核員」自動找描述不清處。
Skills vs MCP：2026 年的新分工
- MCP 負責「連接」（存取外部系統）；Skills 負責「教」（重複性的操作知識，漸進式揭露：中繼資料 ~100 token、完整指令 <5k token）。
- Context 成本對比很鮮明：Skill 未觸發只佔 ~30–50 token；一個「5 個 server、58 個工具」的設定，對話還沒開始就可能先吃掉 ~55,000 token。這正是把「連接」與「教學」拆開的動機——不是每個能力都該用「隨時掛著的工具定義」實現。
- 官方 Code execution with MCP 解法：讓 agent 用「寫程式碼」呼叫 MCP、按需讀取工具定義，範例把 token 從 150,000 壓到 2,000（−98.7%）——但需額外沙箱基礎設施，非零成本。
陷阱與安全
- 工具太多稀釋：50+ 工具時光是 schema 就佔 context 5–7%，還會導致工具幻覺、決策癱瘓。Cursor 對曝光給 LLM 的工具數設 40 個硬上限（二手，建議自行驗證當前版本）。
- Tool Poisoning：攻擊者把惡意指令藏進工具的 description/metadata——對使用者不可見，對模型可見，是目前 client 端最普遍的漏洞類型之一（Invariant Labs）。要把「工具描述」當攻擊面審視，而非純文件隨意寫。
- OAuth scope ≠ 授權已解決：scope 只給粗粒度邊界；細粒度、context-aware 授權必須在 server 端對每一次 tool call 重新檢查。
- 除錯工具本身也是攻擊面：MCP Inspector 舊版有 RCE 漏洞（CVE-2025-49596），連到惡意 server 會中招。
- 官方 reference servers 明確聲明是「教育範例、非生產就緒」，別原封搬上生產。
主張 vs 可佐證
- 可佐證（官方一手）：MCP 架構與協定、工具描述原則（Slack 206→72 token）、code execution 98.7% 降幅、AAIF 捐贈治理、GitHub/Cloudflare/Sentry 官方 server 網址、Skills vs MCP 分工、CVE-2025-49596。
- 中：工具定義 550–1,400 token/個、5 server 58 工具 ~55,000 token（多來源量級一致，無單一一手測量）。
- 弱/行銷：「80%+ Fortune 500 部署」「導入後整合時程縮短 60–80%」——廠商部落格互相引用，無可追溯方法論，只能當背景。
工具讓 agent 能動手，怎麼編排多 agent 見 Agentic Workflow；工具過多的 context 成本見 Context Engineering 與 成本與路由；安全面深入見 AI 安全與 Guardrails；用 MCP 讀觀測性資料除錯見 系統化除錯。