推出 Virtual MCP Server：多MCP工作流的统一网关
Source: Dev.to
问题：连接过载
想象一下：你是平台团队的工程师。你的 AI 助手需要访问 GitHub（代码）、Jira（工单）、Slack（通知）、PagerDuty（事件）、Datadog（指标）、AWS（基础设施）、Confluence（文档）以及内部知识库。这是 8 条独立的 MCP 服务器连接，每条连接又暴露 10‑20+ 个工具。现在 AI 的上下文窗口被 80+ 个工具描述塞满，消耗大量 token，导致性能下降，因为大模型在一长串工具中挑选合适的工具时力不从心。
每条 MCP 服务器连接都需要：
- 在 AI 客户端中单独配置
- 单独的身份验证凭证
- 当任务跨多个系统时需要手动协调
- 重复输入参数（相同的仓库、相同的频道、相同的数据库）
- 为避免上下文膨胀和 token 浪费而进行工具过滤
想要调查一次生产事故？你需要手动在 4 个不同的系统上运行命令并自行拼凑结果。部署应用？你要编排一系列操作：合并 PR、等待 CI、获取批准、部署、通知团队。过程繁琐、易出错且不可复用。
解决方案：统一聚合
vMCP 将这 8 条连接合并为一条。你只需配置一个聚合所有后端服务器的 MCP 端点。
vMCP 之前：
{
"servers": {
"github": { "url": "..." },
"jira": { "url": "..." },
"slack": { "url": "..." },
"pagerduty": { "url": "..." },
"datadog": { "url": "..." },
"aws": { "url": "..." },
"confluence": { "url": "..." },
"docs": { "url": "..." }
}
}使用 vMCP：
{
"servers": {
"company-tools": {
"url": "http://vmcp.company.com/mcp"
}
}
}一条连接。一次身份验证。所有工具均可使用。
你可以根据需要运行任意数量的 vMCP 实例。前端团队连接到带有其特定工具的 vMCP；平台团队连接到另一个带有基础设施访问的 vMCP。每个 vMCP 只聚合该团队所需的后端，并配以相应的安全策略和权限。这提升了安全性（不再让所有人访问所有资源），也提升了效率（工具更少，上下文窗口更小，token 成本更低，AI 性能更佳）。
vMCP 的功能
vMCP 是 ToolHive Kubernetes Operator 的一部分。它充当智能聚合层，位于 AI 客户端与后端 MCP 服务器之间。
1. 多服务器聚合与工具过滤
所有 MCP 工具通过单一端点呈现，但你可以精准挑选要暴露的工具。
- 示例：ToolHive 团队的工程师获得一个 vMCP 连接，包含：
- GitHub 的
search_code工具（仅限stacklok/toolhive仓库） - ToolHive 文档 MCP 服务器
- 连接到 Google Drive 并过滤至 ToolHive 设计文档的内部文档服务器
- Slack（仅
#toolhive-team频道）
- GitHub 的
无关工具不会占用 LLM 的上下文，也不会在未使用的工具描述上浪费 token。
当多个 MCP 服务器拥有同名工具（例如 GitHub 与 Jira 都有 create_issue）时，vMCP 会自动加前缀（github_create_issue、jira_create_issue），并可根据需要自定义名称。
2. 声明式多系统工作流
真实任务往往需要跨多个系统协同。vMCP 让你定义确定性的工作流，支持并行执行、条件分支、错误处理和审批门。
事故调查工作流
→ 从日志系统查询日志
→ 从监控平台获取指标
→ 从追踪服务拉取追踪数据
→ 从云提供商检查基础设施状态
→ 手动将所有信息合并成报告
→ 使用 Jira 创建包含调查结果的工单vMCP 并行运行查询，聚合数据并创建工单。工作流只需定义一次，即可在每次事故中复用。
应用部署工作流
→ 在 GitHub 合并 Pull Request
→ 等待 CI 测试通过
→ 请求人工审批（使用 MCP 询问）
→ 部署（仅在获批后执行）
→ 在 Slack 中通知团队3. 预配置默认值与安全护栏
停止重复输入相同参数。只需在 vMCP 中配置一次默认值。
- 之前：每次 GitHub 查询都必须指定
repo: stacklok/toolhive - 之后：仓库已预配置，防止误查询到错误的仓库。
预配置参数可确保行为确定、提升安全性并在所有用户之间保持一致。
4. 工具自定义与安全策略
第三方 MCP 服务器常常暴露通用、无限制的工具。vMCP 允许在不修改上游服务器的前提下对其进行包装和限制。
- 安全策略执行 – 将网站抓取工具限制为仅内部域名（
*.company.com），在调用后端前验证 URL，并在违规时提供明确的错误信息。 - 简化接口 – 包装一个拥有 20+ 参数的复杂 AWS EC2 工具，只暴露前端团队需要的三个参数，并为其余参数提供安全默认值。
5. 集中式身份验证
vMCP 实现了双边界身份验证模型，并提供完整审计日志。你的 AI 客户端使用官方 MCP 规范中定义的 OAuth 2.1 方法一次性登录 vMCP，随后 vMCP 根据各后端的需求独立处理授权。
当需要撤销访问权限时，只需在身份提供商中禁用用户，所有后端的访问即被即时撤销。
实际收益
没有 vMCP 时
- 4 条顺序手动命令
- 每条命令 2‑3 分钟
- 汇总与格式化 5‑10 分钟
- 每次事故总计 15‑20 分钟
- 结果因工程师而异，流程未记录也不可复用
使用 vMCP 时
- 一条命令触发整个工作流
- 并行执行约 30 秒
- 自动汇总与格式化
- 每次结果一致
- 工作流以代码形式记录，任何团队成员均可使用
对于每周处理 20 起事故的团队而言，时间节省约为每周 5 小时，同时降低 token 成本并提升事故响应的可靠性。