什麼是 MCP(Model Context Protocol)?AI 界的 USB-C

如果你用過 Claude Desktop 連檔案系統,或在 AI 工具裡看過「Connect to GitHub」按鈕,你已經在用 MCP 了。Model Context Protocol 是 Anthropic 2024 年底推出的開放協議,讓 LLM 應用能透過統一介面跟外部工具溝通。一年多後,它已經是 AI 工具圈的主流整合協議 — Claude、Cursor、Windsurf、Continue、好幾十個 agent 都採用。

MCP 解決什麼問題

MCP 出現之前,每個想讀你 Notion、GitHub、資料庫、本機檔案的 AI app,都要為每個資料來源各自寫一份整合。Cursor 的 GitHub 支援是一份 code,Claude Desktop 的 GitHub 支援是另一份,Windsurf 又是另一份。工具方(GitHub、Notion、Linear)也得跟每個 AI 客戶端各別寫(或求他們寫)整合。

MCP 把這件事壓成一個協議:

MCP server 暴露工具、資源、prompt。每個資料來源或服務一個 server:GitHub server、Postgres server、檔案系統 server。
MCP client 是 AI app。Claude Desktop、Cursor、Windsurf — 全部講同一套協議。
任意 client × 任意 server = 可運作的整合。N×M 整合問題變成 N+M。

類比:MCP 之於 AI 整合,就像 USB-C 之於充電器。一個協議、隨插即用,所有東西突然都能跟所有東西接。

MCP server 實際暴露什麼

用協議的話講,三件事:

Tools — 模型可以呼叫的函式。每個工具有名稱、描述、輸入的 JSON schema。一個 GitHub MCP server 可能暴露 list_pull_requests、create_issue、get_file_contents。何時呼叫由模型決定。

Resources — 模型可以拉進來當 context 的唯讀資料。檔案系統 server 暴露檔案;資料庫 server 暴露表格。Resource 可以由 user 主動瀏覽(「把這個檔案附到對話」)或由模型自主抓。

Prompts — server 提供的常用 prompt 模板。GitHub server 可能提供「總結這個 PR」的模板,user 從選單就能 invoke。

大多數 server 主力放在 tools — 那才是動作所在。

實際長什麼樣

Claude Desktop 裝了檔案系統 MCP server:

你問:「我 ~/projects/builderworld 資料夾裡有什麼?」
Claude 呼叫檔案系統 MCP server 的 read_directory。
Server 回目錄清單。
Claude 唸給你聽,順便建議打開某個檔案。
你同意,Claude 呼叫 read_file 拿內容。

從 user 角度,Claude 就是「會」讀檔。從開發者角度,整個檔案系統整合是一個 ~200 行的 Python 或 TypeScript MCP server,任何支援 MCP 的 client 都能用。

現在怎麼用 MCP

如果你是使用者:大多數主流 AI client 都支援 MCP,從 registry 一鍵安裝。Claude Desktop 裡進設定、瀏覽可用 MCP server(filesystem、GitHub、Slack、Postgres、Notion 等)、安裝、授權。Cursor、Windsurf、大部分 coding agent 也有類似 UI。

如果你是 builder:你可以為自家產品/資料寫 MCP server。SDK 有 TypeScript、Python、Rust 等。最小可行 server:定義幾個 tool、跑 stdio 或 HTTP transport、跟 client 註冊。簡單 server 一個下午做得出來。

社群最大的 server registry 在 modelcontextprotocol.io 跟 GitHub 上。從資料庫到設計工具,幾百個都有。

為什麼這比看起來重要

MCP 不只是整合管線 — 它改變誘因結構。

對工具方來說,寫一個 MCP server 就跟整個 AI client 生態相容。Notion 寫一個 server,可以在 Claude、Cursor、未來的 ChatGPT、所有未來 AI 工具被使用。比起一對一整合 deal,投資報酬率好太多。

對 AI client 來說,MCP 等於不用自己寫就有上千個整合。Cursor 的價值不是寫 Slack 整合,是做一個好 IDE。MCP 讓整合由其他人負責。

對 user 來說,MCP 代表「我今天用的 AI,明天可能因為新 server 上架而獲得新能力,不用 app 更新」 — 裝個 server 就好。

Meta 效應:一個低耦合的健康生態,AI client 跟工具 server 可以各自演化。

什麼時候不要用 MCP

**一次性腳本。**只需要從自己 LLM 腳本叫一次 API,直接用 SDK + HTTP 比起 MCP server 快多了。
**自家產品內部 hot path。**MCP 多一個 process 邊界跟協議開銷。如果是你 SaaS 內部的 chat 呼叫自家 DB,直接呼叫更精簡。
**不可信 server。**安裝一個來路不明的 MCP server,等於給它 AI client 的工具權限。把 MCP server 當瀏覽器擴充來看 — 只裝你信任的。

安全注意事項

幾個真實風險:

惡意 MCP server 可能外洩 AI 看到的資料。
暴露一個名字看起來無害的工具的 server,可能誘導模型呼叫(跟 prompt injection 重疊)。
工具描述會進 prompt — server 描述如果是惡意的,可能改變模型行為。

大多數 MCP client 現在有權限 UI(「Allow Claude to use this tool: 是/否」),但協議本身不強制 sandboxing。對 MCP server 保持合理戒心。