如果你最近開始關注 AI Agent，一定看到了「MCP」這三個字母無處不在。Claude 有 MCP、Cursor 有 MCP、GitHub Copilot 要整合 MCP、每個 Agent 框架都在說「支持 MCP」。但很多人對 MCP 的理解還停留在「一種可以讓 AI 連接工具的協議」——這個描述沒錯，但太模糊，沒有解釋 MCP 在解決什麼具體問題、以及為什麼它對你用 AI Agent 很重要。
這篇文章從最基礎開始解釋 MCP：它的出現是為了解決什麼問題、怎麼運作、以及對你使用 AI Agent 的實際影響。
MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月提出的一個開放標準，定義了 AI 模型和外部工具之間如何通信。簡單說：它是 AI 和外部世界之間的「通用插頭」。
為什麼說「通用插頭」？想想電器的插頭：不同國家的插座不同，所以你的歐洲電器要在美國用，需要一個轉換器。AI 和工具的關係在 MCP 之前也是這樣——每個 AI 公司有自己的工具接入格式，每個開發者要讓 Claude 用某個工具，需要自己寫「轉換器代碼」（也就是 Function Calling 的格式化邏輯）。
MCP 的出現相當於：全世界統一用同一種插座——只要你的工具服務器支持 MCP，它就能被任何支持 MCP 的 AI 模型使用，不需要每個 AI 公司分別適配。
為什麼 2025 年突然重要起來？因為越來越多的主流工具（GitHub、Slack、Google Drive、Notion）開始發布官方 MCP Server，同時越來越多的 AI 產品（Claude、Cursor、Windsurf、Zed）聲明支持 MCP。標準正在形成「臨界質量」——使用 MCP 構建工具，一次開發就能被所有主流 AI 模型使用；不使用 MCP，就需要為每個 AI 平台分別維護一套接入代碼。對開發者和企業來說，MCP 的向心力越來越強。
要理解 MCP 解決了什麼問題，先看看 MCP 之前的世界。
在 MCP 出現之前，如果你想讓一個 AI Agent 能夠「查詢 Slack 消息」，你需要：第一，閱讀 Slack 的 API 文檔，寫代碼調用 Slack API；第二，把 Slack API 封裝成 LLM 能理解的格式（每個 LLM 平台的格式略有不同——OpenAI 的 Function Calling 格式、Anthropic 的 Tool Use 格式）；第三，在你的 Agent 代碼裡硬編碼這個工具的描述、參數格式、和調用邏輯。
如果你想讓 Claude 和 GPT-4 都能用這個工具，你需要寫兩份不同的適配代碼。如果你之後想把這個工具分享給其他開發者，他們還需要重新閱讀你的代碼才能理解怎麼用。
更麻煩的是「動態工具」的問題：有些工具的功能是動態的（例如一個 DeFi 協議的工具，隨著協議版本更新，可以調用的函數也會變化）。在 MCP 之前，每次工具更新，Agent 的代碼也需要跟著手動更新。
所有這些問題的根源是：沒有統一標準，每個「AI 和工具的對話」都是一次性的、定制化的工作。
MCP 有三個核心組成部分：
MCP Server（工具提供方）：把某個工具（Slack、GitHub、資料庫、DeFi 協議）的功能暴露為 MCP 格式的接口。MCP Server 的工作是：當有人問「你能做什麼？」，回答一個標準格式的工具列表；當有人發送「請執行這個操作」，執行並返回結果。GitHub 的官方 MCP Server 知道怎麼讀取 GitHub 倉庫、創建 PR、查詢 Issue；Slack 的 MCP Server 知道怎麼發消息、讀取頻道、搜索歷史。
MCP Client（AI 模型這邊）：Claude（或其他支持 MCP 的 AI）是 MCP Client 的角色。它的工作是：詢問 MCP Server「你有什麼工具？」，把這些工具描述加入到自己的 Context，在需要的時候選擇調用對應的工具，解析工具的返回結果。
MCP Protocol（標準通信格式）：定義了 Client 和 Server 之間通信的格式——就像 HTTP 是 瀏覽器和服務器之間的通信標準。MCP Protocol 定義了：怎麼列舉工具（`tools/list`）、怎麼調用工具（`tools/call`）、怎麼訂閱實時數據（`resources/subscribe`）等。
用一個類比理解：MCP Server 就像一個餐廳的菜單系統；MCP Client（Claude）是顧客；MCP Protocol 是點餐格式（「我要第 3 號，少辣」）。不管你去哪家餐廳，點餐格式都一樣——這就是「通用插頭」的意義。
在實際的 Agent 裡，一個典型的 MCP 工作流是：用戶說「幫我總結上週 Slack #general 頻道裡關於 Q3 產品規劃的討論」→ Claude 識別需要 Slack 工具 → 向已連接的 Slack MCP Server 請求工具列表 → 調用 `get_channel_messages(channel='#general', date_range='last_week')` → 接收結果 → 生成摘要回覆用戶。整個過程裡，Claude 不需要知道 Slack API 的具體細節，只需要知道 Slack MCP Server 提供的工具描述。
MCP 解決了很多問題，但作為一個剛起步的標準，它也帶來了新的風險，用戶需要了解：
工具描述的信任問題：MCP Server 的工具描述是由工具提供方自己定義的，Claude 相信這個描述。如果一個惡意的 MCP Server 把自己的工具描述成「幫你總結文件」，但實際執行的是「讀取你的私鑰並發送到遠程服務器」，Claude 可能察覺不到這個差異（因為 Claude 只看描述，不看工具的實際代碼）。這就是「Prompt Injection via MCP Tool Description」——攻擊者通過偽裝工具描述來操控 AI 的行為。
使用者要做的事：只連接你信任的 MCP Server（官方發布的、知名開源社區的、或你自己寫的）。每次給 Claude 連接新的 MCP Server 時，想一想「這個 Server 的工具，在最壞的情況下能做什麼？」——如果答案是「讀取我的 GitHub 私有倉庫」或者「訪問我的銀行帳戶」，確保你理解這個 Server 的工具描述是合法的，且工具的實際行為和描述一致。
版本不一致的問題：MCP 協議本身還在快速演化，不同版本之間可能有不相容的地方。一個用舊版 MCP 格式寫的 Server，在新版 MCP Client 裡可能出現工具無法識別的問題。使用社區或官方的 MCP Server 時，留意版本相容性。
工具數量的 Context 成本：每個連接的 MCP Server 的工具描述都會佔用 Claude 的 Context Window。如果你連接了 10 個 MCP Server，每個有 20 個工具，光是工具描述就可能佔用幾千個 Token，減少了 Claude 用來處理你真實需求的 Context 空間。建議：只連接當前任務需要的 MCP Server，任務完成後斷開不需要的連接。
作為用戶（使用 Claude.ai 或其他有 MCP 支持的工具），MCP 讓你可以把 Claude 連接到你真實使用的工作工具，讓 Claude 不只是一個問答工具，而是真正能訪問你的 GitHub、Slack、Google Drive 的助手。在 Claude.ai 裡，你可以在設置裡找到 MCP 連接選項（或稱為「Connectors」），選擇你想連接的工具。
作為開發者（在建構自己的 Agent），MCP 意味著：你不需要為每個工具都從零寫適配代碼了。如果你想讓 Agent 用 GitHub，直接接 GitHub 的官方 MCP Server；想用自己的內部資料庫，按照 MCP 的格式寫一個 MCP Server，之後這個 Server 就能被任何支持 MCP 的 AI 模型使用。學習一個 MCP Server 的寫法，比學習每個 AI 平台的工具格式更有投資回報。
對 DeFi 和 Onchain Agent 開發者：MCP 的潛力在於讓 Agent 能動態發現和使用鏈上的工具接口（協議的 MCP Server），而不是硬編碼每個協議的 API 調用。這個方向還在發展中，但 MCP 的標準化讓 Onchain Agent 的工具接入有了更可持續的架構基礎。