為什麼需要 MCP？

在 MCP 出現之前，每個 AI 應用要連接外部工具，都需要自行實作整合邏輯。想讓 AI 讀取 GitHub Issues？你要寫一套 GitHub API 的封裝。想查詢資料庫？你要寫另一套資料庫連線邏輯。這就造成了所謂的「M×N 問題」——如果有 M 個 AI 應用和 N 個工具，就需要 M×N 個客製化整合。

MCP 透過標準化的協議層，將這個 M×N 問題簡化為 M+N。每個 AI 應用只需要實作一次 MCP Client，每個工具只需要包裝成一次 MCP Server，就能互相連接。這就像 USB 的概念——不管是鍵盤、滑鼠還是硬碟，只要支援 USB 介面，就能接上任何電腦。

MCP 的核心架構

MCP 採用經典的 Client-Server 架構，但加入了 Host 的概念來管理整個生態系。理解這三個角色的關係，是掌握 MCP 的第一步。

三大角色：Host、Client、Server

Host（宿主）是使用者直接互動的 AI 應用程式，例如 Claude Code、Claude Desktop App 或任何整合了 LLM 的 IDE。Host 負責管理 LLM 實例、建立 MCP Client、控制安全與權限，並協調多個 MCP 連線。

Client（客戶端）是由 Host 建立的協議端點，每個 Client 與一個 Server 維持一對一的連線。Client 負責處理訊息的路由、能力的協商，以及訂閱管理。在 Claude Code 中，每當你新增一個 MCP Server，系統就會自動建立一個對應的 Client。

Server（伺服器）是實際提供工具與資料的程式。Server 可以是一個 Node.js 腳本、Python 程式、或遠端 HTTP 服務。每個 Server 透過 MCP 協議暴露自己的能力（tools、resources、prompts），讓 AI 模型可以呼叫使用。

協議層架構

三大核心原語：Tools、Resources、Prompts

MCP Server 透過三種核心原語向 AI 暴露自己的能力。理解它們的差異，有助於你判斷什麼時候該用哪一種，以及如何設計自己的 MCP Server。

Tools（工具）：讓 AI 執行動作

Tools 是 MCP 中最常用的原語，代表 AI 可以呼叫的可執行函式。每個 Tool 都有名稱、描述和輸入參數的 JSON Schema 定義。當 AI 判斷需要使用某個 Tool 時，會自動傳入適當的參數並等待結果。

舉例來說，一個 GitHub MCP Server 可能暴露這些 Tools：

// Tool 定義範例
{
  "name": "create_issue",
  "description": "在 GitHub 儲存庫中建立一個新的 Issue",
  "inputSchema": {
    "type": "object",
    "properties": {
      "repo": {
        "type": "string",
        "description": "儲存庫名稱，格式為 owner/repo"
      },
      "title": {
        "type": "string",
        "description": "Issue 標題"
      },
      "body": {
        "type": "string",
        "description": "Issue 內容（支援 Markdown）"
      }
    },
    "required": ["repo", "title"]
  }
}

如果把 MCP 想像成一家餐廳，Tools 就是菜單上的菜——你可以點什麼、需要提供什麼資訊（幾分熟、要不要辣），都清楚定義好了。

Resources（資源）：讓 AI 讀取資料

Resources 代表 MCP Server 可以提供的資料來源。與 Tools 不同，Resources 是唯讀的——AI 可以讀取資料，但不會觸發任何副作用。每個 Resource 都有一個 URI 來識別，內容可以是文字或二進位資料。

// Resource 範例
{
  "uri": "file:///project/src/config.json",
  "name": "專案設定檔",
  "description": "目前專案的 JSON 設定內容",
  "mimeType": "application/json"
}

繼續用餐廳的比喻，Resources 就是餐廳提供的菜單、酒單、今日特餐公告板——你可以看、可以參考，但不會改變任何東西。

Prompts（提示模板）：預設的互動模式

Prompts 是預先定義好的互動模板，讓使用者可以快速啟動常見的工作流程。Prompts 可以包含固定的指令文字和動態的參數，由使用者觸發（而非 AI 自動決定）。

// Prompt 範例
{
  "name": "code_review",
  "description": "對指定的 Pull Request 進行程式碼審查",
  "arguments": [
    {
      "name": "pr_number",
      "description": "Pull Request 編號",
      "required": true
    },
    {
      "name": "focus_area",
      "description": "審查重點（如安全性、效能、可讀性）",
      "required": false
    }
  ]
}

Prompts 就像餐廳的套餐——廚師已經幫你搭配好了主餐、配菜和甜點，你只需要選擇要幾人份就好。

傳輸機制：stdio 與 Streamable HTTP

MCP 定義了兩種主要的傳輸機制，分別適用於不同的使用場景。選擇正確的傳輸方式，直接影響 MCP Server 的部署方式和效能特性。

