雲端方程式 Cloud F1 F1

MCP

MCP 協議深入解析｜架構原理與元件完整理解

· 約 18 分鐘閱讀 · Alex Hsieh

更新於 2026年2月11日

MCP 協議深入解析

📥 工作流 JSON 下載：GitHub 範例庫 ｜ 💬 社群討論：Skool 雲端方程式 Cloud F1

專業導讀

OK，今天的內容我們會有六個部分。第一個部分，我會先帶大家快速用一分鐘來了解 MCP 的運作架構；接下來我們會 Demo 兩種情境，讓你知道 MCP 的混用搭配是怎麼樣最好的；再來我們會用兩種方式來說明架構 — 一個是給阿嬤聽的 MCP 架構，另一個是給開發者聽的 MCP 架構。最後我們講五大金剛（MCP 的五大元件）以及五大角色球員（MCP 支援的五大功能）。

MCP (Model Context Protocol) 是一套定義 AI 應用程式如何與外部工具溝通的開放標準協議。 它就像秦始皇統一度量衡一樣，或者像聯合國一起用英文做官方語言，讓所有的 AI — 不論是 LLM 還是應用層的 AI 代理 — 都用統一的語言來溝通。MCP 強調的是溝通處理的能力，並不是本身記憶的功能。

這篇文章是我在影片裡面深入研究 MCP 運作原理架構的文字版本，這一部是很燒腦的。如果你對 MCP 還不了解，建議先看我的 MCP 完整指南，再來啃這一篇。

你將學到

  • MCP 的核心概念：為什麼我說它是 AI 世界的 USB-C
  • 兩個實際 Demo 情境：從 Airtable 拉客戶資料 + Airbnb 訂住宿、Tavily 抓時事存 Notion
  • 給阿嬤聽的 MCP 架構解說（USB 類比版）
  • 給開發者聽的五大金剛：Host、Client、Server、Local Storage、Remote Service
  • 五大角色球員：Prompt、Resource、Tool、Root、Sampling 完整拆解
  • 我的三個 MCP 實戰理解，幫你避開常見誤區

什麼是 MCP 協議？

MCP (Model Context Protocol) 是由 Anthropic 在 2024 年底發布的開放標準，定義了 AI 模型與外部工具之間的標準化通訊介面 — 簡單來說，它就是 AI 世界的 USB-C，一個統一的接口標準，讓任何 AI 應用都能用同樣的方式連接任何工具。

根據 MCP 的官方定義，MCP 是一種開放的協議標準，像 LLM 大語言模型提供上下文。你可以把它想像成是 USB-C 的連接 — 一種統一的連接方式，不論是接手機、接電腦，各種接只要能夠通訊就行。MCP 的設計目標就是成為 AI 跟各種資料源的溝通橋樑，用一致的方法來溝通。

我在影片裡面跟大家說過，MCP 最大的特色是強調 AI 代理之間的溝通跟協作能力。所以最強的應用其實就是混用搭配 — 我們可以利用多工具的整合跟任務的串接，這才是最強的。

在 MCP 出現之前，每個 AI 平台都有自己的工具整合方式。OpenAI 有 Function Calling，Google 有 Tool Use，各家做法不同，工具開發者必須為每個平台分別開發整合。這就像早期手機充電器的亂象 — 每家品牌一種接頭。

重點來了 — MCP 不是要取代 Function Calling。Function Calling 是 LLM 層級的能力（模型能描述它想呼叫什麼函數），MCP 是應用層級的協議（定義工具如何被發現、描述和呼叫）。兩者是互補的關係。

MCP 實際 Demo：兩種應用情境

在講架構之前，我先帶你看兩個我實際 Demo 的情境，讓你先感受 MCP 到底能做什麼事情。

情境一：個人助理 — 查客戶 + 訂住宿

我請 AI 扮演個人助理完成兩件事：第一，從 Airtable 裡面拿潛在客戶名單；第二，根據客戶的地址去 Airbnb 幫我預訂住宿。

這個任務基本上分成三步。我們先請它給我們潛在客戶名單 — 在一個 Table 裡面找出標記為「潛在客戶」的人。第二步，根據這些潛在客戶名單裡面的地址，幫我訂這個禮拜的住宿。

我透過 n8n 觸發了這個流程，AI 會先問有哪些工具可以用 — 像 Airtable 有哪些工具可以使用，然後它就去執行。Airbnb 那邊它也會問有哪些方法可以用，然後再去執行說我要去看有哪些住宿的地方。

