Day 22: 一文認識 Model Context Protocol (MCP)

2025 iThome 鐵人賽

DAY 22

生成式 AI

當 .NET 遇見 AI Agents：用 Semantic Kernel × MCP 打造智慧協作應用系列第 22 篇

17th鐵人賽 ai llm ai agent

Ian

2025-10-06 23:16:24

14 瀏覽

分享至

Model Context Protocol (MCP) 是由 Anthropic 於 2024 年底發起的一個開放標準，目的是讓 LLM AI 應用程式（如 Claude、ChatGPT或是自已撰寫開發的應用等）能夠有一個安全、標準化連接到各種資料源和工具的協議。由其是在 AI Agent 應用中，MCP 可以讓 Agent 存取和操作外部資料，提升應用的靈活性和功能性。

在 MCP 出現之前，當我們想讓 AI 連接到不同的服務（如資料庫、API、文件系統等），都需要針對每個服務開發專屬的function，接著讓 AI Agent 透過 function calling 方式來進行互動，但是這樣的方式會有幾個問題：
開發成本高：每個AI平台服務可能有不同對接 Function Calling 機制的方式，會造成開發和維護專屬的 function 的情況，增加了開發和維護的工作量。
缺乏標準：不同平台或開發者用不同方式實作，造成生態系統碎片化，降低了不同 AI 應用之間的互操作性。

MCP 的解決方案

MCP 提供了一個統一的協議層，就像 HTTP 之於網路通訊一樣，讓 AI 應用與外部資源的連接變得標準化。 MCP 本身定義了一套標準的 API 和資料格式，讓 AI 應用可以透過這些標準化的接口來存取和操作外部資料源，而不需要針對每個服務開發專屬的 function。這樣一來，開發者只需要實作一次 MCP 接口，就可以讓 AI 應用存取多種不同的服務，大大降低了開發成本。如果說 Web API 是讓應用程式能夠透過網路互相溝通的標準，那麼 MCP 就是讓 AI 應用能夠透過標準化的方式存取和操作外部資料的協議。

透過 MCP：

AI 應用只需實作一次 MCP 協議
資源提供者（如 Google Drive、Slack、資料庫等）也只需實作一次 MCP Server
任何支援 MCP 的 AI 應用都能使用任何 MCP Server，無需額外開發

MCP 與 Function Calling 的關係

很多開發者第一次聽到 MCP 時，會有個疑問：「這跟 Function Calling 有什麼不同？」當時我一開始接觸也是這樣想的。但其實，MCP 和 Function Calling 之間並不是對立的關係，而是可以相輔相成的。

Function Calling（函數調用）是 LLM 的一項能力，讓模型能夠：

