IBM Context Forge MCP — 使用場景, 安裝 & 即時演示

Name: IBM Context Forge MCP Server
Author: IBM

為什麼要用

核心特性

將多台 MCP 伺服器統一在單一端點後方進行聯合管理
自動將 REST 與 gRPC API 轉譯為 MCP 工具
內建 JWT / OAuth / Basic 驗證、流量限速與自動重試
OpenTelemetry 追蹤（Phoenix、Jaeger、Zipkin）與管理介面

即時演示

實際使用效果

mcp-context-forge.replay ▶ 就緒

0/0

安裝

選擇你的客戶端

~/Library/Application Support/Claude/claude_desktop_config.json · Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "mcp-context-forge": {
      "command": "uvx",
      "args": [
        "mcp-context-forge"
      ]
    }
  }
}

開啟 Claude Desktop → Settings → Developer → Edit Config。儲存後重啟應用。

~/.cursor/mcp.json · .cursor/mcp.json

{
  "mcpServers": {
    "mcp-context-forge": {
      "command": "uvx",
      "args": [
        "mcp-context-forge"
      ]
    }
  }
}

Cursor 使用與 Claude Desktop 相同的 mcpServers 格式。專案級設定優先於全域。

VS Code → Cline → MCP Servers → Edit

{
  "mcpServers": {
    "mcp-context-forge": {
      "command": "uvx",
      "args": [
        "mcp-context-forge"
      ]
    }
  }
}

點擊 Cline 側欄中的 MCP Servers 圖示，然後選 "Edit Configuration"。

~/.codeium/windsurf/mcp_config.json

{
  "mcpServers": {
    "mcp-context-forge": {
      "command": "uvx",
      "args": [
        "mcp-context-forge"
      ]
    }
  }
}

格式與 Claude Desktop 相同。重啟 Windsurf 生效。

~/.continue/config.json

{
  "mcpServers": [
    {
      "name": "mcp-context-forge",
      "command": "uvx",
      "args": [
        "mcp-context-forge"
      ]
    }
  ]
}

Continue 使用伺服器物件陣列，而非映射。

~/.config/zed/settings.json

{
  "context_servers": {
    "mcp-context-forge": {
      "command": {
        "path": "uvx",
        "args": [
          "mcp-context-forge"
        ]
      }
    }
  }
}

加入 context_servers。Zed 儲存後熱重載。

claude mcp add mcp-context-forge -- uvx mcp-context-forge

一行命令搞定。用 claude mcp list 驗證，claude mcp remove 移除。

使用場景

實戰用法： IBM Context Forge

將 10 台以上的 MCP 伺服器集中在單一閘道器後方

👤 中大型組織的平台工程師 ⏱ ~120 min advanced

何時使用： 不同團隊各自維運不同的 MCP。你需要一個統一的 URL 給用戶端、一份稽核日誌、一套統一的驗證機制。

前置條件

Docker/Kubernetes 環境 — 官方映像檔位於 ghcr.io；提供 Helm chart
驗證提供者（或使用內建 JWT） — 現有的 SSO / OIDC / 靜態 JWT 簽發者

步驟

部署閘道器

透過 Helm 部署 mcp-contextforge-gateway，搭配 Redis 管理聯合狀態，並將其指向我們的 OIDC 提供者。✓ 已複製

→ 管理介面成功載入，驗證正常運作
登錄後端服務

在管理介面中登錄 3 個後端 MCP（github、postgres、our-custom），並設定流量限速：github=100/min、postgres=30/min。✓ 已複製

→ 後端服務在登錄中心顯示為健康狀態
更新用戶端設定

將同事的 Claude Desktop 設定更新為使用單一 mcp-remote https://mcp-gw.company.com/mcp，搭配各自的 JWT。✓ 已複製

→ 所有後端工具皆可透過單一連線存取

結果： 組織內 MCP 存取權限由單一處統一管理——就像任何其他 API 閘道器一樣集中化。

注意事項

流量限速套用至全域，但各團隊需求不同 — 透過策略引擎使用每位使用者或每個 JWT 聲明的限速設定，不要對所有人套用同一個限制
閘道器成為單點故障 — 至少執行 2 個副本並使用 Redis 儲存工作階段狀態；定期對 /health 端點進行健康檢查

搭配使用： cloud-run

無需撰寫伺服器程式，將 REST API 虛擬化為 MCP

👤 沒有 Python/TS 開發人力的平台工程師 ⏱ ~60 min intermediate

何時使用： 你有一個附帶 OpenAPI 規格的內部 REST API，希望在不撰寫 fastapi-mcp 或 FastMCP 程式碼的情況下提供 MCP 存取。

前置條件

API 的 OpenAPI / Swagger 規格 — 通常位於 /openapi.json 或 /swagger.json

步驟

上傳 OpenAPI 規格

在 ContextForge 管理介面中登錄新的 REST 後端，上傳 OpenAPI 規格，確認工具自動產生功能已擷取所有端點。✓ 已複製

→ 工具清單與路由清單一致
設定驗證透傳

設定標頭轉發，讓 Authorization 標頭從 MCP 用戶端流向上游 REST API。✓ 已複製

→ 需驗證的路由可端對端正常運作
篩選公開範圍

透過路徑模式排除內部/管理路由，並對 3 個最常用的工具新增說明覆寫。✓ 已複製

→ 工具清單簡潔且對 AI 代理友好

結果： 無需撰寫任何新的服務程式碼，即可將 REST 轉為 MCP——一份 OpenAPI 規格就足夠。

注意事項

自動產生的工具名稱難以辨識 — 在 OpenAPI 規格中設定明確的 operationId，或在 ContextForge 中逐路由覆寫名稱