結果出來了 — 潛在客戶找到了，像宏達這個客戶訂了兩個住宿，盛達也訂了兩個。它會根據這些客戶的地點到 Airbnb 裡面找，一個在台中，一個在曼谷。你要知道，這件事情其實是 MCP 很厲害的地方。

但我也要老實說，語意的理解其實是 MCP 的挑戰 — 你要給它清楚的指令。

情境二：自動搜索時事 + 存到 Notion

第二個例子，我們希望 AI 自動搜索每日的關鍵字時事，然後把它存到指定的任務。做法是利用三個工具：先做網路搜尋去找五個 AI 時事，再把它整理成 Markdown，然後存到 Notion 頁面。

我們用了 Tavily — 一個 Connect Your LLM to the web 的服務，它會去網路上抓資料。抓了五個熱門的 AI 時事然後存到 Notion，像美國空軍自主飛行這種新聞確實都有對應的網站，而且都成功存到我的 n8n-news 裡面了。

但我要提醒你，MCP 不是萬靈丹，它有時候還是會失敗，比如說內容的格式驗證這一塊。

Alex 的實戰觀察

讓我分享我的三個 MCP 理解，這是我在影片裡面直接跟大家講的，也是我從實戰中歸納出來的。

觀察 1：MCP 很適合用來做 POC

MCP 很適合拿來做 POC（Proof of Concept），就是做一個小型的概念驗證。為什麼？因為它會比改 Restful API 還要快。我的建議是先能夠實現商業價值，來逐項優化會比較好 — 先拿來做快速驗證。

觀察 2：不要有工具的迷思

MCP 不是萬能的，不是所有的任務都需要 MCP。AI Agent 不要只靠 MCP，有時候用 API 整合更快。例如像 Gmail、Google Sheet 這些常見的工具，其實 API 是比較快的。所以要根據你的使用場景來決定，而不是一味地用 MCP。

觀察 3：AI Agent 要專注在一項特定的任務

這個我覺得很重要 — AI Agent 最後常常被用得很像通用智能，又要做 A 又要做 B 又要做 C，什麼都要能做。但我認為 AI Agent 最好讓它只做一件事情，比如找住宿、找時事、存資料，這種它就會表現得比較好。

觀察 4：Tool Description 是成敗關鍵

我開發了好幾個 MCP Server，最大的心得就是：Tool 的 description 寫得好不好，直接決定 AI 能不能正確使用。 不是開玩笑，我改了一個 Tool 的 description，使用成功率從 60% 飆到 95%。好的 description 要包含：做什麼、什麼時候用、什麼時候不該用、參數的語意（不只是型別）。

觀察 5：與 n8n 的整合體驗很好

n8n 2.0 原生支援 MCP，我在 n8n 的平台裡面用最多的就是 Tool 功能。你可以在 n8n 裡面直接連接任何 MCP Server，用 AI Agent 節點呼叫 MCP 工具。這讓 n8n 從「自動化工具」升級成「AI Agent 平台」。

如果你對 n8n + MCP 的實作有興趣，推薦看我的 MCP 完整指南，裡面有完整的設定教學。

給阿嬤聽的 MCP 架構：USB 類比版

我在影片裡面用了一個非常好懂的方式來解釋 MCP — 用 USB 的運作來對比 MCP 的邏輯。

🔧 情境：手機照片傳到電腦

想像一下，你要把手機的照片傳給電腦。怎麼做？拿 USB 來接，把電腦跟手機接起來開始傳照片。溝通的方式就是 USB 的 Protocol。

那這個跟 MCP 有什麼關係？MCP 就是跟 AI 跟外界溝通的統一語言，跟 USB Protocol 的概念一模一樣。

我們來一步步對應：

USB 世界MCP 世界說明
手機裡面的照片資料內容（Data）我們要傳的東西
USB 連接線MCP Client負責建立連接
USB 接收設備（電腦）MCP Server接收並處理資料
電腦硬碟Local Storage存在本地的檔案資料
雲端硬碟Remote Service存在遠端的服務
USB 3.0 標準MCP Protocol統一的溝通標準

所以整個流程就是：手機透過 USB 傳送照片到電腦，存到電腦硬碟或者放到雲端硬碟裡面，看你要存在哪裡 — 一個是存在 Local 本地，一個是存在遠端 Remote Service。

