MCP 是什麼:AI 界的 USB-C

在 AI 沒有 MCP 之前,你的處境大概是這樣:你用 Claude 寫程式,但 Claude 看不到你的 GitHub;你用 Cursor 改 code,但它不知道你的 Jira 票在說什麼;你想讓 AI 幫你整理 Notion 筆記,但你用的是 ChatGPT,所以要先手動複製貼上——每一個 AI 工具,每連一個外部服務,都得各自做一套。這不只麻煩,而且根本不可能規模化。

MCP 就是來解這個問題的。它的全名是 Model Context Protocol,由 Anthropic 在 2024 年底提出並開源。一句話版本:MCP 是讓 AI 連接外部工具的統一標準,就像 USB-C 讓所有裝置共用一個充電接口一樣。

這堂學什麼

• M×N 問題:AI 連工具為什麼以前這麼痛
• USB-C 比喻:MCP 如何把 M×N 變成 M+N
• 三個角色白話文:host、client、server 各管什麼
• 2026 年生態現況:10,000+ server、哪些主流工具已支援
• 整個課程的路線圖:六堂課各做什麼

觀念一:M×N 問題——AI 與工具的整合地獄

想像你是一家公司的 IT 主管。公司裡有 5 個 AI 工具(Claude、ChatGPT、Cursor、Copilot、Gemini),員工要連接的外部服務也有 5 個(Notion、GitHub、Slack、Figma、Google Drive)。在沒有統一標準之前,每個 AI 想連每個服務,都要各自刻一套專屬的整合:

圖:MCP 官方文件(2026 年 7 月實況),來源:modelcontextprotocol.io

5 × 5 = 25 套整合,每套都要維護,每次 API 版本一改全部重來。這就是所謂的 M×N 問題——M 個 AI 工具乘以 N 個外部服務,等於 M×N 個客製化整合。

每個整合死掉的方式還各不一樣:Notion 改了 API,Claude 的 Notion 插件壞了,但 Cursor 的 Notion 插件不受影響——因為是兩組不同的人維護兩套不同的程式碼。這不是哪家公司偷懶,這是缺少標準的必然結果。

現實更殘忍:很多工具根本沒有人去幫它做整合。你想讓 AI 查公司內部 Wiki?那個 Wiki 系統太小眾,沒有任何主流 AI 的原生整合——所以你只能手動複製貼上,永遠都是。M×N 問題讓「AI 連上所有工具」這個承諾淪為空話。

觀念二:USB-C 時刻——MCP 怎麼把 M×N 壓成 M+N

USB-C 出現之前,手機要充電得看廠牌:iPhone 用 Lightning、Android 用 Micro-USB、某些筆電用 barrel jack,一個包包裡要帶三條線。2022 年歐盟強制統一,所有手機用 USB-C——現在一條線全搞定。

MCP 對 AI 生態做的是同一件事。規則很簡單:

• 每個工具做一個 MCP Server:按照標準格式宣告自己有哪些能力
• 每個 AI 應用做一個 MCP Client:按照同樣標準去呼叫 server
• 兩邊說同一種語言,接上就能用

結果:5 個 AI 工具各做一個 client,5 個服務各做一個 server,總共 5 + 5 = 10 個實作。每個人只需要維護自己那一塊,接上就能跟所有符合標準的另一邊溝通。

更重要的是:有了標準,小工具和大工具站在同一個起跑線上。你公司的內部 Wiki、你自己寫的 Python 腳本、你的 Obsidian 筆記——只要有人做一個 MCP server,任何支援 MCP 的 AI 工具都能連上它。這才是 USB-C 比喻最核心的那個點:不是大廠才有插頭。

觀念三:三個角色白話文

MCP 的架構裡有三個角色,官方文件用的英文術語初看很繞,但其實很直覺:

Host(宿主):你在用的 AI 應用程式。Claude Desktop、Cursor、VS Code 就是 host。它負責整個 AI 工作流的生命週期——決定連哪些 server、管理權限、把 AI 的回答顯示給你看。白話:「你打開的那個軟體」。