理解何時需要呼叫外部函數來完成任務
生成適當的函數調用請求(包含函數名稱和參數）
接收函數執行結果並整合到回應中
例如，當你問「台北現在天氣如何？」時，LLM 會：

{
  "function": "get_weather",
  "arguments": {
    "location": "台北",
    "unit": "celsius"
  }
}

MCP 的定位

MCP 並不是取代 Function Calling，而是規範了「如何定義、發現、執行這些函數」的標準協議，讓不同的 AI 應用能夠更容易互相操作和整合。所以並不是有了 MCP 就不需要 Function Calling，反而是 MCP 讓 Function Calling 的實作和使用有一種標準化方式可以跟 AI 應用結合起來。所以只要各平台或開發者願意實作 MCP 協議，AI 應用就能透過一致性的方式整合 Function Calling 來呼叫 MCP 定義的函數，進而存取和操作外部資源。

一句話：MCP 底層仍然使用 Function Calling 機制，但加上了標準化的協議層，讓整個生態系統更有彈性和互操作性。

MCP 的核心角色

MCP 生態系統中有三個核心角色：MCP Host、MCP Client 和 MCP Server，但由於 Client 和 Host 通常是綁在一起的，所以通常聽到的都是 MCP Client與Server。這三個角色分別負責不同的功能：

MCP Client：通常是 AI 應用程式（如 ChatGPT、Claude 或自訂的 AI 應用），在 Host 中實作的協議客戶端，負責與 Server 通訊，它們透過 MCP 協議發起對 Server 的連接請求，呼叫 MCP Server 上定義的函數，接收並處理 Server 的回應。
MCP Server：暴露特定能力（工具、資源、提示詞）的服務端程式，負責處理來自 MCP Client 的請求，執行相對應的 function，接者將結果回傳給 Client。MCP Server 可以連接到各種外部資源，如資料庫、API、文件系統等，讓 AI 應用能夠透過標準化的方式存取這些資源。
MCP Host：MCP Host 是 MCP Client 的一個實體運行宿主，整合了 MCP 協議的 AI 應用程式或平台。將 LLM 的需求轉換為 MCP 協議請求，Host 可以同時運行多個 Client，連接到不同的 Server，管理與多個 MCP Server 的連接，協調多個 Server 之間的互動。Host 通常包含了 MCP Client 的實作，負責發起連接並管理會話。

舉例來說，假設你在 Claude Desktop 中問：「我的 GitHub 專案 'my-app' 有哪些 open issues？」

Claude Desktop（MCP Host）會將這個問題轉換成 MCP 協議的請求，並透過 MCP Client 發送給 GitHub MCP Server。
GitHub MCP Server 收到請求後，會呼叫 GitHub API 來取得 'my-app' 專案的 open issues，然後將結果回傳給 Claude Desktop。
Claude Desktop 最後將這些 open issues 整合到回應中，並呈現給使用者。

MCP 的通訊方式

MCP 目前主要有兩種通訊方式：

stdio Transport（標準輸入輸出傳輸）：透過標準輸入輸出進行通訊，適用於本地程序間通訊，在本機啟動 Server 程序，直接通過 stdin/stdout 交換訊息，簡單直接不需要網路配置，例如讀取本機端的檔案工具。
Streamable HTTP（HTTP 傳輸）：透過 HTTP 協議進行通訊，適用於遠端連接、雲端服務、需要跨網路的場景，Server 提供 HTTP 端點，Client 透過 HTTP 連接，早期一開始是SSE Transport（Server-Sent Events 傳輸），現在已建議採用 Streamable HTTP 取代之。

無論使用哪種傳輸方式，MCP 的訊息格式都遵循 JSON-RPC 2.0 規範：

請求格式：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "台北"
    }
  }
}

回應格式：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "台北現在氣溫 25°C，晴天"
      }
    ]
  }
}

MCP 的生態系

MCP 是一個開放標準，任何人都可以實作 MCP Client 或 MCP Server，這促進了生態系的發展。目前已有一些知名的 AI 平台和工具開始支援 MCP，例如：

Anthropic 的 Claude：Claude 是 MCP 的主要推動者，Claude 3 和 Claude 4 都支援 MCP 協議，讓開發者能夠更容易地將 Claude 整合到各種應用中。
OpenAI 的 GPT-4.5 和 GPT-4.1：OpenAI 也開始支援 MCP，讓開發者能夠透過標準化的方式存取外部資源。
Context7 的 MCP Server：Context7 提供一個雲端的 MCP Server，讓開發者能夠快速連接到各種工具和資源。

許多 Server 快速成長中，然整個 MCP 生態系仍在發展中，許多設計模式變化還在摸索中，MCP 協議可能也還會有破壞性更新。

結語

Model Context Protocol (MCP) 應該是除了LLM 模型發展之外，一個 AI 應用整合領域的重要進展。透過標準化的協議，讓 AI 應用與外部工具和資料源的連接變得更加簡單、安全和可維護，甚至如果把 MCP Server 設計成外部一個 Agent，這時候也就可以讓 Agent 之間互相呼叫，形成一個更大的 Agent 生態系。