Remote MCP Server

3 秒看懂

Remote MCP Server = 把 MCP 工具伺服器從本地程序搬上雲端端，通過 HTTP 暴露標準化的 AI 工具/資料介面，讓任何大型模型客戶端都能遠端發現和呼叫外部能力。

一句話類比：如果 MCP 是”AI 時代的 USB 協議”，那 Remote MCP Server 就是把 USB 裝置變成了”雲端服務”——你不再需要把裝置插在本機上，而是通過網路即插即用。

3 分鐘產業解釋

問題背景

MCP（Model Context Protocol）由 Anthropic 於 2024 年開源釋出，定義了一套標準化協議，讓大型模型（LLM Host）以統一方式連線外部工具和資料來源。協議原始設計採用 本地 stdio 傳輸——MCP Server 作為宿主機上的子程序執行，通過標準輸入輸出通訊。

這帶來一個根本性的侷限：工具只能跑在使用者本機。對於 SaaS 服務、企業級部署、多使用者共享場景，本地模式完全不夠用。

Remote MCP 做了什麼

Remote MCP Server 將 MCP Server 部署為 可通過網路訪問的 Web 服務，核心變化包括：

維度	本地 MCP	Remote MCP
傳輸層	stdio（程序間）	HTTP + 流式響應（SSE → Streamable HTTP）
部署位置	使用者本機	雲端端/遠端伺服器
認證	無需（本地信任）	OAuth 2.0 等標準鑑權
多使用者	單使用者	多租戶共享
發現機制	配置檔案手動指定	可通過 URL 動態發現

產業意義

Remote MCP 本質上是為 AI Agent 生態建立了一套 “工具即服務”（Tool-as-a-Service） 的基礎設施層。誰控制了 Remote MCP Server 的分發和發現，誰就有可能成為 AI 時代的”應用商店”。

15 分鐘專家深入

1. 從本地到遠端的架構演進

本地模式（stdio）的侷限：

┌──────────────┐     stdin/stdout     ┌──────────────┐
│  MCP Host    │ ◄──────────────────► │  MCP Server  │
│  (e.g. Claude│                      │  (本地程序)    │
│   Desktop)   │                      │              │
└──────────────┘                      └──────────────┘
       │
       ▼
  只能訪問本機工具

本地模式下，MCP Server 是 Host 啟動的子程序。Host 通過管理子程序的生命週期來保證連線，但這也意味著：

工具提供方無法獨立部署和運營
無法實現跨使用者共享
無法施加標準的網路級鑑權

遠端模式（HTTP）的架構：

┌──────────────┐    HTTP/SSE/         ┌──────────────────────┐
│  MCP Host    │    Streamable HTTP   │  Remote MCP Server   │
│  (Claude,    │ ◄──────────────────► │  (雲端端部署)           │
│   Cursor,    │                      │                      │
│   自研Agent) │    OAuth 2.0 鑑權     │  工具 API + 資料來源    │
└──────────────┘                      └──────────────────────┘
       │                                        │
       ▼                                        ▼
  多個Host例項可連線            可服務多個租戶/使用者

2. 傳輸層技術細節

MCP 協議的遠端傳輸層經歷了演進（以下基於 MCP 規範的公開討論，具體版本號請參閱 [官方規範倉庫]）：

SSE（Server-Sent Events）：早期遠端傳輸方案，客戶端通過 HTTP POST 傳送請求，服務端通過 SSE 流返回響應。實現相對簡單但存在連線管理的侷限。
Streamable HTTP：後續引入的更靈活方案。服務端可根據場景選擇返回單次 JSON 響應或升級為 SSE 流，客戶端也可以選擇是否建立持久 SSE 連線接收服務端推送（如通知）。無狀態與有狀態模式可根據實現需求靈活切換。

協議層仍基於 JSON-RPC 2.0 訊息格式，定義了標準化的請求/響應/通知結構。

3. 認證與安全

Remote MCP 的安全模型是其與本地模式的最大差異之一。規範引入了 OAuth 2.0 授權架構作為標準鑑權機制，核心流程大致為：

MCP Client 檢測到 Remote Server 需要認證
通過 OAuth 發現機制獲取授權端點
引導使用者完成授權（授權碼流程等）
獲取 access token，後續請求攜帶 token

這使得第三方 SaaS 提供商可以在不暴露底層憑證的前提下，安全地向 AI 客戶端暴露工具能力。企業級場景下，還可結合 mTLS、API Key 等補充機制 [具體實現因廠商而異]。