MCP 的邏輯也是一樣：AI 應用透過 MCP Protocol，把資料從 MCP Server 取出來，存到本地的資源或者透過 Web API 連到遠端的服務。

給開發者聽的 MCP 架構：五大金剛

OK，從開發者的角度來深入理解一下 MCP 的架構。我們參考 MCP 官方的說明，會有五大元件 — 我把它們叫做五大金剛。

先看這張 MCP 官方提供的架構圖，你會看到五個核心的角色：MCP Host、MCP Client、MCP Server、Local Storage、Remote Service。那這張圖的背景是一台電腦 — 你的電腦，它是整個系統運作的平台。

元件 1：MCP Host（宿主應用）

MCP Host 像 Claude Desktop 或者是整合開發環境，希望透過 MCP 存取 AI 工具等等的程式。簡單來說，Host 其實就是你的程式 — 你這個發起指令、觸發操作的起點。

Host 代表的是開發者所使用的系統或服務平台，像使用者的電腦或者移動裝置，或者是去整合大語言模型的服務平台。MCP Host 通常都會跟 Client 兩者結合運作，一起完成服務的調用跟傳遞。

元件 2：MCP Client（連接管理器）

MCP Client 是維持伺服器一對一連線的用戶程式。它的角色就是發起連線。

官方圖裡面支援的功能列表有四大項：資源的管理、提示的模板、工具的整合、跟取樣的設定。常見的 Client 形式包括 Claude 的桌面應用程式（由 Anthropic 推出的，可以控制你的電腦幫你做事情），還有 Cursor AI 這種 AI Code Editor — 如果是開發人員這個不用我介紹，一定很常用。

要注意的是，Claude AI 的網頁版是沒有支援 MCP 的，只有桌面版才有。Cursor 也支援 STDIO 跟 SSE 的伺服器傳送事件。

元件 3：MCP Server（工具提供者）

MCP Server 是彈性而且抽象的元件，會透過標準的 MCP Protocol 來公開特定功能的輕量化程式。你可以想像是一個 Web API 的封裝服務器，可以對接遠端的服務。

MCP Client 跟 MCP Server 在官方的架構圖裡面是成對出現的，兩者一起協作，完成資料的存取跟溝通。

官方列出來支援的工具包括：檔案系統（Filesystem）、PostgreSQL、SQLite、Google Drive，還有開發工具像網頁瀏覽，以及 Slack 生產力工具、Google Map，還有 AI 專用的工具。簡單來說，MCP Server 就是支援的總管，負責跟外面的工具系統做整合。

元件 4：Local Data Storage（本地資料源）

電腦中的檔案、資料庫跟服務，MCP Server 可以安全的存取這些資源。如果你的資料是來自於 A 或 B 的 MCP Server，它就會跟 Local Data Storage — 就是電腦本身的檔案資料或者任何的內建服務 — 透過 MCP Server 的接口來存取。

比如說你的相簿的檔案資料、你的 Excel、你的相片，這些本地的資料可以藉由 MCP Server 的串接讓 LLM 的應用來取得。

元件 5：Remote Services（遠端服務）

不是本地的資源，是透過網際網路 API 連線的外部程式。比如說要串接到 Notion、Airtable 這種雲端的工具，我們就會利用 MCP Server C 這種用 Web API 的方式做串接。

MCP Server 就是當橋接，把結果再統一格式傳給 Client，讓 AI 的應用可以像用本地工具一樣去用遠端的工具 — Airtable、Notion 跟 Airbnb 等等。

五大金剛比較表

元件角色USB 類比說明
MCP Host宿主應用手機（發送端）發起指令的起點，如 Claude Desktop、n8n
MCP Client連接管理器USB 連接線維持一對一連線的用戶程式
MCP Server工具提供者USB 接收設備輕量化標準元件，對外提供功能
Local Storage本地資料源電腦硬碟檔案、資料庫、本機服務
Remote Service遠端服務雲端硬碟透過 API 連線的外部系統

五大角色球員：MCP 的五大核心功能

MCP 架構裡面支援互動和串接的五個核心功能，我把它們叫做五大角色球員：Prompt 提示、Resource 資源、Tool 工具、Root 根目錄、以及 Sampling 採樣。

角色 1：Prompt（提示模板）— 客服的標準話術卡

