Model Context Protocol, MCP
「模型上下文協定」不是只為了讓 AI 更會聊天，
而是為了讓 agent 能在真實世界裡 做事、協作、創造價值 的一種協議，讓大家共用
MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems.
動機
以前的 AI 像「顧問」：只會回答，不會操作。
- 自己手動串接每個 API
與其他應用接口連線，包含查資料、看日曆、存取資料庫 - 每個模型（OpenAI、Anthropic…）都要不同格式
- 工程師只能「一個一個」寫接口，把 AI 綁到某個 API、某個工具
→ 成本高、難維護、還容易幻覺
Function Calling（工具時代的開端）
為了讓 AI「用工具」，各家模型開始支援：
- 用 JSON schema 描述可呼叫的 function
- 模型回傳結構化指令（例：
{"name": "get_weather", "arguments": {...}}）
→ AI 從「說話」升級成「能呼叫 API」但每家格式不同 → 出現痛點：
- 不相容（OpenAI / Claude / Gemini 都不同）
- 要重寫 glue code
- 無法共享工具
Tools / Plugins（多樣但混亂）
為了解決「每次都要重寫 API 整合」的問題，
各家模型推出自己的 插件（plugin / tool）生態系：
- ChatGPT Plugins（OpenAI）：用 manifest.json 定義 API + OAuth
- Claude Tools（Anthropic）：讓 Claude 直接呼叫 Google Drive、Slack、Notion
- Gemini Extensions（Google）：延伸至 Gmail、Docs、Drive、YouTube
- Copilot Connectors（Microsoft）：連接 Microsoft 365、Graph API
每個平台都設計自己的「工具描述格式」，例如：
- JSON schema 宣告輸入輸出
- OAuth2 或 API Key 做驗證
- LLM 根據使用者指令，自動選擇要調用的 plugin
→ 聽起來強大，但實際上「各自為政」，結果導致：
- 碎片化生態
- 每家插件格式不同，開發者要為不同平台重寫一次。
- 例：同一個「天氣查詢」功能，要做成三個版本：OpenAI、Claude、Gemini。
- 安全與授權難統一
- 各平台的 OAuth 機制不相容，無法集中控管。
- 缺乏統一審計與使用者授權記錄。
- 維護成噩夢
- 工具版本更新後容易壞；測試流程冗長。
- 不同平台的 SDK、API 改動頻繁，開發者疲於追版本。
- 缺乏跨平台協作
- Plugin 無法在不同模型間共用（Claude 無法用 ChatGPT plugin）。
- 工具之間無上下文共享能力。
MCP
MCP 想做的事：
要有一個所有模型都聽得懂的語言， 能讓 AI 自動發現、呼叫、驗證外部工具
把「AI 使用外部工具」這件事，標準化
讓任何支援 MCP 的模型都能：
- 自動偵測有哪些工具（discover）
- 知道該怎麼呼叫（invoke）
- 用一致格式回傳結果
→ 「一次串好，所有模型都能用」
架構角色（Host / Client / Server）
MCP 的世界裡，一共有三個角色，負責「誰控制誰、誰執行誰」
使用者 → Host → Client → Server → Client → Host → 回覆使用者
Host（主機）
例如：Claude 桌面版、Cursor 編輯器、VSCode 插件、或 ChatGPT App
它負責：
- 接收使用者輸入（prompt）
- 管理整個 AI session 的上下文
- 決定是否、何時讓模型去「呼叫外部工具」
Host 通常內建一個 MCP client，幫 AI 跟外界對話
→ 使用者直接互動的 AI 應用本體
Client（客戶端）
Host 與 Server 之間的「中介層」，負責通訊與轉譯
是 MCP 的「橋樑角色」
任務：
- 接收模型的工具呼叫（例如：
get_weather(city="Taipei")） - 用 MCP 規範的格式發送給 Server（可能是 JSON-RPC、SSE、HTTP Stream）
- 收到回傳結果後，再送回 Host → 由模型整合進回覆
→ 讓指令與資料在模型 ↔ 工具之間安全流動
Server（伺服器）
實際連接外部系統的程式／API，負責執行具體任務、回傳結果給 Client
- 可以是雲端 API（GitHub、Notion、Slack）
- 也可以是本地腳本（讀檔案、查資料庫、跑分析）
MCP server 會：
- 提供 工具描述 (tool metadata)：有哪些功能、參數怎麼寫
- 處理請求、回傳結構化結果
- 通常以 JSON 或流式格式回傳資料
傳輸協定（Transport Protocols）
MCP 並不是綁死在單一網路協定上，而是提供多種「Host ↔ Server 溝通管道」方式，不同協定適合不同場景（本地開發、雲端整合、即時串流）
Stdio（Standard Input / Output）
最早期、也是最穩定的 MCP 傳輸方式
常用於「本地工具或 CLI 程式」與模型互通
原理，利用作業系統提供的三個資料流：
0 → stdin（輸入）
1 → stdout（輸出）
2 → stderr（錯誤）
Host 啟動 MCP server 時，互相傳送 JSON
- 不需網路，低延遲、安全、可離線運作
- 適合整合到本地 IDE、CLI、桌面應用（如 Claude Desktop、Cursor）
SSE（Server-Sent Events）
Server 單向推送協定（HTTP-based streaming）
由瀏覽器時代的 EventSource API 延伸而來
原理：
- Host 發起一次 HTTP 連線
- Server 不結束連線，而是持續用 event-stream 格式「推送訊息」
- 每次 Server 有新進度／輸出，就即時傳送給 Host
優點：
- 支援「流式更新」，模型能邊等邊輸出結果（像 ChatGPT typing 效果）
- 基於 HTTP，跨語言、跨平台相容性高
Streamable HTTP（新式傳輸方式）
MCP 近期升級版本的主流選擇。
是對 SSE (Server-Sent Events) 的進化版，採「可雙向流式傳輸」的 HTTP 通訊模式
因為有些缺點：
- 傳輸格式僅限文字（
text/event-stream），不支援二進位資料 - 單向通道：Server → Host；Host 無法主動推送回應
原理：
- 同樣基於 HTTP，但使用 chunked encoding / duplex stream 技術
- 允許雙方（Host ↔ Server）在同一連線上「邊發送、邊接收」
- 可傳文字、JSON、或二進位檔案（例如圖片、CSV）
| 協定類型 | 資料方向 | 即時性 | 跨平台 | 適用場景 | 備註 |
|---|---|---|---|---|---|
| Stdio | 雙向（本機） | ★★ | ❌ | 本地 Agent、IDE | 穩定、低延遲 |
| SSE | 單向（Server → Host） | ★★★ | ✅ | 雲端串流回覆 | Web 最常見 |
| Streamable HTTP | 雙向（全雙工） | ★★★★ | ✅✅ | 跨系統 Agent、長任務 | 新標準、支援二進位 |
為什麼產生（動機）
以前的 AI 就是「會說話但不會動手的顧問」
- 與其他應用接口連線，包含查資料、看日曆、存取資料庫
- 工程師只能「一個一個」寫接口，把 AI 綁到某個 API、某個工具
所以 Function Calling 出現了，提供了不同的參數、模型、微調選擇
最重要的是讓模型有使用工具的能力！ → Tools
這些 Tools 會透過 JSON 的方式和模型溝通
但是！各家廠商的格式不同會導致開發成本提升，或是無法自由切換，結果就是：
- 協定不一致：每接一個新工具，就要重寫一堆程式碼
- 整合複雜：每個模型 + 工具都要維護獨立接口，難以擴展 → 開發者會很辛苦
- 幻覺問題：模型還常常因為資料過時而「亂講」，因為它根本拿不到即時訊息
- 缺乏安全治理：跨系統呼叫沒有一致授權、審核、日誌機制沒有一致規範 → 存在資安風險
→ MCP 出現：它就是要蓋一條「標準化的大橋」，讓所有 AI 都能用同樣的方式安全走出去，接觸外部世界，產生的理由可能包含：
- 工具語言的不同，無法直接應用 → 可以打包成執行檔，或本地啟動一個執行緒
- 源碼保密的關係 → 發布成 API 的方法
總結
MCP 帶來的價值
- 統一標準：AI 與工具間格式一致
- 能力擴充：AI 能執行 API、workflow、寫入資料庫
- 上下文共享：跨工具保持語境連貫
- 一次整合，多方使用：一個 MCP server → 所有支援的模型都能用
- 安全治理：統一授權、審查、日誌規範
挑戰與注意
- 惡意 Server / 工具中毒
- Prompt 注入、執行風險
- 跨系統身份驗證
- debug 難，可觀察性不足
小補充
- Tool Metadata：MCP server 需回傳工具描述（名稱、參數、格式）供模型解析。
- MCP vs Function Calling：
- Function Calling 是「模型會呼叫工具」
- MCP 是「統一讓模型能呼叫任何工具的標準語言」
- MCP vs A2A（Agent-to-Agent Protocol） / ACP（Agent Communication Protocol）：MCP 是「人機協定」，A2A/ACP 是「AI 與 AI 的協定」。
其他
所有 client→server 請求都必須「驗證誰、並授權能做什麼」。