你有沒有想過，為什麼每次要讓 AI 助手讀取一個 API、連上一個資料庫，都得從頭寫客製化的整合程式碼？每個 AI 工具都有自己的外掛系統，開發者被迫為不同平台各寫一套連接邏輯——直到 MCP 出現，這個問題終於有了解法。

什麼是 MCP？

MCP 全名 Model Context Protocol（模型上下文協定），是由 Anthropic 在 2024 年底提出、2025 年迅速被業界採納的開放標準。它的核心目標非常簡單：

用一套統一的協定，讓任何 AI 模型都能連接任何外部工具或資料來源。

你可以把 MCP 想像成 AI 世界的「USB-C」。在手機充電領域，各家廠商曾經各有自己的充電接口，USB-C 出現後，一條線充所有設備。MCP 之於 AI 代理，正是同樣的角色——一個標準化的連接介面。

為什麼需要 MCP？原本的世界出了什麼問題？

在 MCP 出現之前，AI 工具的生態系面臨幾個嚴重痛點：

1. 客製化整合的重複勞動

每個 AI 平台（OpenAI、Anthropic、Google、本地開源模型）都有自己的「函式呼叫」（Function Calling）格式。開發者想讓 AI 讀取 Slack 訊息，得為每個平台各寫一套對接程式碼。五個平台就是五倍的開發工作量。

2. 安全性參差不齊

沒有統一標準，各家的權限控制、認證機制各做各的。有些平台直接把 API Key 寫在 Prompt 裡，有些甚至沒有最基本的存取控制。這對企業導入 AI 來說是硬傷。

3. 生態系碎片化

你開發了一個超好用的 AI 工具外掛，但它只能在 OpenAI 生態裡用。想讓 Claude 或 Gemini 使用？重新開發一次。結果就是每個平台的工具庫都是封閉的，開發者的投入無法跨平台累積。

MCP 的出現，就是要一次解決這三個問題。

MCP 的核心架構

MCP 採用 客戶端—伺服器架構（Client-Server Architecture），但角色定義和我們熟悉的 Web 架構不太一樣：

三個關鍵角色

角色 說明 舉例
MCP Host 發起連線的 AI 應用程式 Claude Desktop、Cursor、VS Code Copilot
MCP Client Host 內建的協定客戶端，負責與 Server 通訊 內嵌在 Host 中的 MCP 協定處理器
MCP Server 提供工具與資料的外部服務 GitHub MCP Server、Slack MCP Server、自建 API Server

一個 Host 可以同時連接多個 MCP Server，每個 Server 提供不同領域的能力。這就像你的筆電可以同時接上 USB-C 的滑鼠、鍵盤和螢幕一樣。

通訊方式

MCP 支援兩種傳輸方式：

  • stdio：適合本地端 Server，Host 直接啟動 Server 程序，透過標準輸入輸出溝通
  • SSE over HTTP：適合遠端 Server，透過 HTTP 長連線雙向傳訊

兩種方式都用 JSON-RPC 2.0 作為訊息格式，這意味著訊息結構是標準化的、可預測的。

MCP Server 提供的三種能力

每個 MCP Server 可以選擇性地提供以下能力：

🛠 Tools（工具）

讓 AI 能夠執行動作。例如：

  • 查詢 GitHub Issue 清單
  • 在資料庫中新增一筆記錄
  • 發送一封電子郵件
  • 執行一段程式碼

📄 Resources（資源）

讓 AI 能夠讀取資料。例如：

  • 讀取某個 Git Repository 的 README
  • 查看某個 API 的 OpenAPI 規格
  • 取得某個資料夾的檔案清單

Resources 是被動的——AI 可以請求讀取，但不會主動推播。

💬 Prompts（提示詞模板）

提供預先定義好的提示詞模板，讓使用者可以快速啟動特定任務。例如：

  • 「幫我 Code Review」的提示詞組合
  • 「分析這份財報」的結構化指令

一個實際的運作流程

假設你在 Claude Desktop 中裝了 GitHub MCP Server，流程是這樣的：

  1. 你問 Claude：「幫我看一下 my-repo 有哪些 open issue」
  2. Claude 判斷需要呼叫 MCP Tool → list_issues
  3. MCP Client 將請求打包成 JSON-RPC 訊息，傳給 GitHub MCP Server
  4. MCP Server 呼叫 GitHub API，取得 Issue 清單
  5. Server 將結果回傳給 Client
  6. Claude 整理結果，用人類可讀的方式呈現給你

整個過程中，你不需要寫任何程式碼，也不需要把 GitHub Token 直接貼在對話裡。MCP Server 會透過環境變數安全地管理認證資訊。

MCP vs. 傳統 Function Calling：差在哪？

比較項目 傳統 Function Calling MCP
標準化 各家格式不同 統一協定，跨平台通用
連接方式 硬編碼在應用中 動態發現，隨插即用
安全性 依賴各平台實作 內建權限控制與認證隔離
生態系 平台封閉 開放標準，社群共建
開發成本 N 個平台 = N 套程式碼 寫一次，到處可用

簡單來說：Function Calling 是「每家餐廳有自己的點餐系統」，MCP 是「統一的點餐 API」。

如何開始使用 MCP？

使用者端

如果你是 AI 工具的使用者，只需要在 Host 應用（如 Claude Desktop）的設定檔中加入 MCP Server 的連線資訊：

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxx"
      }
    }
  }
}

重啟應用後，AI 就自動擁有了操作 GitHub 的能力。

開發者端

如果你想自己開發 MCP Server，官方提供了 TypeScript 和 Python 的 SDK：

# TypeScript
npm install @modelcontextprotocol/sdk

# Python
pip install mcp

一個最簡單的 MCP Server 只需要定義工具名稱、描述、參數 schema 和處理函式，不到 50 行程式碼就能上線。

MCP 在 2026 的現況與未來

截至 2026 年，MCP 已經獲得廣泛的產業支持：

  • Anthropic Claude：原生支援 MCP
  • OpenAI ChatGPT：已整合 MCP 協定
  • Google Gemini：宣布支援 MCP
  • 開源社群：數百個 MCP Server 已上架，涵蓋 GitHub、Slack、Notion、Google Drive、PostgreSQL 等常見服務
  • 企業端：越來越多企業以 MCP 作為內部 AI 工具的標準化整合方案

未來的方向包括：遠端 Server 的 OAuth 認證標準化、Server 發現機制（類似 DNS 的 MCP Registry），以及串流式回應支援——這些都讓 MCP 從「能用」走向「好用」。

結語：為什麼你該關注 MCP？

如果你是開發者，MCP 意味著寫一次整合，所有 AI 平台通用——你的投入不再被單一平台綁架。

如果你是企業決策者，MCP 意味著標準化的安全管控——不需要每個 AI 工具各搞一套認證機制。

如果你是一般使用者，MCP 意味著更強大、更安全的 AI 體驗——你的 AI 助手可以連接更多服務，而且你的資料不會外洩。

AI 代理的時代才剛開始，而 MCP 就是那條讓 AI 真正「走出去」的通用高速公路。現在開始理解它，就是為未來做好準備。

想了解更多？ 可以參考 MCP 官方規格文件，或直接試裝一個 MCP Server 體驗看看——你會驚訝於它有多簡單。