Client(客戶端):host 內部負責跟 server 溝通的那個模組。每個 host 裡面可以有多個 client,每個 client 對應一個 server 連線。這個角色你通常看不見,是幕後人員。白話:「host 派去跟 server 講話的使者」。

Server(伺服器):工具那一邊的程式。它宣告自己有哪些能力(「我會搜尋 Notion」、「我會列 GitHub PR」、「我會讀本機檔案」),等 client 來問。注意:MCP server 不一定跑在遠端機器上——很多 server 直接跑在你自己的電腦裡,由 host 啟動時自動拉起來。白話:「工具的翻譯員」。

一個完整的流程:你在 Cursor(host)說「幫我看看這個功能的 GitHub issue 在說什麼」→ Cursor 的 MCP client 用 MCP 協定問 GitHub 的 MCP server → server 去呼叫 GitHub API → 把結果回傳給 client → Claude 看到資料後組成答案給你。中間這整條管線對你完全透明,你只看到 AI 回答。

三個角色的分工讓整個系統可以解耦——Anthropic 不需要知道你用什麼 server,GitHub 不需要知道你用什麼 AI,兩邊各自按標準做自己的部分。這才是協定的力量。

觀念四:2026 年的 MCP 生態

很多新協定推出後只有幾個玩家支援就默默死去。MCP 不是這樣。

截至 2026 年,幾個關鍵數字說明它已經成氣候:

• 官方 registry 紀錄超過 9,600 個 server,公開可用的活躍 server 突破 10,000+(Anthropic 2025 年 12 月數據)
• SDK 月下載量超過 9,700 萬次——有人在用才會下載 SDK,這個數字代表開發者的真實採用量
• 主流 AI 產品全面支援:Claude Desktop、Cursor、Windsurf、VS Code(含 GitHub Copilot)、ChatGPT Desktop、Gemini CLI……幾乎你說得出名字的 AI 開發工具都已經是 MCP host
• 大廠官方 server 正式上線:GitHub、Notion、Stripe、Figma、Atlassian、Cloudflare 都推出由自己維護的官方 MCP server

這個格局有個重要含義:MCP 不再只是 Anthropic 的生態系——它已經成為業界事實標準。你今天學的技能,在 Claude 之外照樣用得到。

不過生態大也帶來一個現實問題:品質良莠不齊。真正有完整文件、持續維護、可信度高的 server 其實是少數——2026 年一份針對約 7,000 個公開 server 的安全分析就發現,超過四成完全不需要任何身分驗證。剩下的不一定不能用,但你在接上陌生 server 之前需要做一些基本評估——這是第 4 課的主題。

觀念五:哪些產品你現在就可以用

實際要接 MCP 之前,先確認你用的 AI 工具有沒有支援 host:

如果你是開發者,Cursor 或 VS Code 是最自然的起點;如果你主要用 AI 做非程式工作,Claude Desktop 是最直覺的 host。第 2 課的實戰會帶你在這些工具上裝第一個 server,本課程示範以 Claude Desktop 為主,每個關鍵步驟也會標注 Cursor 的對應做法。

手把手實戰:認識你的第一份 server 設定

裝之前先讀懂設定長什麼樣。這步不需要動任何東西——就是看一份 JSON 設定,確保你之後裝起來不是盲目貼上去的。

Claude Desktop (macOS):
~/Library/Application Support/Claude/claude_desktop_config.json

Claude Desktop (Windows):
%APPDATA%\Claude\claude_desktop_config.json

Cursor (macOS):
~/.cursor/mcp.json
(或從 Cursor → 設定 → MCP → Open MCP config)

VS Code:
.vscode/mcp.json(專案層級)
或 Command Palette → 搜尋「MCP: Open User Configuration」(全域)

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/yourname/Documents"
      ]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxxxxxxxxxx"
      }
    }
  }
}

你目前有哪些 MCP tools 可以用?列出來給我看。

常見坑

坑 1:把「MCP server」和「AI 工具的插件」混為一談

很多工具在 MCP 普及前就有自己的插件系統(ChatGPT 的 Plugin、VS Code 的 Extension)。MCP 是另一層,專門處理「讓 AI 在對話過程中即時呼叫外部工具」這件事。

