IBM Context Forge MCP — 使用场景, 安装 & 实时演示

Name: IBM Context Forge MCP Server
Author: IBM

为什么要用

核心特性

在一个端点后面聚合多个 MCP 服务器
自动将 REST 和 gRPC API 翻译为 MCP 工具
内置 JWT / OAuth / Basic 认证、限流、重试
OpenTelemetry 追踪（Phoenix、Jaeger、Zipkin）+ 管理 UI

实时演示

实际使用效果

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 图表可用
一个认证提供者（或使用内置 JWT） — 现有 SSO / OIDC / 静态 JWT 签名器

步骤

部署网关

通过 Helm 部署 mcp-contextforge-gateway，使用 Redis 存储联合状态。指向我们的 OIDC 提供者。✓ 已复制

→ 管理 UI 加载成功，认证工作正常
注册后端

在管理 UI 中注册 3 个后端 MCP（github、postgres、our-custom）。应用限流：github=100/分钟，postgres=30/分钟。✓ 已复制

→ 后端在注册表中显示为健康
重新指向客户端

更新同事的 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。你想要 MCP 访问而无需编写 fastapi-mcp 或 FastMCP 代码。

前置条件

API 的 OpenAPI / Swagger 规范 — 通常是 /openapi.json 或 /swagger.json

步骤

上传 OpenAPI 规范

在 ContextForge 管理界面中，注册一个新的 REST 后端。上传 OpenAPI 规范。确认工具自动生成捕获了所有端点。✓ 已复制

→ 工具列表与路由列表匹配
配置认证通过

设置头部转发，使 Authorization 头从 MCP 客户端流向上游 REST API。✓ 已复制

→ 认证路由端到端工作
过滤暴露的表面

通过路径模式排除内部/管理路由。在 3 个最常用的工具上添加描述覆盖。✓ 已复制

→ 清晰的、代理友好的工具列表

结果： REST 即 MCP，无需新的服务代码——一个 OpenAPI 规范就足够了。

注意事项

自动生成的工具名字很糟 — 在 OpenAPI 规范中设置显式的 operationId，或在 ContextForge 中按路由覆盖名称

为整个组织的所有 MCP 调用添加追踪和分析

👤 SRE / 平台可观测性负责人 ⏱ ~90 min advanced

何时使用： 你想回答'代理今天做了什么？'跨越使用 MCP 的每个团队。

前置条件

一个 OTel 后端（Phoenix、Jaeger、Grafana Tempo） — 接受 OTLP 的运行中端点

步骤

启用 OTel 导出

配置网关的 otel.endpoint 指向我们的 Phoenix 实例。在 span 中包含工具名称、延迟、用户、结果。✓ 已复制

→ Span 在调用后几秒内出现在 Phoenix 中
构建仪表板

创建仪表板：按调用量排名前 10 的工具、每个后端的 p95 延迟、每个用户的错误率。✓ 已复制

→ 仪表板已填充
异常告警

告警条件：任何后端的错误率 >5%，或单个用户每小时消耗 >10k 次调用。✓ 已复制

→ 测试告警在测试环境中触发

结果： 组织范围的 MCP 可见性——你知道谁使用了什么以及何时它会出问题。

注意事项

OTel span 基数会因为按请求 ID 作为 span 名称而爆炸 — 将 span 名称保持为工具名称；将请求 ID 放在属性中，而不是名称中

搭配使用： sentry

组合

与其他 MCP 搭配，撬动十倍杠杆

mcp-context-forge + cloud-run

在 Cloud Run 上部署 ContextForge，将 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 + 最小的模式开销
费用: 开源（Apache 2.0）；你为基础设施和后端付费
提示: 对于 <10 个服务器，使用 SQLite 后端开始；仅在需要多节点 HA 时才迁移到 Redis 联合

安全

权限、密钥、影响范围

凭据存储： JWT 签名密钥存储在密钥管理器中；从不在容器镜像的环境变量中

数据出站： 网关 → 所有配置的后端；OTel → 追踪后端

活跃项目——在 Helm 值中固定版本，在升级前查看发布说明

故障排查

常见错误与修复

后端被标记为不健康，但直接测试时工作正常

健康检查使用 HEAD 或 GET /；你的后端可能只响应 POST。为每个后端配置 health_check.path。

JWT 验证失败

检查 iss 和 aud 声明是否与网关配置匹配。还要验证 JWKS 端点是否可从网关 pod 访问。

在峰值期间限流过于激进

从固定窗口切换到令牌桶策略；设置 burst=5× 平均值。

管理 UI 登录循环

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

前置条件

步骤

注意事项

前置条件

步骤

注意事项

前置条件

步骤

注意事项

组合

与其他 MCP 搭配，撬动十倍杠杆

工具

此 MCP 暴露的能力

成本与限制

运行它的成本

安全

权限、密钥、影响范围

故障排查

常见错误与修复

替代方案

IBM Context Forge 对比其他方案

更多

资源