Prompt 就像是客服的標準話術卡。它是 MCP 裡面由伺服器提供的範本訊息或工作流程。

我怎麼理解呢？想像客服人員會有很多張預設的話術卡，比如說推銷你買保險、推銷你房貸、信貸等等。他會根據你當前的環境情境，選擇一張話術卡跟你說話。

Prompt 的核心特性：

  1. 範本化的訊息 — 定義好的 LLM 互動模板，像話術卡一樣去套用
  2. 使用者控制 — 你決定要用哪一種提示
  3. 標準化的流程 — 提供一致性的操作
  4. 參數客製化 — 讓你根據需求調整

伺服器這邊會有一個 Prompt Library（提示庫），管理跟提供各種預定義的模板 — 代碼審查、摘要生成、資料分析、語言翻譯等等。使用者會先從伺服器端拿到提示模板，再用這個模板跟 LLM 互動。

角色 2：Resource（資源）— 圖書館的參考書

資源是系統中的資料庫或背景資料。MCP 裡面有伺服器提供上下文的資料 — 例如檔案內容、日誌、資料庫紀錄、文件片段、專案的 Git 記錄等等。

我的類比是圖書館助理 — 資源就很像參考書，使用者要求的時候來提供，讓答案更準確跟完整。你去圖書館，會根據很多的書找出你要的書，把書借走，然後用這本書來解決你的問題。

Resource 的核心特性：

  1. 上下文資料 — 提供給模型參考的獨特知識和資源列表
  2. 唯一識別碼 — 每個資源都會有一個 URI，就像身分證一樣（例如 Doc123、DB345）
  3. 使用者控制 — 資源的納入都是由使用者或應用的邏輯來控制的，不是模型自己說了算

角色 3：Tool（工具）— 最常見也最強大

工具是 MCP Server 提供可執行的操作，LLM 模型可以呼叫工具和外部的系統做互動。我的類比是 Uber — Uber 駕駛會使用導航系統當作導航工具，來幫你載客達到目的地。或者手機語音助理會去 Call 地圖 APP 跟天氣 APP，給你一個出門旅行的建議，比如說去台北要不要帶雨傘。

Tool 在 n8n 的平台裡面是用最多的功能。它本質是讓 LLM 可以呼叫外部的工具或 API，擴展它的手跟腳。

Tool 的核心特性：

  1. 可用工具清單 — LLM 模型會先從伺服器知道有哪些技能可以用
  2. 智慧選擇 — LLM 分析使用者的請求跟上下文，決定要用哪一個工具
  3. 使用者審核 — 工具在執行的時候使用者要知道可不可以用，會有審核確認（但大部分我們都委派給 LLM，只有敏感資訊的時候才介入）
  4. 結果回傳 — 伺服器執行工具回傳結果，LLM 再做後續分析

角色 4：Root（根目錄）

Root 是定義 MCP Server 可以存取的根目錄路徑。這是一個安全性的設計，確保 Server 只能存取被授權的目錄，不會越權讀取其他敏感資料。

角色 5：Sampling（採樣）

Sampling 是讓 MCP Server 可以反向請求 LLM 模型進行推理的機制。一般的流程是 Client → Server，但 Sampling 允許 Server → Client 的反向溝通，讓 Server 可以利用 LLM 的能力來做更複雜的任務。

五大角色球員比較表

功能中文名控制方類比說明
Prompt提示使用者選擇客服話術卡伺服器提供的範本訊息
Resource資源應用程式控制圖書館參考書上下文資料供模型參考
Tool工具LLM 模型決定Uber 導航可執行操作，最常被使用
Root根目錄系統設定門禁卡定義可存取的路徑
Sampling採樣Server 發起回電機制Server 反向請求 LLM 推理

MCP 訊息格式與通訊流程

MCP 使用 JSON-RPC 2.0 作為訊息格式。這是一個成熟的 RPC 標準，很多系統都在用（像 Ethereum 的 API 也是 JSON-RPC）。

訊息類型

MCP 定義了三種訊息類型：

Request（請求） — Client 向 Server 發出請求：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": { "sql": "SELECT * FROM users LIMIT 10" }
  }
}

Response（回應） — Server 回覆請求結果：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      { "type": "text", "text": "[{\"id\": 1, \"name\": \"Alex\"}]" }
    ]
  }
}