4. Remote MCP Server 的核心原語（Primitives）

遠端模式下，MCP Server 仍暴露三類標準化原語：

Tools：可被模型呼叫的操作函式（如”搜尋資料庫""傳送郵件""執行程式碼”），是 Agent 行為能力的核心載體。
Resources：可被模型讀取的資料內容（如檔案內容、資料庫記錄、API 響應），相當於只讀資料介面。
Prompts：預定義的提示模板，供客戶端選用以最佳化互動。

對於 Remote Server，Tools 是最核心的價值承載——它讓 LLM 具備了遠端操作真實世界的能力。

5. 生態位與平台邏輯

Remote MCP Server 的出現催生了一個新的生態層級：

┌─────────────────────────────────────────────┐
│              AI Agent / LLM Host            │
│     (Claude, Cursor, 自研Agent 等)          │
├─────────────────────────────────────────────┤
│           MCP Client（協議層）               │
├──────────┬──────────┬───────────────────────┤
│ Remote   │ Remote   │ Remote                │
│ MCP      │ MCP      │ MCP                   │
│ Server A │ Server B │ Server C ...          │
│ (GitHub) │ (Slack)  │ (資料庫/SaaS/...)     │
└──────────┴──────────┴───────────────────────┘
         ▲
         │
    誰來"發現"這些Server？
    ──→ MCP Server Registry / Directory

關鍵競爭點：當 Remote MCP Server 大量湧現後，發現層（Registry/Directory） 成為新的流量入口。類似移動網際網路時代 App Store 的角色——誰的目錄被最多 Host 整合，誰就掌握了分發權。

技術原理（深入機制）

MCP 協議通訊全流程（遠端場景）

步驟 1: 初始化握手 (Initialize)
┌────────┐  ── initialize request ──>  ┌────────────┐
│ Client │                              │ Remote     │
│        │  <-- initialize response ──  │ MCP Server │
└────────┘     (能力協商)               └────────────┘
     │                                       │
     │  步驟 2: OAuth 鑑權（如需要）           │
     │  <-- 401 + WWW-Authenticate ──────────│
     │  --> Authorization: Bearer  ──>│
     │                                       │
     │  步驟 3: 工具發現                       │
     │  ── tools/list request ──────────────>│
     │  <-- tools/list response ─────────────│
     │     (返回工具名 + 描述 + 引數schema)     │
     │                                       │
     │  步驟 4: 工具呼叫                       │
     │  ── tools/call request ──────────────>│
     │     {name, arguments}                 │
     │  <-- tools/call response ─────────────│
     │     {content, isError}                │
     │                                       │
     │  步驟 5: 流式通知（可選）                │
     │  <-- notifications/... ──────────────│
     │     (SSE 或 Streamable HTTP 推送)      │

JSON-RPC 訊息格式（簡示）

// Request (Client → Server)
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search_database",
    "arguments": {
      "query": "Q4 revenue",
      "limit": 10
    }
  }
}

// Response (Server → Client)
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Q4 revenue was $X.XB..."
      }
    ],
    "isError": false
  }
}

Streamable HTTP 傳輸特徵

場景 A: 簡單請求 → 單次 JSON 響應
  POST /mcp  →  200 OK  { "result": ... }

場景 B: 長時間操作 → SSE 流
  POST /mcp  →  200 OK  Content-Type: text/event-stream
                         data: { "progress": "30%" }
                         data: { "progress": "100%", "result": ... }

場景 C: 服務端推送通知 → 客戶端預建 SSE 連線
  GET /mcp (Accept: text/event-stream)  →  持久連線
                         ← 服務端按需推送 notifications

這種設計允許同一個 endpoint 同時支援無狀態的請求/響應和有狀態的流式互動，是 Remote MCP 相比早期 SSE-only 方案的關鍵改進 [基於規範公開討論，具體版本演進請參閱官方文件]。

技術演進史

階段	時間 [大致]	關鍵事件
MCP 初始版本釋出	2024 Q4 [大致]	Anthropic 開源 MCP 協議，stdio 本地傳輸，Claude Desktop 率先整合
早期生態	2024 Q4 – 2025 Q1	Cursor、Cline 等 IDE 工具接入，社群大量本地 MCP Server 湧現
遠端傳輸支援	2024 Q4 [大致]	MCP 初始規範即包含 SSE 遠端傳輸，Server 可作為 HTTP 服務部署
Streamable HTTP	2025 H1 [大致]	傳輸層進一步演進，支援無狀態/有狀態靈活切換
OAuth 鑑權標準化	2025 [大致]	規範引入 OAuth 2.0 授權流程，為商業化 Remote Server 鋪路
平台級整合	2025 進行中	多家廠商關注 MCP 協議，評估整合可能，Remote Server 生態加速擴張

