MCP 生產部署地雷圖：為什麼 86% 的 MCP Server 還困在 Localhost

你在本地用 stdio 跑 MCP server，Claude 完美地呼叫工具、回傳結果，一切順暢到你以為部署只是「換個環境跑」的事。然後你 push 到雲端，Docker 容器啟動三秒後 exit，Kubernetes 部署隨機失敗，agent 開始「失智」忘記任務——歡迎來到 MCP 生產部署的真實世界。

我們在 agent fleet 的部署測試中踩過這些坑。這篇文章是我們整理的「生產部署地雷圖」——從傳輸層、認證、token 消耗到 session 隔離，逐一拆解 MCP 從 localhost 到 production 之間的每一個斷裂點。

TL;DR

• stdio 傳輸不適合生產環境：20 個同時連線下 91% 請求失敗（20/22，Apigene 業界分析），唯一正確的生產選擇是 Streamable HTTP（SSE 已在 2025-11-25 規範版本廢棄）
• 38.7% 的公開 MCP server 零認證（Bloomberry 1,412 server 調查），規範把 auth 標記為 OPTIONAL，這不是 bug 是 spec
• Agent 失智 = token 稅問題：5 個常見 MCP server（GitHub、Slack、Sentry、Grafana、Splunk）合計 58 個工具定義消耗約 55,000 tokens，在第一條 user message 前最高吃掉 context window 的 50%
• Kubernetes 部署隨機失敗是協議設計問題：MCP 官方 2026 roadmap 直接承認 "stateful sessions fight with load balancers" 是擴展痛點
• AAIF 是政治訊號不是安全保證：AWS/Google/Microsoft 加入代表 MCP 不會被廢棄，但不提供 auth 標準化、compliance certification 或安全基線
• 三大真實事故：Asana tenant 資料洩露（約 1,000 客戶）、Postmark 惡意 npm（BCC 攻擊）、Supabase RLS bypass——都在 2025 年發生

---

你的 MCP 在本地跑得完美——為什麼一部署就死？

先說症狀：你的 MCP server 在本地用 stdio 完美運作，Docker 部署後 container 啟動三秒就 exit。或者，你用 HTTP+SSE 部署到雲端，單人測試正常，第二個用戶連進來就全部掛掉。

這不是你的程式有 bug——是你用錯了傳輸機制。

三種傳輸的現實

傳輸方式	適用場景	生產可用性	狀態
stdio	本地開發、單人測試	不適合	規範支援，但僅限 1:1 parent-child process
HTTP+SSE	你 Google 到的教學幾乎都用這個	不建議新部署	2025-11-25 規範版本正式廢棄
Streamable HTTP	生產環境唯一選擇	適合	規範當前標準

Apigene 的部署測試（業界分析）給了一個殘酷的數字：stdio 在 20 個同時連線下，20/22 請求失敗——失敗率 91%。你本地測試沒問題，純粹是因為只有你一個 client。

重要：如果你現在的 MCP 教學是用 SSE 傳輸，請注意 SSE 已在 2025-11-25 規範版本正式廢棄。所有新部署應該直接使用 Streamable HTTP。

Docker 部署四個必查點

我們在容器化部署中反覆踩到的四個坑：

1. stdio server 需要 -i flag

# 錯誤：stdin 關閉，container 立即 exit
docker run my-mcp-server

# 正確：保持 stdin 開啟
docker run -i my-mcp-server

2. Server 必須 listen 0.0.0.0

// 錯誤：本機 loopback，容器外連不到
server.listen(3000, '127.0.0.1');

// 正確：所有介面
server.listen(3000, '0.0.0.0');

3. Port mapping 正確設定

# docker-compose.yml
services:
  mcp-server:
    ports:
      - "3000:3000"  # host:container 必須一致
    environment:
      - MCP_TRANSPORT=streamable-http

4. Volume permission：非 root user 執行時，mounted volume 的寫入權限經常出問題。先在 Dockerfile 中設定正確的 user/group。

---