典型症狀:你在 VS Code 安裝了「GitHub Copilot」插件,但 AI 還是看不到你的 GitHub issue。原因:Copilot 插件是讓 VS Code 能跑 AI;要讓 AI 能查 GitHub,你還需要額外裝一個 GitHub 的 MCP server。這是兩件完全不同的事情,一個是讓 VS Code 支援 AI,另一個是讓 AI 能讀 GitHub 資料。

坑 2:本機 server 和遠端 server 的差異沒搞清楚,以為 server 要一直跑著

MCP server 有兩種運行方式:

• 本機 (local):server 跑在你電腦上,由 host 啟動時自動拉起,設定裡用 command + args。Host 關掉,server 一起關
• 遠端 (remote):server 跑在某個雲端位置,設定裡用 url 指向連線端點,host 透過 HTTP/SSE 連線

初學者最常踩的坑:設定好 server 卻沒重啟 host,然後問「為什麼 AI 說它沒有這個工具?」——因為本機 server 是 host 啟動時才一起啟動的,改完設定一定要重啟 Claude Desktop 或 Cursor 才會生效。

另一個坑:設定 JSON 格式出錯(例如結尾多了一個逗號),host 靜默地忽略整個 mcpServers 區塊,不會顯示任何錯誤提示。症狀一樣是「AI 說它沒有工具」,但原因是 JSON 語法錯誤。解法:把設定貼進 jsonlint.com 驗證格式。

坑 3:看到 10,000+ server 就想全裝

看到 registry 有這麼多 server 很興奮,把一堆全部塞進設定——然後發現 AI 開始變慢、回答有時答非所問、有時還因為 tool 太多選錯。

每個連進來的 server 都會把自己的工具描述(名稱、參數說明、用途)傳給 AI 的 context window。你接 10 個 server、每個 server 有 5 個工具,AI 的 context 裡就多了 50 段工具說明——這會吃掉可用的 token 空間,讓 AI 在「要不要用這個工具」的判斷上更容易出錯。

原則:一開始只接你今天就會用到的 server,之後按需求慢慢加。第 3 課會教你怎麼組一個「日常工具組」,在工具數量和效能之間找到平衡點。

坑 4:設定裡有 API 金鑰,直接截圖貼給別人問問題

設定 JSON 裡如果有 API 金鑰或 token,分享時要把值換成佔位文字。貼給 AI 問問題、貼進論壇求助、傳給朋友——只要金鑰字串外洩,對應服務的權限就被別人拿走了。有些服務(尤其是有付費額度的 AI API)被盜用可能在幾小時內刷出大量費用。

正確做法:分享設定時把金鑰值換掉:

"env": {
  "GITHUB_PERSONAL_ACCESS_TOKEN": "填你自己的 token"
}

第 4 課的安全主題會完整展開這個議題,教你評估 server 的可信度以及金鑰管理的正確方式。

作業

1. 在你平常用的 AI 工具裡問:「你目前有哪些 MCP tools 可以用?」,把回答截圖存起來。第 2 課裝好第一個 server 之後再問一次,對比兩張截圖——這是最直接的學習成果驗收。

2. 到 mcp.so 或 modelcontextprotocol.io/servers 逛 10 分鐘,找出 3 個你有在用的服務的 server(例如 Notion、GitHub、Slack),把它們的名稱和 npm 套件名稱記下來——第 2、3 課用得到。

3. 找到你電腦上的 MCP 設定檔路徑(用手把手實戰第 1 步的對照表),用文字編輯器打開它,確認自己看得懂或看得到這個檔案——這是你以後所有設定的操作據點。

下一課預告

觀念清楚了,下一課要動手了。第 2 課會帶你在 15 分鐘內把第一個真正可用的 server 接上。我們選 Filesystem server 當起點:不需要任何 API 金鑰、裝上就能讓 AI 讀寫你電腦裡的檔案,效果立竿見影。你會看到設定從空的 {} 變成一個有能力的 AI 助理:問它「我的 Documents 資料夾裡有哪些檔案?」它真的去找給你看。裝完第一個之後,再帶你接一個需要 API 金鑰的 server,走完完整的設定流程。

整個課程路線圖: