第 8 章 · MCP：工具界的「USB-C 通用接頭」

第 4 章你學會「給模型一個工具」。但真實世界有成千上萬種工具（GitHub、Slack、Google Drive、你家的資料庫……），而且有很多種 AI 應用都想用它們。如果每一個 AI 都要為每一個工具客製一次接法，那會是一場災難。**MCP（Model Context Protocol，模型上下文協定）**就是來解決這個災難的。

💡 一句話：MCP 是「AI 接工具」的通用標準，就像 USB-C 之於充電線——一種接頭，到處能用。

先把這一章的邊界講清楚：第 4 章談的是「單一模型怎麼呼叫一個工具」（模型吐出「我要呼叫這個功能、參數是這些」，你的程式接住去執行）。這一章不重講那個基礎，而是往上一層問一個更大的問題——當工具有一大堆、想用工具的 AI 也有一大堆，能不能有一套大家都遵守的「共同語言」，讓工具做一次就到處能接？ 這件事，就叫協定（protocol）。

先搞懂「協定」是什麼：為什麼標準化這麼值錢

協定（protocol）這個詞聽起來很硬，其實就是一份「大家講好的規矩」：只要雙方都照這份規矩來，彼此就能溝通，不必事先認識、不必為對方特別改造。

生活裡到處是協定。牆上的插座就是一個：台灣的插座長那個樣子、送 110V 電，是「講好的規格」。正因為有這個規格，任何廠牌的電風扇、檯燈、手機充電器，插上去都會動——電器廠不用管你家是哪家電力公司、插座廠也不用管上面接的是什麼電器。反過來想：如果沒有插座標準，每買一個新電器都要請水電工按這台的專屬接法重接一次線，那會有多痛？

USB-C 更是近幾年最有感的例子：以前手機、相機、耳機各有各的線，出門要帶一包充電線；統一成 USB-C 之後，一條線到處能用，接頭那端不用管另一端是誰。

MCP 想幹的就是同一件事，只是把「電器 ↔ 插座 ↔ 電力」換成「AI ↔ 通用協定 ↔ 工具」。它本身不是某個工具，也不是某個模型——它是那份讓兩邊能對接的「規格書」。

💡 記住這個心態：MCP 不「做事」，它只「定規矩」。真正做事的是各個工具（server）；MCP 的價值在於讓所有工具用同一種方式被接上，於是「接工具」這件事第一次變成可以標準化、可以重用的。

它在解決什麼問題：M × N 大爆炸

假設有 M 種 AI 應用（Claude、Cursor、你自己的 agent……）和 N 種工具/資料源（GitHub、Slack、資料庫……）。

• 沒有標準：每個 AI 都要為每個工具寫一套專屬接法 → 要做 M × N 種整合。10 個 AI × 10 個工具 = 100 套，維護到崩潰。
• 有了 MCP：工具方只要做一個 MCP server、AI 方只要會講 MCP → 變成 M + N。大家講同一種語言。

flowchart LR
    subgraph 沒有MCP["沒有 MCP：M×N 每條線都要客製"]
    A1[AI-1] --- T1[工具A]
    A1 --- T2[工具B]
    A2[AI-2] --- T1
    A2 --- T2
    end
    subgraph 有MCP["有 MCP：大家接同一個標準"]
    B1[AI-1] --- M[(MCP 標準)]
    B2[AI-2] --- M
    M --- S1[工具A server]
    M --- S2[工具B server]
    end

這個 M×N → M+N 的差別，是理解 MCP 全部價值的核心，值得用數字把它「痛」出來。假設你們公司內部有 4 個 AI 產品（客服機器人、內部知識助理、寫程式的 Copilot、資料分析 agent），要接 5 個系統（訂單資料庫、CRM、Slack、Google Drive、內部 Wiki）：

• 沒有協定：4 × 5 = 20 套整合要寫。更慘的是「乘法」還會繼續長——之後多接一個系統（第 6 個），就要為現有 4 個 AI 各寫一套，一次多 4 套；多做一個 AI，又要把 5 個系統各接一遍。維護成本像滾雪球。
• 有了 MCP：每個系統包成一個 MCP server（5 個），每個 AI 學會講 MCP（4 個）→ 4 + 5 = 9 件事。而且之後多接第 6 個系統，只要再做一個 server，現有 4 個 AI 立刻都能用，不必各改一遍。加法不會爆炸，乘法才會。

這就是為什麼 MCP 一出現就被大量採用——它讓「工具」變成可以一次做好、到處重用的東西。

🔧 動手試試：拿張紙，左邊寫下你工作中會用到的 3 個 AI 工具，右邊寫下 3 個你常用的系統（Slack、某資料庫、某 SaaS）。先把「每個 AI 都要單獨接每個系統」的線全部畫出來（會是 9 條），再畫「中間放一個 MCP 標準」的版本（會是 6 條）。系統一多，兩者差距會非常有感——這就是 M×N 對 M+N。