Notification（通知） — 單向訊息，不需要回應：

{
  "jsonrpc": "2.0",
  "method": "notifications/progress",
  "params": { "progressToken": "abc123", "progress": 50, "total": 100 }
}

完整連接生命週期

一個 MCP 連接從建立到結束，經過以下步驟：

Step 1: Initialize（初始化） — Client 發送 initialize 請求，帶上自己的 capabilities。

Step 2: Server 回應 capabilities — Server 回覆自己支援的功能清單。

Step 3: Client 確認 — Client 發送 notifications/initialized 通知。

Step 4: 正常通訊 — 這時候才能開始呼叫 tools、讀取 resources。

Step 5: 關閉連接 — 任何一方都可以發送關閉請求。

我自己在開發 MCP Server 的時候，遇到最多問題的就是 Step 1-2 的 capability negotiation。如果版本不匹配或者 capability 設定有誤，連接會直接失敗。不用擔心，這個排查起來不難，看 log 就知道是哪邊的問題。

Transport 層深入解析

Transport 層是 MCP 架構中最底層的部分，但也是影響效能和部署方式最直接的一層。目前 MCP spec 定義了三種 Transport。

stdio（標準輸入輸出）

最簡單也最常用的 Transport。Client 直接啟動 Server 的 process，透過 stdin/stdout 通訊。

  • 優點：零延遲、無需網路、設定最簡單
  • 缺點：只能本地使用
  • 適合：本地開發、Claude Desktop

HTTP + SSE（Server-Sent Events）

Client 透過 HTTP POST 發送請求，Server 透過 SSE 回傳串流結果。Cursor AI 也支援 STDIO 跟 SSE 這種伺服器傳送事件。

  • 優點：支援網路部署、支援串流回應
  • 缺點：單向串流、需要管理 SSE 連接
  • 適合：雲端部署、需要遠端存取

Streamable HTTP（2025 新增）

使用標準 HTTP 請求搭配可選的 SSE 升級，更靈活、無狀態友善。

  • 優點：支援 CDN 快取、擴展性最好
  • 缺點：較新，支援度還在增加中
  • 適合：生產環境

Transport 選擇策略

場景建議 Transport原因
本地開發stdio最簡單、零設定
Claude Desktopstdio官方預設
n8n 自架版stdio 或 Streamable HTTP看 Server 位置
多用戶雲端Streamable HTTP擴展性最好
企業內網HTTP + SSE成熟穩定

我自己的建議是：先用 stdio 開始，有遠端需求再切換。 在本地環境下，stdio Transport 的穩定性遠優於 HTTP。我在用 HTTP+SSE 的時候偶爾會遇到連接中斷（特別是長時間 idle 的情況），但 stdio 從來沒出過問題。大多數情況下，stdio 就夠了，延遲基本上是毫秒級，完全感覺不到。

安全模型與權限控制

MCP 的安全設計我覺得是整個協議最被低估的部分。重點來了：

1. Server 隔離

每個 MCP Server 在獨立的 process 中運行，Server 之間完全隔離。一個 Server 被攻破不會影響其他 Server。

2. 工具確認機制

在呼叫有副作用的工具之前，Host 應該向使用者確認。但大部分的情況我們都委派給 LLM，只有某些特定的行為 — 比如說有敏感資訊的 — 你就應該要介入審核。

3. 能力限制

Server 只能做它宣告的事情。Client 在初始化階段就會知道 Server 的能力範圍。

4. Input Validation

所有工具參數都有 JSON Schema 定義。我自己實測的結果是，很多 MCP Server 在參數驗證上做得不夠嚴格，這是一個常見的安全隱患。

我要誠實說一個 MCP 目前的限制：在 stdio Transport 下，MCP Server 的安全性主要依賴 OS 層級的 process 隔離。對於高安全需求的場景，建議用 HTTP Transport + 容器化部署。

如何實作 MCP Server：五步驟指南

如果你想自己動手開發 MCP Server，以下是我整理的五步驟流程。

Step 1: 選擇 SDK

SDK套件名適合場景
TypeScript@modelcontextprotocol/sdkWeb 開發者、Node.js 環境
Pythonmcp資料科學、後端開發

Step 2: 定義工具

先想清楚你要暴露哪些能力。建議從最小可用開始，不要一次想做太多。

Step 3: 實作 Handler

# Python MCP Server 範例
from mcp.server import Server
from mcp.types import Tool, TextContent