⚠️ 以上時間線為基於公開報道的 [大致推斷]，具體日期請以各公司官方公告和 MCP 規範 changelog 為準。

技術路線對比

與替代方案的對比

維度	Remote MCP Server	Function Calling（原生）	自定義 REST API + Agent	LangChain Tools 等架構層
標準化程度	開放標準協議	各廠商私有定義	無統一標準	架構內統一，跨架構不互通
互操作性	任一 MCP Client 可連線任一 Server	繫結特定模型廠商	需逐個適配	繫結特定架構
傳輸標準化	HTTP + JSON-RPC	各廠商自定義	REST/GraphQL 等	架構自定義
鑑權標準化	OAuth 2.0（規範級）	各廠商自定義	自行實現	架構層或自行實現
工具發現	規範化 list 介面	模型級 schema 定義	文件/Swagger	架構內註冊
生態開放性	高（任何人可部署 Server）	低（依賴模型廠商）	中（無標準）	中（架構繫結）
成熟度	快速迭代中	較成熟	成熟	較成熟

本地 MCP vs Remote MCP

維度	本地 MCP Server	Remote MCP Server
部署成本	零（使用者本機執行）	需伺服器/雲端資源
安全模型	本地信任	OAuth + 網路鑑權
可達性	單機單使用者	任意網路可達，多使用者
更新維護	使用者手動更新	服務端統一更新
適用場景	開發者工具、個人助手	SaaS 整合、企業級、Agent 平台
商業化路徑	弱（開源工具為主）	強（API 呼叫計費、訂閱模式）

上下游

上游（Remote MCP Server 依賴什麼）

┌─────────────────────────────────────────────┐
│  基礎設施層                                    │
│  ├─ 雲端伺服器 / 容器平台（AWS, GCP, Azure...）    │
│  ├─ CDN / 邊緣節點（低延遲分發）                  │
│  └─ 資料庫 / 向量庫 / 外部 API（工具的資料底座）    │
│                                               │
│  協議與標準層                                    │
│  ├─ MCP 規範（JSON-RPC, 傳輸層, 認證層）          │
│  ├─ OAuth 2.0 / OIDC（身份鑑權）                 │
│  └─ OpenAPI / JSON Schema（工具引數描述）         │
│                                               │
│  開發工具層                                      │
│  ├─ MCP SDK（TypeScript/Python/Java/Kotlin...） │
│  └─ 部署架構 / Serverless 平台                   │
└─────────────────────────────────────────────┘

下游（誰消費 Remote MCP Server）

┌─────────────────────────────────────────────┐
│  MCP Host / Client 層                        │
│  ├─ AI 對話產品（Claude 等已支援 MCP 的產品）      │
│  ├─ AI IDE / 開發工具（Cursor, VS Code...）      │
│  ├─ AI Agent 架構（自研 Agent 平台）              │
│  └─ 企業工作流平台（內部 Agent 系統）              │
│                                               │
│  發現與管理層                                    │
│  ├─ MCP Server Registry / Directory           │
│  ├─ API Gateway / 管理面板                      │
│  └─ 企業治理 / 審計系統                          │
│                                               │
│  終端使用者                                       │
│  └─ 開發者 / 知識工作者 / 企業員工                 │
└─────────────────────────────────────────────┘

關鍵指標

評估 Remote MCP Server 生態的核心指標：

指標	說明	當前狀態
已釋出 Remote Server 數量	各 Registry/Directory 上線的遠端 MCP Server 總數	快速增長中 [具體數字需查閱最新統計]
頭部 Host 整合數	Claude / Cursor 等主流 Host 對 MCP 的支援狀態	多家已表態支援，程度不一 [具體進展請查各廠商公告]
協議版本覆蓋	各 Host/Server 對最新規範特性（Streamable HTTP, OAuth 等）的相容情況	處於快速迭代期，相容性參差不齊 [定性判斷]
呼叫量 / DAU	Remote Server 的實際呼叫頻次	未充分揭露，缺乏公開統計資料
平均延遲（p50/p99）	網路往返 + 工具執行的端到端延遲	因工具型別差異極大，無統一基準
認證成功率	OAuth 流程的完成率	未充分揭露