MCP 的 Auth 是「OPTIONAL」——規範這樣寫，38.7% 的 Server 這樣做

你可能以為 MCP 規範要求認證——但翻開 MCP Authorization Specification，auth 被明確標記為 OPTIONAL。

Bloomberry 分析了 1,412 個公開（publicly-listed）MCP server，結果令人不安（注意：此數據代表公開發布的 server，企業內部私有部署的安全設定通常截然不同）：

Auth 方式	比例	意義
零認證	38.7%	任何人都能連線、列舉所有工具
Static API Key / PAT	53%	比沒有好，但金鑰外洩就全完了
OAuth 2.1	8.5%	官方推薦，但實作極少

更諷刺的是：想要「正確」實作 OAuth 2.1 的企業開發者，馬上遇到另一個問題——原始規範把 MCP server 本身當作 authorization server。如果你的企業用 Okta 或 Azure AD 作為身份驗證中心，這個假設根本行不通。

OAuth 專家 Aaron Parecki 記錄了這個設計問題——他指出根本原因正是原始規範要求使用 RFC 8414（OAuth Server Metadata），這迫使 MCP server 必須同時身兼授權伺服器。規範後來更新，允許將授權委派給外部 IdP，但 SDK 的實作還在追趕中。

今天的 Auth 決策矩陣

你的場景	推薦方案	理由
獨立開發者 / 內部工具	Static bearer token + server-side validation	快速上線，風險可控
SaaS 產品 / 多租戶	OAuth 2.1 + external IdP	長期正確，但需要自行整合
企業內部（Okta/Azure AD）	OAuth 2.1 + RFC 8414 metadata delegation	等 SDK 完善，或自行實作 wrapper

重要：不論用哪種方案，MCP 規範有兩條硬性要求——token 禁止放在 URI query string，server 禁止 passthrough 收到的 token（防止 confused deputy 攻擊）。

---

Agent 失智不是你的 Prompt 有問題——是 Token 帳單問題

你的 Claude agent 使用 MCP 工具到一半，突然開始亂用工具、忘記任務目標、甚至回答跟問題完全無關的內容。你以為是 prompt 寫得不好，花了三天調整 system prompt——但問題根本不在那裡。

真相：Context Window 被工具定義稅吃掉了

每個 MCP tool 的 JSON Schema 定義會被注入 context window，不論你是否呼叫它。這是固定成本：

指標	數字	來源
GitHub MCP 工具數量	35 個	GitHub MCP Server
GitHub MCP token 消耗	約 26,000 tokens	Lunar.dev 分析
5 個 server 合計（GitHub、Slack、Sentry、Grafana、Splunk）	58 個工具，約 55,000 tokens	Lunar.dev 分析
每個 tool 定義成本	550–1,400 tokens	業界測量
5 個 MCP server + 150 工具	30,000–100,000 tokens	業界估算
200k context window 佔比	最高 50%	計算值

換句話說，在你發送第一條 user message 之前，context window 可能已經被工具定義吃掉一半。

MCP vs 直接 REST API 的成本對比

Scalekit 的 75 組對照 benchmark 顯示：MCP 比直接 CLI/REST API 操作貴 4–32 倍（4 倍接近簡單的單步 read 操作；32 倍發生在多工具鏈式呼叫的複雜 write 操作）。

如果你的 use case 只用 1–3 個工具，直接用 REST API 或 function calling（不透過 MCP）的 token 效率好很多。MCP 的優勢在多 server 統一接口和動態工具組合——但這個優勢值多少 token overhead，需要你自己評估。

三個緩解方案

1. 限制 MCP server 數量：不是每個 server 都需要同時載入，30 個工具以下是合理參考上限
2. MCP Tool Search：Anthropic 從 2025 年 11 月起支援 on-demand 載入，開發者需在工具定義中標記 defer_loading: true 啟用。建議當工具定義超過 10K tokens 時使用，可保留 95% 的 context window（減少約 85% 的 token overhead）
3. Claude Code Mode：針對程式碼任務大幅降低 token 消耗，但需要評估是否適合你的 workflow