為組織內所有 MCP 呼叫新增追蹤與分析

👤 SRE / 平台可觀測性負責人 ⏱ ~90 min advanced

何時使用： 你想回答「今天 AI 代理做了什麼？」這個問題，涵蓋所有使用 MCP 的團隊。

前置條件

OTel 後端（Phoenix、Jaeger、Grafana Tempo） — 可接受 OTLP 的執行中端點

步驟

啟用 OTel 匯出

將閘道器的 otel.endpoint 設定為指向我們的 Phoenix 實例，並在 span 中包含工具名稱、延遲、使用者與執行結果。✓ 已複製

→ 呼叫發生後數秒內，span 出現在 Phoenix 中
建立儀表板

建立以下儀表板：呼叫量前 10 名的工具、每個後端的 p95 延遲、每位使用者的錯誤率。✓ 已複製

→ 儀表板已有資料填入
設定異常警報

針對以下情況設定警報：任一後端錯誤率 >5%，或單一使用者每小時消耗 >10k 次呼叫。✓ 已複製

→ 測試警報在 staging 環境成功觸發

結果： 取得組織層級的 MCP 全局可視性——掌握誰在使用什麼工具，以及何時發生問題。

注意事項

將每個請求 ID 作為 span 名稱導致 OTel span 基數爆炸 — span 名稱只使用工具名稱；將請求 ID 放在屬性中而非名稱中

搭配使用： sentry

組合

與其他 MCP 搭配，撬動十倍槓桿

mcp-context-forge + cloud-run

將 ContextForge 部署至 Cloud Run，並將托管於 GCP 的 MCP 統一集中在其後方

使用 IAM 驗證將 ContextForge 部署至 Cloud Run，並將我們 3 個內部 MCP（同樣在 Cloud Run 上）登錄為後端。✓ 已複製

mcp-context-forge + sentry

將閘道器的追蹤資訊與錯誤回報傳送至 Sentry，提升維運可視性

設定閘道器的 OTel 匯出，同時將錯誤推送至 Sentry，供值班人員查看。✓ 已複製

工具

此 MCP 暴露的能力

工具	輸入參數	何時呼叫	成本
Gateway federation	N registered backends	基礎設施層級的設定；非每次請求都呼叫的工具	free
REST → MCP virtualization	OpenAPI spec + target URL	將 REST 服務導入 MCP 時使用	passthrough of target API costs
gRPC → MCP translation	gRPC service descriptor	與上述相同，適用於 gRPC 後端	passthrough
Prompt registry	Jinja2 templates + variables	跨團隊共享提示詞並支援版本控制	free
Resource registry	URI-based resources	公開靜態/動態的組織內容	free
Admin API / UI	HTTP + web UI	維運與設定相關任務	free

成本與限制

運行它的成本

API 配額: 自行托管——取決於你的基礎設施容量
每次呼叫 Token 數: 閘道器額外增加約 50ms 延遲與少量 schema 負載
費用: 開源軟體（Apache 2.0）；費用由基礎設施與後端服務產生
提示: 伺服器數量少於 10 台時，從 SQLite 後端開始即可；只有在需要多節點高可用性時才遷移至 Redis 聯合模式

安全

權限、密鑰、影響範圍

憑證儲存： JWT 簽章金鑰存放於密鑰管理器中；絕對不要放在容器映像檔的環境變數裡

資料出站： 閘道器 → 所有已設定的後端；OTel → 追蹤後端

此為活躍開發中的專案——在 Helm values 中鎖定版本號，並在升級前詳閱版本更新說明

故障排查

常見錯誤與修復

Backend marked unhealthy but works when tested directly

健康檢查使用 HEAD 或 GET /；你的後端可能只回應 POST 請求。請針對每個後端設定 health_check.path。

JWT validation fails

確認 iss 與 aud 聲明與閘道器設定相符，並驗證 JWKS 端點可從閘道器 Pod 正常連線。

Rate limit too aggressive during spikes

從固定時間窗口策略改為 token-bucket 策略；將 burst 設為平均值的 5 倍。

Admin UI login loops

OIDC 提供者中的重新導向 URI 必須與閘道器外部 URL 的 /auth/callback 完全一致——確認已設定為正確的公開主機名稱。

替代方案

IBM Context Forge 對比其他方案

替代方案	何時用它替代	權衡
Kong / Apigee + custom plugins	你已在使用這些工具，想要擴充現有閘道器而非另行新增	需要開發外掛程式；MCP 並非原生支援
mcp-use server namespace	個人開發者使用情境——直接在用戶端串接多個 MCP 即可	沒有集中治理；適合個人，不適合組織
Cloudflare AI Gateway	你想使用 SaaS 托管的閘道器，而非自行托管	MCP 專屬功能較少；主要聚焦於 LLM 流量

IBM Context Forge

為什麼要用

核心特性

即時演示

實際使用效果

安裝

選擇你的客戶端

使用場景

實戰用法： IBM Context Forge

將 10 台以上的 MCP 伺服器集中在單一閘道器後方

前置條件

步驟

注意事項

無需撰寫伺服器程式，將 REST API 虛擬化為 MCP

前置條件

步驟

注意事項

為組織內所有 MCP 呼叫新增追蹤與分析

前置條件

步驟

注意事項

組合

與其他 MCP 搭配，撬動十倍槓桿

工具

此 MCP 暴露的能力

成本與限制

運行它的成本

安全

權限、密鑰、影響範圍

故障排查

常見錯誤與修復

替代方案

IBM Context Forge 對比其他方案

更多

資源