2026 MCP 深度解析
AI 時代的 HTTP 協定
台灣與香港的接案工程師、新創技術主管，多半已在 Cursor 或 Claude Desktop 裡見過「MCP Server」設定，卻很少把 Model Context Protocol（MCP） 和當年 HTTP 統一 Web 的歷史對照起來。2026 年 6 月，OpenAI、Google、Microsoft、Anthropic 四大陣營均已表態支援 MCP，社群登錄的 MCP Server 已突破一萬個——這不是某一家 IDE 的私有外掛格式，而是 AI Agent 連接外部工具與資料來源的通用協定層。本文從 TCP/IP→HTTP 的歷史類比切入，拆解 N×M 整合困境、USB-C 式通用介面、Host／Client／Server 三層架構、JSON-RPC 傳輸、與 REST 的本質差異，並說明 A2A 如何互補，最後附五步按日租用 Mac 隔離試跑清單。
📋 本文目錄
01 · 導語：從 HTTP 到 MCP
1990 年代，每家網站各自實作傳輸層與應用層格式，瀏覽器與伺服器之間缺乏共通語言。HTTP 的出現，把「請求—回應」語意標準化，讓 N 個客戶端與 M 個後端服務只需遵守同一套協定，就能在 TCP/IP 之上交換 HTML、JSON、圖片——Web 因此爆發。今天 AI 領域面臨類似局面：N 個 AI 應用（Host）想接M 個外部工具（資料庫、GitHub、Slack、本機檔案系統），若每家各自定義函式呼叫格式，整合成本呈 N×M 爆炸。
Model Context Protocol（MCP）由 Anthropic 於 2024 年底提出，2025–2026 年逐步捐贈至 Linux Foundation 旗下的 Agentic AI Foundation，成為業界共識的「AI 工具匯流排」。它不取代大語言模型本身，而是在模型與工具之間插入一層標準化的上下文與工具發現協定——就像 HTTP 不取代 TCP，但讓應用開發者不必再為每個網站寫專屬 Socket 協定。對台灣、香港團隊而言，理解 MCP 等於理解 2026 年 AI Agent 的「匯流排規格」：你的 Cursor、Claude Desktop、VS Code Copilot Agent 能否無縫接 Slack、PostgreSQL、內部 Wiki，取決於 MCP Server 是否標準化，而非某個 IDE 是否願意為你客製外掛。
02 · 三大整合痛點
在 MCP 普及前，我們觀察到接案團隊與企業 IT 最常踩的三個坑：
- 痛點一：每款 AI 工具各寫一套整合。 Cursor 有 @docs 與外掛市場，Claude Desktop 有 Connectors，Copilot 有 Extensions——同一個 GitHub API，可能要維護三套設定檔、三套 OAuth 流程。人力與稽核成本隨工具數量線性甚至指數成長。
- 痛點二：工具能力無法被模型「發現」。 REST API 文件寫得再完整，模型也不會自動知道有哪些 endpoint 可用。你需要手寫 Prompt 或 Function Calling schema，且每次 API 改版都要同步改 Prompt——這不是協定問題，是上下文發現（Discovery）缺失。
- 痛點三：本機與雲端邊界模糊。 Agent 既要讀 ~/Projects 下的原始碼，又要查雲端 Jira、又要呼叫內網 SQL——在主力 Mac 上混裝正式 API 金鑰、測試 MCP Server 與生產 OAuth，一次誤設就可能把 Token 燒進背景 cron。缺少隔離環境，團隊不敢試新 Server。
MCP 的設計目標，正是用一層協定同時解決「格式統一」「能力發現」「傳輸可審計」三件事——下文會逐項對照。
03 · N×M 困境與 USB-C 類比
假設你有 5 個 AI Host（Cursor、Claude Desktop、VS Code、Windsurf、自研 Agent）和 20 個常用工具（GitHub、Notion、PostgreSQL、Redis、Slack、Google Drive、本機 filesystem、Shell……）。若每家 Host 各自實作整合，最壞情況需要 5×20＝100 組客製連接器；每新增一個 Host 或工具，邊際成本不是 +1，而是 +N 或 +M。這就是業界口中的 N×M 整合困境。
類比硬體界：USB-C 之前，手機、筆電、相機各用 Micro-USB、Mini-USB、Lightning——出差要带一捆線。USB-C 不提升傳輸邏輯本身，但用統一物理介面讓 N 個裝置 × M 個充電器／Hub 降維成「插得上就能用」。MCP 對 AI 生態的角色類似：Host 只需實作 MCP Client，工具只需提供 MCP Server，兩邊對話語意固定，N×M 降為 N+M。
├─ 無 MCP：N 個 Host × M 個工具 ＝ N×M 客製連接器
├─ 有 MCP：N 個 Host 各 1 個 Client ＋ M 個 Server ＝ N+M
└─ 新增工具：只需 1 個 MCP Server，所有 Host 自動可發現
04 · Host／Client／Server 三層架構
MCP 規格把參與方分成三個清晰角色，避免「到底誰呼叫誰」的混淆：
| 角色 | 典型實例 | 職責 |
|---|---|---|
| Host | Cursor、Claude Desktop、VS Code Copilot | 使用者直接互動的 AI 應用；管理對話、模型路由、權限審批 |
| Client | Host 內建的 MCP 協定模組 | 代表 Host 與 Server 建立連線；處理 JSON-RPC 訊息、訂閱資源變更 |
| Server | @modelcontextprotocol/server-filesystem、postgres-mcp、自研企業 Server | 暴露 Tools（可呼叫函式）、Resources（可讀上下文）、Prompts（可重用模板） |
一次典型的工具呼叫流程：使用者在 Host 輸入「查詢上週 Slack #dev 頻道的部署討論」→ Host 的 LLM 決定需要 Slack MCP Server → Client 向 Server 發送 tools/call JSON-RPC 請求 → Server 呼叫 Slack API 並回傳結構化結果 → Host 將結果注入對話上下文。整個過程中，Host 不必知道 Slack REST API 的每個 endpoint，只需知道 MCP 協定層的 Tools 列表——這就是「能力發現」。
對 macOS 開發者而言，許多 MCP Server 以 Node.js 或 Python 程序跑在本機 stdio 或 localhost SSE 上；在 Apple Silicon 的統一記憶體架構下，多個 Server 程序與 IDE 共用記憶體頻寬，長時 Agent 任務比 x86 虛擬機更省電。但若 Server 需要讀取 Keychain 憑證或 TCC 保護的本機目錄，仍建議在隔離租用節點試跑，避免污染主力機權限設定。
05 · JSON-RPC 傳輸機制
MCP 在傳輸層採用 JSON-RPC 2.0，而非發明全新二進位格式。這是有意的工程選擇：JSON 可讀、除錯友好、各語言函式庫成熟，且與現有 HTTP／WebSocket／stdio 傳輸相容。核心訊息類型包括：
- initialize：Client 與 Server 握手，交換協定版本與能力位元
- tools/list：模型「發現」Server 提供哪些可呼叫工具
- tools/call：執行具名工具並回傳結構化結果
- resources/list 與 resources/read：讀取檔案、資料庫快照等上下文
- prompts/list：取得 Server 預置的可重用 Prompt 模板
// MCP tools/call 請求範例（簡化）
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "query_database",
"arguments": { "sql": "SELECT count(*) FROM orders WHERE date > '2026-06-01'" }
}
}
相較於早期各 IDE 私有的 Function Calling JSON schema，MCP 把「工具名稱、參數 schema、錯誤語意」標準化，讓同一個 postgres-mcp Server 可被 Cursor 與 Claude Desktop 共用，無需為每家 Host 維護 fork。傳輸通道方面，本機開發常用 stdio（Host 以子程序啟動 Server）；遠端或容器化部署則用 SSE over HTTP，方便在租用 Mac 上以 SSH 隧道暴露給團隊 PoC 驗收。
06 · MCP vs REST 對照
「MCP 會取代 REST 嗎？」——這是 2026 年技術簡報裡最高頻的問題。答案是否定的：MCP 與 REST 解決不同層次的問題。REST 是資源導向的 HTTP API 風格，面向人類工程師與傳統微服務；MCP 是面向 AI Agent 的工具發現與上下文注入協定，底層 Server 內部仍常呼叫 REST API。
| 維度 | REST API | MCP |
|---|---|---|
| 消費者 | 工程師、前端、後端服務 | AI Host 內的 LLM／Agent |
| 發現機制 | OpenAPI／Swagger 文件（人工閱讀） | tools/list 自動發現（模型可讀） |
| 會話語意 | 無狀態請求為主 | 支援長連線、資源訂閱、上下文流 |
| 傳輸 | HTTP verbs + JSON/XML | JSON-RPC 2.0（stdio／SSE／HTTP） |
| 典型用途 | CRUD、微服務邊界 | Agent 工具鏈、RAG 資料源、本機 filesystem |
| 安全模型 | API Key、OAuth2、 mTLS | Host 側審批 + Server 側 scope 限制 |
實務上，一個 Slack MCP Server 內部仍用 Slack REST API；MCP 的價值在於把「哪些工具可用、參數 schema 長什麼樣、錯誤如何回傳給模型」統一，讓 Host 不必為 Slack 單獨寫 Prompt 說明書。對企業架構師而言：對外 B2B 仍用 REST／GraphQL；對內 Agent 工具層加 MCP 適配器——兩者並存，而非二選一。
07 · 2026 四大廠商入局
2026 年上半年，MCP 從 Anthropic 社群實驗走向「四大陣營共同站台」的基礎設施協定，里程碑包括：
- Anthropic：協定原創者；Claude Desktop 原生 MCP Client；持續維護規格與 reference Server 實作。
- OpenAI：ChatGPT Desktop 與 Responses API 生態接入 MCP；Agent 工具鏈與 MCP 對齊，降低開發者遷移成本。
- Google：Gemini CLI、Antigravity 與 Google Cloud Agent 工具整合 MCP；同時推進 A2A（Agent-to-Agent）作為 Agent 間通訊補充（見下文）。
- Microsoft：VS Code Copilot Agent、GitHub Copilot 擴展 MCP Server 連接；企業場景強調 Entra ID 與審批閘道。
對台灣新創與接案工作室，這意味著：現在投資 MCP Server 適配，比投資某一家 IDE 私有外掛格式更抗供應商鎖定。你今天為 PostgreSQL 寫的 MCP Server，明天換 Host 仍可用——就像當年把業務 API 做成 REST，換前端框架不必重寫後端。
08 · 萬餘 Server 生態
截至 2026 年 6 月，MCP 社群登錄與 npm／PyPI 可發現的 Server 實作已超過 10,000 個，涵蓋：
- 開發工具：GitHub、GitLab、Jira、Linear、filesystem、git
- 資料與分析：PostgreSQL、MySQL、Snowflake、BigQuery、Redis
- 協作與通訊：Slack、Discord、Microsoft Teams、Gmail
- 雲端與基礎設施：AWS、GCP、Kubernetes、Docker
- 企業內部：Confluence、SharePoint、自研 CMDB／工單系統
數量爆炸帶來新問題：品質參差、惡意 Server、過寬權限。2026 年最佳實踐包括：只安裝有簽章或官方維護的 Server；在 Host 側開啟工具呼叫審批；用最小 scope 的 OAuth；在隔離 macOS 節點試跑未知 Server 再接入主力環境。MacDate 客戶常見路徑是：租用 Mac mini M4 節點 → 部署 3–5 個候選 MCP Server → 跑固定 Prompt 基準 → 對照延遲與權限 → 寫入 ADR 後退租擦碟。
09 · MCP 與 A2A 互補
Google 2025 年推出的 Agent-to-Agent（A2A）協定，常被誤解為 MCP 的競品。實際上兩者分工不同：
| 協定 | 連接對象 | 類比 |
|---|---|---|
| MCP | Agent（Host）↔ 工具／資料源（Server） | HTTP：瀏覽器 ↔ Web 伺服器 |
| A2A | Agent ↔ Agent | SMTP／XMPP：郵件客戶端 ↔ 郵件客戶端 |
場景举例：你的「程式碼審查 Agent」透過 MCP 讀 GitHub PR 與 CI 日誌；「部署 Agent」透過 MCP 操作 Kubernetes。兩個 Agent 之間要協商「這個 PR 可否合併」，則用 A2A 交換結構化任務與狀態——MCP 不管 Agent 對 Agent 的對話，A2A 不管 Agent 對資料庫的 SQL。2026 年企業 Agent 架構的合理分層是：底層 REST／gRPC 微服務 → MCP 適配層 → Host Agent → A2A 編排層。
10 · 五步租用 Mac 隔離試跑（HowTo）
- 租用隔離 macOS：Mac mini M4 起，SSH 接入；本機使用者、Apple ID 與 OAuth 工作階段與主力機完全隔離。方案見 裸機 macOS 定價。
- 部署 MCP Host 與候選 Server：在租用節點安裝 Cursor 或 Claude Desktop，並以
npx或uvx啟動待測 MCP Server（如 filesystem、postgres、Slack）。設定檔與主力機對齊但使用測試 OAuth。 - 跑固定工具呼叫任務包：選三類基準——本機檔案 grep、資料庫 SELECT、外部 API GET——用同一組 Prompt 分別執行，記錄成功率與 JSON-RPC 往返延遲。
- 對照權限與稽核維度：記錄 Host 工具審批彈窗頻率、Server scope 是否過寬、SSE 連線在租用節點的伺服器頻寬下是否穩定；估算正式接入後的記憶體佔用。
- 匯出 ADR 並釋放環境：將 MCP Server 選型與安全結論寫入團隊文件，吊銷測試金鑰、登出 OAuth、退租擦碟。細節見 按日租用 Mac FAQ 與 OpenClaw MCP 接入指南。
11 · 常見問題
Q：MCP 會取代 OpenClaw 外掛嗎？ 不會完全取代。OpenClaw 有自己的 Gateway 與外掛審批模型；MCP 是更通用的工具協定。OpenClaw 已支援接入 MCP Server，兩者可並用——詳見站內 OpenClaw MCP 實操文。
Q：小公司需要自建 MCP Server 嗎？ 若只用 GitHub + 本機檔案，直接用社群 Server 即可。若有內部工單／CMDB API，建議寫一層 thin MCP 適配器，把 REST 包成 tools/list 可發現的工具，比讓模型直接讀 OpenAPI 文件可靠。
Q：stdio 和 SSE 怎麼選？ 本機單使用者開發用 stdio 最簡單；團隊 PoC 或遠端 Host 用 SSE over HTTP，方便在租用 Mac 上透過 SSH 隧道暴露 127.0.0.1 服務給審核方驗收。
Q：10000+ Server 怎麼篩選？ 優先選官方或 Foundation 維護的 reference 實作；檢查 npm 下載量、GitHub 最近 commit、權限 scope 是否最小化；未知 Server 一律在隔離節點試跑。
Q：MCP 與 Cursor Agent Skill 有何不同？ Skill 是 Cursor 生態的 Prompt／工作流封裝；MCP 是跨 Host 的工具協定。Skill 可呼叫 MCP Server，兩者互補而非替代。
12 · 結尾：別在主力 Mac 混裝未知 MCP Server
MCP 讓 AI 工具整合從 N×M 降維到 N+M，但協定標準化不等於 Server 可信。一萬多個社群 Server 中，不乏過寬 filesystem 權限、硬編碼 API Key、或未審計的第三方 fork。在主力 Mac 上直接 npx @someone/random-mcp，等於把 Keychain、~/Projects 與正式 Slack OAuth 一次暴露給未知程序——且 macOS TCC 授權一旦批准，撤回比想像中麻煩。
若你需要可稽核的「Cursor vs Claude Desktop vs Copilot Agent 同一組 MCP Server 對照實測」證據，又與 Xcode／Apple 工具鏈同週期協作，在獨立 macOS 租用節點完成 1–3 天試跑再決定正式接入，通常比衝動全域設定更安全——Apple Silicon 的統一記憶體讓多 Server 並行試跑更省電，租用節點的伺服器頻寬也足以支撐 SSE 長連線 PoC。MCP 是 AI 時代的 HTTP；你的驗收環境，也該像當年 staging 伺服器一樣與生產隔離。