供需與市場資料

需求側驅動

AI Agent 自主性提升：模型從”對話”走向”行動”，需要標準化的工具呼叫基礎設施。Remote MCP 降低了工具整合的邊際成本。
SaaS 廠商的 AI 化需求：Saleshop、Slack、Notion 等 SaaS 產品需要向 AI 開放能力，Remote MCP 提供了標準化的暴露方式。
企業私有資料接入：企業希望 Agent 安全地訪問內部系統（ERP、CRM、知識庫），Remote MCP + OAuth 提供了合規路徑。

供給側格局

層級	參與者型別	代表 [基於公開報道]
協議層	標準制定者	Anthropic（MCP 創始方）
Host/Client 層	模型廠商、IDE 廠商	Anthropic (Claude)、Cursor 等已整合 MCP 的廠商，其他多家廠商仍在探索中 [各自支援程度不同]
Server 層	SaaS 廠商、工具開發者	大量第三方開發者和企業 [生態快速擴張中]
Registry/Directory 層	發現平台	Anthropic 官方 Registry、第三方目錄站 [處於早期]
基礎設施層	雲端服務商、MCP 託管平台	各雲端廠商 [間接參與]

市場規模

無可靠公開資料。Remote MCP 生態仍處於早期階段，尚未形成獨立的市場規模統計口徑。可類比的參考：全球 API 經濟市場規模在數千億美元量級 [行業報告估算口徑不一]，Remote MCP 作為 AI-native 的工具介面層，可能從中切分一部分份額，但具體數字 [未充分揭露]。

代表公司與資本對映

核心參與者

角色	公司	與 Remote MCP 的關係	上市狀態
協議發起方	Anthropic	MCP 創始者和主要推動者，Claude 是首個深度整合 MCP 的 Host	未上市（一級市場）
模型廠商	OpenAI	對 MCP 協議保持關注，尚未正式宣佈支援 [具體進展請查官方公告]	未上市（一級市場）
模型廠商	Google (Alphabet)	Gemini 生態的工具整合策略待觀察	GOOGL
軟體平台	Microsoft	VS Code / Copilot 生態與 MCP 的整合潛力	MSFT
IDE 廠商	Cursor	早期深度整合 MCP 的 AI IDE，Remote MCP 提升其工具生態豐富度	未上市（一級市場）
雲端基礎設施	AWS / Azure / GCP	Remote MCP Server 的託管和執行環境	AMZN / MSFT / GOOGL
API 基礎設施	Cloudflare	閘道器、邊緣計算與 MCP Server 託管的潛在整合	NET

產業鏈對映邏輯

Remote MCP 生態擴張
    │
    ├── MCP Server 數量增加 → 工具供給豐富 → Agent 能力增強
    │       │
    │       └── 利好：AI Agent 平台公司、SaaS 公司（新增 AI 分發渠道）
    │
    ├── Host 端整合 MCP → 使用者可用工具增多 → Host 競爭力增強
    │       │
    │       └── 利好：Claude、Cursor 等先發整合者
    │
    ├── 呼叫量增長 → 網路流量 + 計算負載增加
    │       │
    │       └── 利好：雲端服務商、CDN、API 閘道器
    │
    └── 發現層（Registry）形成規模
            │
            └── 利好：控制 Registry 入口的平台（潛在"AI 工具 App Store"）

投資邏輯

看多邏輯

協議標準化紅利：MCP 正在成為 AI 工具呼叫的事實標準之一（“USB for AI”敘事），Remote MCP 是其商業化的核心路徑。先發深度繫結 MCP 的公司享有生態位優勢。
Agent 範式不可或缺的基建：如果 AI Agent 是下一代計算範式，那標準化的遠端工具呼叫協議就是其”神經系統”。Remote MCP Server 生態的繁榮意味著 Agent 能力的指數級擴充套件。
SaaS 公司的第二增長曲線：SaaS 產品通過 Remote MCP Server 向 AI 開放能力，本質上是在傳統人力使用者之外，新增了 AI Agent 作為”使用者”，可能帶來呼叫量級的躍遷。
Registry 入口價值：如果 Remote MCP Server 數量達到數十萬量級，一個被主流 Host 整合的 Registry 將具備類 App Store 的分發權和定價權。

看空/風險邏輯