stdio：本地執行的首選

stdio（Standard Input/Output）傳輸是最簡單的方式。Client 啟動 Server 作為子程序，透過標準輸入（stdin）和標準輸出（stdout）交換 JSON-RPC 訊息。每條訊息以換行符號分隔。

# 在 Claude Code 中新增一個 stdio 類型的 MCP Server
claude mcp add --transport stdio my-db-server -- npx -y @example/db-server

# 帶環境變數的版本
claude mcp add --transport stdio --env DB_URL=postgresql://localhost/mydb \
  my-db-server -- npx -y @example/db-server

stdio 的優點是延遲極低（不需要網路傳輸）、設定簡單，且天然支援安全隔離（因為只在本機執行）。缺點是無法跨機器使用，Server 的生命週期綁定在 Host 程式上。

Streamable HTTP：遠端服務的標準

Streamable HTTP 是 MCP 規格在 2025 年 3 月更新後推薦的遠端傳輸方式，取代了先前的 SSE（Server-Sent Events）傳輸。它透過標準的 HTTP 請求進行通訊，並可選擇性地使用 SSE 來串流回應。

# 在 Claude Code 中新增一個 HTTP 類型的 MCP Server
claude mcp add --transport http notion https://mcp.notion.com/mcp

# 帶認證的版本
claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer your-token"

Streamable HTTP 的優點是可以跨網路使用、支援多用戶共享同一個 Server、容易部署在雲端環境。缺點是需要處理網路延遲和認證機制。

連線生命週期

MCP 的連線建立遵循嚴格的初始化流程，確保 Client 和 Server 在開始通訊之前就協商好彼此的能力。

初始化流程

當 Claude Code 啟動或你新增一個 MCP Server 時，會經歷以下步驟：

在初始化階段，Client 和 Server 會交換各自支援的協議版本和能力（Capabilities）。例如，Server 可能宣告它支援 tools 和 resources，但不支援 prompts。Client 則可能宣告它支援 sampling（讓 Server 請求 AI 模型進行推理）和 roots（提供檔案系統存取點）。

訊息交換模式

初始化完成後，MCP 支援三種訊息交換模式：

Request-Response（請求-回應）：Client 發送請求，Server 回傳結果。例如呼叫一個 Tool 或讀取一個 Resource。每個 Request 都帶有唯一的 ID，用來配對對應的 Response。

Notification（通知）：單向訊息，不需要回應。例如 Server 通知 Client 它的 Tool 列表已更新（list_changed），或 Client 通知 Server 某個 Root 已變更。

Progress（進度）：長時間執行的操作可以回報進度，讓使用者知道目前的處理狀態。這對需要幾秒鐘以上才能完成的 Tool 來說特別實用。

在 Claude Code 中設定 MCP Server

理解了 MCP 的架構概念後，讓我們來看看如何在 Claude Code 中實際設定和使用 MCP Server。Claude Code 提供了簡潔的 CLI 指令來管理 MCP 連線。

新增 MCP Server

Claude Code 支援三種方式新增 MCP Server：

# 方式一：新增遠端 HTTP Server（推薦用於雲端服務）
claude mcp add --transport http notion https://mcp.notion.com/mcp

# 方式二：新增本地 stdio Server
claude mcp add --transport stdio my-server -- npx -y @example/mcp-server

# 方式三：新增 SSE Server（已棄用，建議改用 HTTP）
claude mcp add --transport sse legacy-api https://api.example.com/sse

注意指令的語法規則：所有選項（--transport、--env、--scope、--header）必須放在 Server 名稱之前，--（雙破折號）用來分隔 Server 名稱和要傳給 Server 的命令及參數。

三種設定範圍（Scope）

MCP Server 的設定可以儲存在不同的範圍，決定了它的可見性和共享方式：

如果你的團隊需要共用相同的 MCP Server，使用 project scope 是最佳選擇。設定會儲存在 .mcp.json 檔案中，團隊成員只要 pull 最新的程式碼就能自動取得 MCP 設定。

管理與除錯

# 列出所有已設定的 MCP Server
claude mcp list

# 查看特定 Server 的設定細節
claude mcp get github

# 移除一個 MCP Server
claude mcp remove github

# 在 Claude Code 互動模式中檢查 Server 狀態
/mcp

在 Claude Code 的互動模式中輸入 /mcp，可以看到所有 MCP Server 的連線狀態、可用的 Tools 數量，以及是否有錯誤發生。如果某個 Server 顯示為斷線狀態，可以嘗試重新啟動 Claude Code 或檢查 Server 的執行環境。

Tool Search：智慧型工具載入

當你連接了大量 MCP Server 後，所有 Tool 的定義加起來可能佔用數萬個 Token 的 Context。Claude Code 內建的 Tool Search 功能透過智慧索引和動態載入，只在需要時才載入相關的 Tool 定義，將 Context 消耗從約 72,000 Token 降低到約 8,700 Token——減少了約 85%。