---

Kubernetes 部署 MCP——官方承認的設計限制，不是你的 YAML 問題

你把 MCP server 部署到 Kubernetes，有時成功有時失敗，完全看不出規律。你懷疑是 YAML 寫錯、resource limit 不夠、或 network policy 有問題——但真正的問題是 MCP 協議本身的設計。

協議設計 vs 負載均衡

MCP 維護 per-connection 的 server-side session state。Client 透過 SSE/Streamable HTTP 連到 Pod A 建立 session 後，後續的 POST request 必須到達同一個 Pod A。

但 Kubernetes 的預設行為是 round-robin load balancing——後續 request 被送到 Pod B，Pod B 沒有 session state，協議立即斷裂。

GitHub Discussions #102 記錄了一位 PHP 開發者的真實經歷：「Kubernetes with multiple pods, POST requests get round-robined to different pod from SSE connection = breaks protocol。」

官方 2026 roadmap 直接承認「stateful sessions fight with load balancers」是 MCP 的擴展痛點之一。

今天的唯一解法：Sticky Session + External Session Store

# Nginx sticky session 設定
upstream mcp_backend {
    ip_hash;  # 基於 client IP 的 sticky session
    server mcp-pod-1:3000;
    server mcp-pod-2:3000;
    server mcp-pod-3:3000;
}