協議碎片化風險：MCP 並非唯一選擇，OpenAI 的 Function Calling、Google 的 Extensions 等各有生態。如果主要模型廠商各搞各的，MCP 可能無法成為統一標準。
安全攻擊面擴大：Remote MCP 讓 AI 具備了遠端操作能力，也意味著攻擊面從本機擴大到整個網路。任何嚴重的安全事件（如 Agent 被誘導惡意呼叫工具）都可能重創生態信任。
商業模式尚未驗證：Remote MCP Server 的計費模型（按呼叫次數？按 Token？訂閱？）尚無成熟範式，變現路徑存在不確定性。
去中心化 vs 中心化博弈：如果各大平台傾向於在自己的封閉生態內建置工具整合（而非採用開放標準），Remote MCP 的開放互聯價值將被削弱。

關鍵觀察變數

頭部 3 家以上模型廠商是否都原生支援 MCP
是否出現千萬級呼叫量的 “killer” Remote MCP Server
是否出現主流的商業化 MCP Registry 平台
企業客戶對 Remote MCP 的採購決策案例

常見誤讀糾偏

誤讀 1：“Remote MCP Server 就是把 API 用 HTTP 包了一下，本質還是 REST API”

糾偏：Remote MCP Server ≠ 簡單的 API Wrapper。核心差異在於：

標準化的發現協議：Client 可以通過 tools/list 自動發現 Server 暴露的所有工具及其引數 schema，無需硬編碼或查閱文件。這是 REST API 不具備的。
面向 LLM 的語義描述：工具的 description 和引數 schema 是為 LLM 理解和推論而設計的，不僅僅是給人類讀的 API 文件。
協議級的雙向通訊：Streamable HTTP 支援服務端主動推送通知（如任務進度），比傳統 REST 的單向請求-響應模型更豐富。
統一的鑑權發現機制：OAuth 流程被納入協議規範，而非每個 API 各自為政。

誤讀 2：“MCP 只是 Anthropic 的私有協議，大廠不會用”

糾偏：雖然 MCP 由 Anthropic 發起，但它是 開源標準（協議規範和 SDK 均開源）。截至 2025 年，已有多家主要廠商表態支援或在產品中整合 MCP [具體整合深度和時間線請查各廠商官方公告]。協議的生命力取決於生態採納度，而非發起者的控制力——類似 HTTP 由 Tim Berners-Lee 發起但屬於整個網際網路。

誤讀 3：“Remote MCP Server 的主要價值是遠端訪問”

糾偏：遠端訪問只是手段，核心價值是 降低了 AI 工具生態的整合摩擦：

對工具提供方：只需實現一個 MCP Server，即可被所有支援 MCP 的 Host 使用，無需逐個適配。
對 Host 開發者：只需實現 MCP Client，即可接入所有 MCP Server，無需逐個對接工具。
這是網路效應——每多一個 Host 支援 MCP，所有 Server 的潛在使用者就增加；每多一個 Server，所有 Host 的能力就增強。

誤讀 4：“有了 MCP 就不需要 Function Calling 了”

糾偏：兩者在不同層級運作。Function Calling 是模型廠商在推論層實現”模型決定呼叫什麼函式”的能力；MCP 是在應用層標準化”如何發現、連線和呼叫遠端工具”的協議。理想狀態下，Host 通過 Function Calling 讓模型決策，再通過 MCP 協議實際呼叫 Remote Server——兩者是互補而非替代關係。

學習路徑

入門（1-2 小時）

閱讀 MCP 官方文件中的 Introduction 部分，理解 Host/Client/Server 三層架構
在 Claude Desktop 或 Cursor 中配置一個本地 MCP Server（如 filesystem server），親身體驗工具呼叫
閱讀 MCP 規範中關於 Resources、Tools、Prompts 三類原語的定義

進階（3-5 小時）

使用 MCP SDK（TypeScript 或 Python）編寫一個簡單的 Remote MCP Server，部署到雲端上
理解 Streamable HTTP 傳輸層的工作機制，對比 stdio 和 HTTP 兩種模式的差異
研究 OAuth 2.0 在 MCP 中的整合方式
閱讀 MCP 規範中的 JSON-RPC 訊息定義和生命週期管理

深度（持續跟進）

關注 MCP 規範倉庫的 Issues 和 Pull Requests，追蹤協議演進方向
研究主流 Host（Claude, Cursor 等）的 MCP 整合實現和差異
思考 Remote MCP 在企業場景下的安全治理模式（RBAC、審計、限流）
對比 MCP 與其他工具呼叫方案的異同