Tool Search 是自動運作的，你不需要做任何設定。當你向 Claude 提出請求時，它會根據語意搜尋最相關的 Tools 來使用，就像搜尋引擎一樣。這意味著即使你連接了幾十個 MCP Server、數百個 Tools，Claude 的效能和成本也不會受到顯著影響。

MCP 的安全性考量

使用 MCP Server 時，安全性是必須重視的議題。以下是幾個關鍵的安全原則：

審慎選擇 Server 來源：只安裝你信任的 MCP Server。第三方 Server 可能含有未經驗證的程式碼，尤其是那些需要存取敏感資料的 Server。官方推薦的 Server 列表是最安全的起點。

注意 Prompt Injection 風險：如果 MCP Server 會抓取不受信任的外部內容（例如網頁、電子郵件），這些內容可能包含惡意的指令注入。Claude Code 有內建的安全機制來防範，但你仍應該對 Server 回傳的內容保持警覺。

妥善管理認證資訊：使用 --env 參數傳遞 API Key 和認證 Token，避免將敏感資訊直接寫在 .mcp.json 中（因為這個檔案可能會被加入版本控制）。對於需要 OAuth 2.0 認證的遠端 Server，可以在 Claude Code 中使用 /mcp 指令來完成認證流程。

善用 Project Scope 的安全機制：當 Claude Code 偵測到 .mcp.json 中的 Project Scope Server 時，會提示你確認是否信任這些 Server，這是一道額外的安全防線。如果需要重設這些選擇，可以使用 claude mcp reset-project-choices 指令。

MCP 生態系的現況與發展

MCP 自 2024 年 11 月發布以來，已經從 Anthropic 的內部實驗快速發展成為業界標準。2025 年 3 月，OpenAI 正式採用 MCP，將其整合到 ChatGPT Desktop App 中。同年 12 月，Anthropic 將 MCP 捐贈給 Linux Foundation 旗下的 Agentic AI Foundation（AAIF），由 Anthropic、Block 和 OpenAI 共同主導，Google 和 Microsoft 也加入支持。

目前，MCP 生態系中已有數百個開源 Server，涵蓋資料庫（PostgreSQL、MySQL）、專案管理（Jira、Asana、Linear）、溝通工具（Slack、Discord）、開發工具（GitHub、GitLab）、設計工具（Figma）等各類服務。Anthropic 也維護了一個官方 MCP Server 清單，方便開發者查詢和使用。

2025 年 11 月的規格更新帶來了幾個重要的新功能：非同步操作支援、無狀態設計、Server 身分識別機制，以及官方的 MCP Server Registry。這些更新讓 MCP 更適合在生產環境中使用，也為未來的擴展奠定了基礎。

實際應用場景

理解了 MCP 的概念，讓我們看幾個具體的應用場景，感受 MCP 如何改變日常開發流程：

場景一：從 Issue 到 PR 的完整工作流——連接 Jira MCP Server 和 GitHub MCP Server 後，你可以告訴 Claude：「讀取 JIRA-1234 的需求，在 main 分支上實作，完成後建立 PR 並 tag reviewer。」Claude 會自動讀取 Issue 內容、分析需求、撰寫程式碼、建立 Pull Request，一氣呵成。

場景二：資料庫查詢與分析——連接 PostgreSQL MCP Server 後，你可以用自然語言查詢資料：「找出上個月註冊但從未登入的使用者，匯出他們的 email 清單。」Claude 會自動撰寫 SQL、執行查詢、整理結果。

場景三：跨工具協作——同時連接 Slack、Figma 和 GitHub 後，你可以說：「根據 Figma 中最新的設計稿，更新首頁元件，完成後在 Slack 的 #frontend 頻道通知團隊。」Claude 會讀取設計稿、修改程式碼、發送通知，串連多個工具完成複雜的跨平台工作流。

下一步：動手連接你的第一個 MCP Server

本文介紹了 MCP 的核心概念、架構設計、三大原語、傳輸機制和安全考量。MCP 的出現，讓 AI 工具從「聰明的聊天機器人」進化為「能夠操作真實世界的數位助手」。

在下一篇文章中，我們將進入實戰環節——帶你一步步連接常見的 MCP Server，包括 GitHub、Slack、資料庫等，讓 Claude Code 真正成為你的全方位開發夥伴。如果你已經等不及了，可以先試試在 Claude Code 中執行以下指令：

# 連接 GitHub MCP Server（需要 GitHub 帳號）
claude mcp add --transport http github https://api.githubcopilot.com/mcp/

# 檢查連線狀態
/mcp

連上之後，試著問 Claude：「列出我最近的 GitHub 通知」——你會發現，AI 與工具之間的溝通，從此變得如此自然。

ㄚ槌

blog.che-ya.com