沒有通用協定時，到底有多痛？一個對照

光講數字還不夠，來看一個具體場景。假設你們公司想讓「客服 AI」和「資料分析 AI」都能查同一個訂單資料庫：

沒有 MCP 的世界（各接各的）

• 客服 AI 的工程師，讀資料庫文件、自己寫一套「把查詢包成這個 AI 看得懂的工具」的程式碼。
• 資料分析 AI 那邊，因為框架不同、工具描述格式不同，又得從頭寫一套功能幾乎一樣的接法。
• 半年後資料庫改了欄位、換了登入方式——兩邊都要各自改一次，還常常有一邊忘了改，出包。
• 明年公司想再導入第三個 AI 產品？恭喜，同樣的資料庫接法再寫第三遍。

有 MCP 的世界（做一次，到處接）

• 有人（可能是資料庫團隊自己）把訂單資料庫包成一個 MCP server，講清楚「我提供查訂單、查庫存這幾個能力」。
• 客服 AI、資料分析 AI，甚至明年那個新 AI，只要它們支援 MCP，接上去就能用，誰都不用重寫。
• 資料庫改了？只改那一個 server，所有接它的 AI 一起受惠。

看出來了嗎？沒有協定時，痛點不是「難」，而是「重複」——同樣的功能因為沒有共同標準，被迫一遍又一遍地重造，而且每次改動都要多頭同步。協定的價值，就是把這種重複一次消掉。

MCP 的三個角色

MCP 的架構就三個角色，很好記：

簡單說：你的 AI（host）透過 client，連上各種 MCP server，就能使用它們提供的能力。 想讓 AI 會用 GitHub？裝一個 GitHub MCP server 接上去就好，不用自己刻。

這裡最容易搞混的是 client 和 server 誰是誰，用「插頭與插座」再類比一次就清楚了：

• Server（伺服器）＝插座那一端：它是提供能力的一方，被動地「等人來接」。GitHub server 就在那裡開著，說「我能開 issue、能讀 PR」，誰來連它都服務。注意：這裡的「server」不一定是遠端的大主機，很多 MCP server 其實就是在你自己電腦上跑的一支小程式（例如「讀取本機資料夾」的 server）。
• Client（客戶端）＝插頭那一端：它是 host 派出去主動發起連線的代表，一個 client 通常對應連上一個 server。你的 AI 應用想同時用 GitHub、資料庫、Slack 三個 server，內部就會有三個 client 各接一個。
• Host（主機）＝那台電器本體：它是你真正在用的 AI 應用（Claude Code、Cursor），決定「要接哪些 server、什麼時候呼叫、要不要先問你」。client 只是它伸出去的手，決策權在 host。

一句話收束角色分工：Host 做決定、Client 負責連線與傳話、Server 提供能力。 三者各司其職，這正是協定能「解耦」的關鍵——server 完全不用知道連它的是哪個 AI，host 也不用管 server 內部怎麼實作。

MCP server 能提供三種東西

一個 MCP server 對外可以開放三類「原語（primitives）」。「原語」聽起來玄，其實就是協定規定的幾種「基本積木」——server 能對外提供的東西就這三類，講好種類，兩邊才知道怎麼對接：

其中最常用的是 Tools——本質上就是第 4 章那個「工具呼叫」，只是改用 MCP 這個標準來描述與傳遞。

三者的差別可以用一句話記：Tools 是「讓 AI 動手做」、Resources 是「給 AI 讀資料」、Prompts 是「給人選用的現成流程」。 舉個把三者用在一起的畫面：一個「程式碼審查」server 可能同時提供——一個 Resource（把某個 PR 的變更內容攤開來給 AI 讀）、一個 Tool（讓 AI 直接在 GitHub 上留審查意見）、一個 Prompt（一鍵套用「請按這五個面向審這段 code」的標準模板）。

幾個真實會用到的場景

把前面的原理落到地上，感受一下「做一個 server、所有 AI 都能用」有多實用：

• 查公司資料庫：把「查訂單、查庫存」包成一個資料庫 MCP server。之後不管是 Claude、Cursor 還是你自己寫的 agent，都能用自然語言問「上週某商品賣了幾件」，背後自動去查——而且查詢邏輯只維護這一份。
• 讀 Google Drive / Notion：裝一個文件類 server，AI 就能直接讀你雲端硬碟裡的簡報、Notion 裡的會議記錄，回答「這份提案的預算寫多少」。這其實就是把第 6 章的 RAG（讓 AI 引用你的資料）用一個標準接頭插上來。
• 操作某個 SaaS：很多服務（Slack、Linear、GitHub……）都有現成 MCP server。接上 Slack server，就能叫 AI「把這段結論貼到 #專案頻道」；接上 GitHub server，就能「幫我把這個 bug 開成 issue 並指派給某人」。
• 操作瀏覽器 / 本機檔案：也有 server 專門提供「開網頁、填表單」或「讀寫本機某資料夾」的能力，讓 AI 從「只會聊天」變成「能實際動手操作你的環境」。