server {
    location /mcp {
        proxy_pass http://mcp_backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

搭配 Redis 作為 external session store，確保即使 request 偶爾跑到不同 Pod，session state 仍可取得：

import Redis from 'ioredis';

const redis = new Redis(process.env.REDIS_URL);

// 儲存 session state 到 Redis，不要用 in-memory
async function saveSessionState(sessionId: string, state: object) {
  await redis.set(`mcp:session:${sessionId}`, JSON.stringify(state), 'EX', 3600);
}

async function getSessionState(sessionId: string) {
  const data = await redis.get(`mcp:session:${sessionId}`);
  return data ? JSON.parse(data) : null;
}

Cold Start vs Always-on 費用決策

部署方式	Cold Start	估算月費（25 RPD）
Azure Container Apps（scale-to-zero）	10–30s	約 $0 + per-request
AWS Lambda	500ms–2s	約 $0 + per-invocation
Cloud Run min-instances=1	<10ms	約 $15/月
AWS ECS always-on（t3.medium）	<10ms	約 $30/月
傳統 VM	<10ms	約 $20–50/月

💡 提示：如果用戶體驗重要，Cloud Run 設定 min-instances=1（約 $15/月）是消滅 cold start 最便宜的方案。10–30 秒的 cold start 在 WebSocket/SSE 長連線場景中，用戶會直接感受到連線斷開。

Timeline：MCP 官方 2026 roadmap 已將 stateful session 與 load balancer 的衝突列為已知擴展痛點，但尚未公布具體的 stateless transport 發布時程。持續追蹤 roadmap 更新以掌握進展。

---

AAIF 的真相——AWS/Google/Microsoft 加入是政治訊號，不是安全保證

2025 年 12 月 9 日，Linux Foundation 宣布成立 Agentic AI Foundation（AAIF）。Anthropic 捐贈 MCP、Block 捐贈 Goose、OpenAI 捐贈 AGENTS.md。Platinum 成員包含 AWS、Google、Microsoft、OpenAI——陣容華麗。

但 AAIF 解決的問題和你想的可能不一樣：

AAIF 解決的	AAIF 不解決的
協議中立治理（防止 Anthropic 單方面控制）	Auth 標準化
SDK 兼容性 Working Group	SSO 整合規範（Okta/Azure AD）
防止協議被單一公司廢棄	Compliance certification（SOC 2/ISO 27001）
開源社群治理流程	生產安全基線
	誰可以發布 MCP server（無門檻）

AWS、Google、Microsoft 成為 Platinum member 是一個重要的政治訊號——MCP 不會被 Anthropic 單方面廢棄，是一個會長期存在的協議。但 AAIF membership 不能替你背書任何一個 MCP server 是「企業就緒」的。

MCP Enterprise Ready 自評框架

在 AAIF 提供正式認證之前（目前沒有時間表），你需要自己回答這五個問題：

• Auth 是否已設定？（不是零認證就好，是有完整的 token 生命週期管理）
• Session 是否隔離？（無全域可變 state，session ID keyed）
• Dependency 是否鎖定？（package-lock.json / yarn.lock 存在且定期審計）
• 是否只使用 Tier 1 官方 server？（Anthropic / GitHub / Cloudflare 自己維護）
• Tool description 是否定期掃描？（防止 tool poisoning 攻擊）

---

環境變數地獄——MCP 生態系沒有統一規範的代價

同時使用 3 個 MCP server？恭喜，你即將面對 env var 命名地獄：

# ClickUp MCP
MCP_API_KEY=xxx

# PostgreSQL MCP
DATABASE_URL=postgres://user:pass@host:5432/db

# GitHub MCP
GITHUB_TOKEN=ghp_xxxxx

沒有統一命名規範。每個 server 自己定義。${env:VAR} 語法只有部分 server 支援。

Docker MCP Gateway 的靜默覆蓋

Docker MCP Gateway issue #317 記錄了一個特別陰險的行為：gateway 從 config.yaml + Docker secret 讀取 credential，找不到時用空值覆蓋已設定的 credential——不報錯、不警告、靜默失敗。

你的 env var 明明設好了，但 server 讀到的是空字串。debug 時請先確認 credential 是否真的傳到了 server process。

v1.27.1 修了讓你 Debug 三天的 Silent Bug

如果你的 MCP server 斷線後 agent 靜默失敗，沒有任何 error log——在 v1.27.1 之前的 TypeScript SDK 版本，transport error 會被 silently swallowed，onerror callback 根本不觸發。

這代表連線斷開、session 失效、傳輸錯誤——你的 agent orchestration 層完全不知道發生了什麼。v1.27.1 修復了這個 bug，現在 onerror callback 會正確觸發。

重要：「MCP v1.27」在業界文章中混指兩個東西——協議規範用日期版本（最新 2025-11-25）、TypeScript SDK 用 semver（v1.27.1）。讀到相關資料時，先確認指的是哪一個。

環境變數管理實戰方案

# .env.mcp — 統一管理所有 MCP server 的 credential
# ClickUp
CLICKUP_MCP_API_KEY=xxx

# PostgreSQL
POSTGRES_MCP_DATABASE_URL=postgres://...

# GitHub
GITHUB_MCP_TOKEN=ghp_xxx

# 前綴命名規範：{SERVICE}_MCP_{KEY_TYPE}

在 CI/CD pipeline 加入啟動前驗證：

#!/bin/bash
# mcp-env-check.sh — server 啟動前驗證 credential
REQUIRED_VARS=("GITHUB_MCP_TOKEN" "POSTGRES_MCP_DATABASE_URL")

for var in "${REQUIRED_VARS[@]}"; do
  if [ -z "${!var}" ]; then
    echo "ERROR: $var is not set. Aborting."
    exit 1
  fi
done

echo "All MCP credentials verified. Starting server..."

---

三大真實事故的解析——你使用的第三方 MCP Server 是安全的嗎？

2025 年發生了三起 MCP 相關的安全事故，它們的共同根源揭示了 MCP 生態系目前的結構性風險。

事故 1：Asana Tenant 資料洩露（2025 年 6 月）

• 時間線：2025 年 5 月 1 日上線 MCP server → 6 月 4 日發現 tenant isolation 漏洞 → 約 1,000 客戶受影響 → server 下線 2 週修復
• Root Cause：cached response 沒有重新驗證 tenant context。User B 的 request 可能讀到 User A 的專案名稱、任務描述和 metadata
• 模式：Confused Deputy——server 信任了不該信任的 cached session state

事故 2：Postmark 惡意 npm Package（2025 年 9 月）

• 手法：攻擊者建立了非官方的 postmark-mcp npm package，經過 15 個版本建立信任後，在 v1.0.16 加入隱藏 BCC
• 影響：每週約 1,500 次下載（下架前累計 1,643 次），所有透過此 server 發送的 email 被靜默複製到攻擊者的信箱
• 模式：Supply Chain Attack——利用 npm 生態系的信任機制

事故 3：Supabase/Cursor RLS Bypass

• 手法：MCP server 使用 service_role key 繞過 Row-Level Security，加上 prompt injection 導致資料外洩
• 模式：Privilege Escalation——MCP server 持有過高權限的 credential

共同根源

arXiv 的 MCP 威脅分類研究歸納了 7 個威脅類別、23 個攻擊向量——沒有任何單一防禦措施覆蓋超過 34% 的已識別威脅。

第三方 MCP Server 安全評估 4 問

在使用任何第三方 MCP server 前，問自己：

1. 誰維護？ 是官方（Anthropic/GitHub/Cloudflare）還是社群？
2. 有沒有 security contact？ npm page 是否有 bug report 管道？
3. Dependency 最後更新是何時？ 超過 90 天未更新是警訊
4. npm registry 名稱是否與官方一致？ postmark-mcp 不是 Postmark 官方的

---

多 Tenant Session 隔離——MCP 協議不負責，你必須自己做

如果你的 MCP server 要服務多個 tenant，有一個關鍵事實必須理解：MCP 協議本身不保證 session 隔離——這完全是 server 開發者的設計責任。

MCP GitHub Issue #1087 記錄了風險：如果 server 用全域變數儲存 session state（例如 self.last_email），User B 的 request 可能讀到 User A 的資料。這正是 Asana 事故的 root cause。

三個隔離失敗模式

1. 全域可變 state：let currentUser = ... 在模組層級宣告，所有 session 共用
2. 共用 in-memory cache：cache key 不包含 session/tenant ID，跨 tenant 污染
3. 未驗證的 session state reassignment：cached response 在回傳前沒有重新驗證 tenant context

正確的 Multi-Tenant MCP Server 設計

// 錯誤：全域可變 state
let lastQuery: string; // 所有 session 共用！

// 正確：session ID keyed state
const sessionState = new Map<string, SessionData>();

function handleRequest(sessionId: string, request: McpRequest) {
  const state = sessionState.get(sessionId);
  if (!state || state.tenantId !== request.tenantId) {
    throw new Error('Session/tenant mismatch');
  }
  // ... 處理 request
}

搭配資料庫的 row-level security 和定期的 session ID 碰撞測試，確保隔離完整性。

---

MCP 生態系現況——為什麼「95% 是垃圾」這句話有資料支撐

「95% 的 MCP server 是垃圾」這句話在 Reddit 被廣泛引用——聽起來極端，但 Bloomberry 的資料相當接近這個觀感。

生態系健康指標

指標	數字	來源
遠端 endpoint 死亡率	52%	Bloomberry 2,181 endpoint 研究
完全健康的 endpoint	9%	同上
實作 rate limiting	2.4%	Bloomberry 1,412 server 分析
CORS 完全開放	22.9%	同上
零認證	38.7%	同上

Server 分級建議

Tier	定義	範例	生產使用建議
Tier 1	官方自己維護	Anthropic / GitHub / Cloudflare	可用，但仍需設定 auth
Tier 2	大公司官方發布	Asana / Stripe / Notion 官方 MCP	需評估安全紀錄
Tier 3	活躍社群維護	有 security contact、定期更新	需完整安全審計
Tier X	無維護者	最後 commit 超過 90 天	不建議生產使用

為什麼生態系是這個狀態

• Tooling 不成熟：沒有 MCP server 認證流程，任何人都能發布
• OAuth 採用率極低（8.5%）：規範標記為 OPTIONAL，SDK 預設不含 auth
• 沒有強制安全基線：AAIF 目前不提供 compliance certification

長期樂觀的理由

1. AAIF 治理：防止 Anthropic 單方面控制 roadmap，確保中立演化
2. Stateless transport 目標：roadmap 已列為擴展痛點，待協議層解決 session vs load balancer 衝突
3. MCP Tool Search：透過 defer_loading: true 標記緩解 context drift 的 token 消耗問題
4. MCP Tool Search GA：Anthropic 2026 年 2 月將 Tool Search 和 Programmatic Tool Calling 推向正式版，大型工具集的 token 消耗問題正在生態系層面緩解

---

MCP 生產部署 Checklist——今天就能執行的 15 個檢查點

Transport 層

• Streamable HTTP 確認：生產環境一律使用 Streamable HTTP，不要用 stdio 或已廢棄的 SSE（→ 看「為什麼一部署就死」段落）
• 0.0.0.0 binding：server listen 地址不是 127.0.0.1（→ 看 Docker 部署四個必查點）
• SSE 禁用：新部署不要使用 HTTP+SSE，已有的盡快遷移

Auth 層

• Bearer token 到位：至少使用 static bearer token，不是零認證（→ 看 Auth 決策矩陣）
• Token 不在 URI query string：MCP 規範硬性要求
• Token 生命週期設定：access token ≤1 小時，搭配 refresh token

Session 層

• Sticky session 設定：Nginx ip_hash 或 ALB cookie affinity（→ 看 Kubernetes 段落）
• External session store：Redis 或 PostgreSQL，不要只用 in-memory

Context 管理

• Tool count audit：單一 server 工具數量 < 30 是參考上限（→ 看 token 帳單段落）
• MCP Tool Search 確認啟用：工具定義超過 10K tokens 的 server，標記 defer_loading: true 啟用 on-demand 載入（2025 年 11 月起支援）

Env 管理

• Credential 啟動驗證：CI/CD pipeline 加入 env var 檢查腳本（→ 看環境變數地獄段落）
• .env.mcp 集中管理：統一前綴命名，避免跨 server 覆蓋

Tenant 隔離

• Session ID keyed state：無全域可變 state，每個 session 獨立（→ 看多 Tenant 隔離段落）

Supply Chain

• 只用 Tier 1 官方 server：生產環境避免使用未經驗證的第三方 server（→ 看三大事故段落）
• Dependency lock + 定期 audit：package-lock.json 存在，定期掃描 tool description

---

風險揭露

本文涉及 MCP server 的生產部署安全決策。幾個重要的風險提醒：

1. MCP 協議仍在快速演化中：2025-11-25 規範版本廢棄了 SSE，roadmap 已將 stateless transport 列為目標。今天的最佳實踐可能在半年後改變。
2. 本文引用的第三方數據（Bloomberry 1,412 server 分析、Apigene 部署測試）為業界獨立研究，非官方 MCP 團隊發布，數字可能隨生態系成熟而改善。
3. Cold start 費用為估算值：實際費用取決於你的 request 量、region、provider 定價變動。
4. 使用第三方 MCP server 需要你自己評估安全風險：AAIF 不提供認證，「Tier 1 / Tier 2」分級是本文的建議框架，非官方標準。
5. Auth 方案選擇涉及你的安全需求：static bearer token 是過渡方案，不是長期安全架構。

---

結論：MCP 的潛力是真的，但生產部署的坑也是真的

MCP 解決了一個真實的問題——讓 AI agent 用統一協議連接工具和資料。這個願景很好，AAIF 的成立也保證了它的長期存在。

但今天，86% 的 MCP server 還困在 localhost 是有原因的。從 stdio 到 Streamable HTTP 的傳輸斷層、規範把 auth 標記為 OPTIONAL 的設計選擇、session-per-connection 與 load balancer 的根本衝突——這些都不是你的技術能力問題，是協議和生態系尚未成熟的現實。

如果你今天要把 MCP 推上生產環境，上面的 15 點 checklist 是最低標準。跑一遍，確認每個都打勾，然後持續追蹤 MCP 2026 roadmap 的進展。

MCP 會成熟的——問題是你願不願意在成熟之前，先帶著地雷圖上路。