server = Server("my-server")

@server.list_tools()
async def list_tools():
    return [
        Tool(
            name="hello",
            description="Say hello to someone",
            inputSchema={
                "type": "object",
                "properties": {
                    "name": {"type": "string", "description": "Person's name"}
                },
                "required": ["name"]
            }
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "hello":
        return [TextContent(type="text", text=f"Hello, {arguments['name']}!")]

Step 4: 設定 Transport

選擇 stdio 或 HTTP，設定對應的 Transport 層。

Step 5: 測試與部署

用 MCP Inspector 或 Claude Desktop 測試你的 Server。一步一步來，第一次沒做好是正常的。我自己第一個 MCP Server 也花了好幾個小時 debug。

重點整理

  1. MCP 是 AI 世界的 USB-C — 像秦始皇統一度量衡，像聯合國用英文做官方語言，讓所有 AI 用統一語言溝通
  2. 五大金剛 — Host（宿主應用）、Client（連接管理器）、Server（工具提供者）、Local Storage（本地資料）、Remote Service（遠端服務）
  3. 五大角色球員 — Prompt（話術卡）、Resource（參考書）、Tool（最常用、讓 LLM 擴展手腳）、Root（門禁卡）、Sampling（反向請求）
  4. MCP 適合做 POC — 比改 Restful API 快，先實現商業價值再逐項優化
  5. 不是萬能的 — Gmail、Google Sheet 這些常見工具用 API 更快，不要有工具迷思
  6. AI Agent 只做一件事 — 不要讓 Agent 又做 A 又做 B 又做 C，專注表現更好
  7. Tool Description 是關鍵 — 描述寫得好不好直接影響 AI 使用工具的成功率
  8. Transport 選 stdio 開始 — 本地穩定性最好，有遠端需求再切換

常見問題 FAQ

MCP 和 Function Calling 有什麼不同？

Function Calling 是 LLM 的能力，MCP 是應用層的協議標準，兩者互補而非競爭。 Function Calling 讓模型能描述它想呼叫的函數，但沒有定義工具如何被發現、如何通訊。MCP 補足了這個缺口，定義了從工具發現到呼叫到結果回傳的完整流程。打個比方，Function Calling 是「嘴巴」（模型能說出想做什麼），MCP 是「電話系統」（定義怎麼打電話、怎麼接電話）。

什麼是 MCP 的五大金剛和五大角色球員？

五大金剛是 MCP 架構的五大核心元件：Host、Client、Server、Local Storage、Remote Service。五大角色球員是五大核心功能：Prompt、Resource、Tool、Root、Sampling。 金剛是硬體層面的架構組成，角色球員是功能層面的互動方式。我在影片裡面用阿嬤聽得懂的 USB 類比來解釋金剛，用客服話術卡、圖書館參考書、Uber 導航來解釋角色球員，就是為了讓不同背景的人都能理解。

如何開發自己的 MCP Server？

五步驟：選 SDK、定義工具、寫 Handler、設定 Transport、測試部署。 我建議用 Python SDK 入門，因為上手最快。最小可用的 MCP Server 大概只需要 30-50 行程式碼。官方在 GitHub 上有很多範例可以直接 fork。如果你想看我實作的範例，可以加入 Skool 社群 下載完整的 starter template。

MCP 不是萬能的，什麼時候不該用 MCP？

常見工具（Gmail、Google Sheet）用 API 更快，不需要什麼都走 MCP。 我在影片裡面特別強調不要有工具的迷思。MCP 最適合的場景是 POC 快速驗證、多工具混用搭配、以及需要統一介面的情境。但如果你只是要做一個簡單的 Gmail 發信，直接用 n8n 內建的 Gmail 節點就好了，不需要繞一圈走 MCP。

MCP Host 和 Client 有什麼差別？

Host 是 AI 應用程式本身，Client 是 Host 內部負責管理單一 Server 連接的元件。 MCP Host 通常都會跟 Client 兩者結合運作，一起完成服務的調用跟傳遞。一個 Host 可以同時連接多個 Server，每個連接由一個獨立的 Client 實例管理。這個設計讓 Server 之間完全隔離。

Transport 層該怎麼選？

預設用 stdio，有遠端需求用 Streamable HTTP，舊系統用 HTTP+SSE。 我自己 90% 的 MCP 使用都是 stdio，延遲毫秒級，完全感覺不到。在本地環境下穩定性也遠優於 HTTP，我用 HTTP+SSE 偶爾會遇到連接中斷，但 stdio 從來沒出過問題。不要過度設計，大多數場景 stdio 就夠了。

下一步行動

🎓 想更有系統地學會這些技巧？ 到 AI 職場工作術（雲端方程式 Cloud F1 旗艦課程） 看看完整的實作路徑。

想更深入學習 MCP 和 AI Agent 的實作嗎？

  1. 入門推薦：MCP 完整指南 — 從零開始的完整學習路徑
  2. 實作教學：n8n AI Agent 概念 — AI Agent 在 n8n 的應用
  3. 進階整合：AI Agent 完整指南 — 理解 AI Agent 的核心概念
  4. 自動化基礎：n8n 零基礎教學 — 從零開始學 n8n

想學更多 n8n 自動化技巧？ 加入我們的 Skool 社群，和其他自動化愛好者一起學習交流！

相關資源

關於作者：Alex 是一位專注於 n8n 自動化和 AI 應用的技術教育者，透過 YouTube 頻道和 Skool 社群幫助超過數千位學員掌握自動化技能。

想把這篇學到的用進日常工作？

「AI 職場工作術」課程把這類實戰經驗整理成一步步的教學，帶你系統化練出跟 AI 協作的產能。

看 AI 職場工作術課程 →

本文作者：Alex Hsieh，SRE / DevOps 背景出身，現為企業 AI 導入顧問，也是「AI 相談室」課程講師。專注把 AI 自動化真正落地到企業日常流程，而不是停留在 Demo。

目錄
  1. 專業導讀
  2. 你將學到
  3. 什麼是 MCP 協議？
  4. MCP 實際 Demo：兩種應用情境
  5. 情境一：個人助理 — 查客戶 + 訂住宿
  6. 情境二：自動搜索時事 + 存到 Notion
  7. Alex 的實戰觀察
  8. 觀察 1：MCP 很適合用來做 POC
  9. 觀察 2：不要有工具的迷思
  10. 觀察 3：AI Agent 要專注在一項特定的任務
  11. 觀察 4：Tool Description 是成敗關鍵
  12. 觀察 5：與 n8n 的整合體驗很好
  13. 給阿嬤聽的 MCP 架構：USB 類比版
  14. 🔧 情境：手機照片傳到電腦
  15. 給開發者聽的 MCP 架構：五大金剛
  16. 元件 1：MCP Host（宿主應用）
  17. 元件 2：MCP Client（連接管理器）
  18. 元件 3：MCP Server（工具提供者）
  19. 元件 4：Local Data Storage（本地資料源）
  20. 元件 5：Remote Services（遠端服務）
  21. 五大金剛比較表
  22. 五大角色球員：MCP 的五大核心功能
  23. 角色 1：Prompt（提示模板）— 客服的標準話術卡
  24. 角色 2：Resource（資源）— 圖書館的參考書
  25. 角色 3：Tool（工具）— 最常見也最強大
  26. 角色 4：Root（根目錄）
  27. 角色 5：Sampling（採樣）
  28. 五大角色球員比較表
  29. MCP 訊息格式與通訊流程
  30. 訊息類型
  31. 完整連接生命週期
  32. Transport 層深入解析
  33. stdio（標準輸入輸出）
  34. HTTP + SSE（Server-Sent Events）
  35. Streamable HTTP（2025 新增）
  36. Transport 選擇策略
  37. 安全模型與權限控制
  38. 1. Server 隔離
  39. 2. 工具確認機制
  40. 3. 能力限制
  41. 4. Input Validation
  42. 如何實作 MCP Server：五步驟指南
  43. Step 1: 選擇 SDK
  44. Step 2: 定義工具
  45. Step 3: 實作 Handler
  46. Step 4: 設定 Transport
  47. Step 5: 測試與部署
  48. 重點整理
  49. 常見問題 FAQ
  50. MCP 和 Function Calling 有什麼不同？
  51. 什麼是 MCP 的五大金剛和五大角色球員？
  52. 如何開發自己的 MCP Server？
  53. MCP 不是萬能的，什麼時候不該用 MCP？
  54. MCP Host 和 Client 有什麼差別？
  55. Transport 層該怎麼選？
  56. 下一步行動
  57. 相關資源

相關文章