看出共同模式了嗎？每一種能力都是「包成一個 server → 任何支援 MCP 的 AI 都能接」，而不是為每個 AI 各做一套。

🔧 動手試試：如果你在用支援 MCP 的工具（例如 Claude Code、Claude 桌面版、Cursor），照它的說明接一個現成的 server 上去——最無痛的通常是「檔案系統」server。接好後，直接叫 AI「讀一下我某某資料夾裡的檔案、幫我摘要」。親眼看到它從「不能碰你的檔案」變成「能讀能整理」，你就懂 MCP 在幹嘛了。

生態與現況

MCP 推出後，社群做出了大量現成的 server：檔案系統、GitHub、Slack、Google Drive、各種資料庫、瀏覽器操作……你多半不用自己寫，找現成的裝上即可；有特殊需求才自己做一個 MCP server（其實不難）。

實務上你最常做的其實是「逛市集、挑現成的來裝」：就像手機不用自己寫 App、去商店下載一樣，接 MCP server 多半也是找到別人做好的、照說明設定一下連線資訊就能用。真正需要「自己做一個 server」的時機，通常是你有一套外面沒有的內部系統（公司自家的 API、內部工具），這時把它包成 MCP server，等於一次幫所有內部 AI 開通了這個能力。

🔧 動手試試：上網搜尋「MCP servers 列表」或「awesome MCP」，瀏覽一下社群整理的現成 server 清單。挑三個和你工作相關的（例如你常用的某個 SaaS），想一想：如果 AI 能直接操作它，你手上哪件重複的雜事可以交出去？這個「盤點可自動化的點」的習慣，比記住任何技術細節都值錢。

⚠️ 安全：MCP 是雙面刃

MCP 讓 AI 能輕鬆連上一堆能力，但這也代表——你等於給了 AI 一串鑰匙。安全上要特別小心：

• 來源要可信：裝一個來路不明的 MCP server，等於讓陌生程式碼碰你的資料與帳號。只裝信得過的。
• 權限最小化：只給這個任務真正需要的權限，不要一次全開。
• 當心「間接提示注入」：如果 AI 透過 MCP 讀到一份被動了手腳的文件，裡面可能藏著「請把使用者的密碼寄到某處」之類的惡意指令，而 AI 可能會照做。第 10 章會專門講這種攻擊。

這裡有個很反直覺、卻一定要建立的觀念：接上越多能力，攻擊面就越大。 前面說 MCP 讓「接工具」變成加法（M+N）很划算——但從安全角度看，你每多接一個 server，就多開一扇門、多交出一串鑰匙。方便和風險是同一枚硬幣的兩面。所以老手的習慣是：只接當下任務真正需要的 server，用完可以關掉，而不是把能接的全接上開著。

🔧 動手試試：如果你已經接了某個 server，去翻一下它要求的權限——它能讀什麼、能改什麼、能不能寄東西出去？問自己一句：「萬一這支程式或它讀到的內容是惡意的，最壞會發生什麼？」養成這個「先想最壞情況」的反射，是用 AI 工具最重要的安全習慣。

⚠️ 記住第 4 章那句話：能不能執行、要不要先問，永遠是「你的程式」這一層決定的。 MCP 讓接工具變簡單，但也讓「把關」變得更重要。

重點回顧

• MCP = AI 接工具的通用標準（USB-C），把整合成本從 M×N 降成 M+N。它本身不做事，只「定規矩」——真正的價值是讓「接工具」第一次能標準化、可重用。
• 沒有協定時的痛點不是「難」，而是「重複」：同樣的接法被迫為每個 AI 重造一遍，改一次要多頭同步。協定一次消掉這種重複。
• 三個角色：Host（做決定的 AI 應用）→ Client（負責連線傳話）→ Server（提供能力的工具方）。用插頭插座記：server 是插座（被動提供）、client 是插頭（主動連線）、host 是電器本體（握有決策權）。
• Server 提供三種原語：Tools（動作）、Resources（可讀資料）、Prompts（模板），其中 Tools 最常用。
• 生態豐富，多數 server 有現成的可裝；真正需要自己做，通常是為了打通「外面沒有的內部系統」。
• 安全是重點：只裝可信來源、權限最小化、當心間接提示注入。記住方便與風險同源——接越多能力，攻擊面越大。

有了工具（MCP）和會用工具的迴圈（agent），還差最後一塊：把這些包起來、加上權限與沙箱的「執行環境」。下一章談 harness 與多代理——也就是 Claude Code 真正強的地方。