虚拟 MCP 服务器：安全聚合多个工具源

TL;DR：虚拟 MCP server 会把多个真实 MCP server 中的工具组合起来，形成一个经过筛选的 server，供你的应用连接。你可以只选择安全的工具，排除具有破坏性的工具，并将它们作为一个远程 MCP server 统一暴露，无需额外部署。借助这种方式，你可以让 Agent 访问 GitHub 和 Slack，却不必同时把 delete_project 交给它。

当 Agent 开始调用真实工具时，访问权限问题很快就会变得尖锐。Model Context Protocol（MCP）非常适合将 AI Agent 连接到数据源或一组工具，但未经处理的 MCP server 通常只能“全给或全不给”。一旦把 Agent 连接到 GitHub MCP server，它就能看到该 server 暴露的所有工具，包括删除分支和关闭 pull request 的工具。虚拟 MCP server 可以解决这个问题：你可以从一个或多个底层 server 中挑选部分工具，经过筛选后再提供给 Agent，而不需要新建和部署任何服务。

本指南将介绍什么是虚拟 MCP server、它如何工作、工具命名如何处理，以及它在更完整的 MCP gateway 中处于什么位置。

什么是虚拟 MCP server？

虚拟 MCP server 会把多个 MCP server 中的工具组合起来，形成一个经过筛选的 MCP server，供你的应用连接。你不再需要让 Agent 直接连接每个后端 server，而是可以精确挑选它应当拥有的工具，再把这组工具作为一个 server 发布。

TrueFoundry 文档中的示例很好地说明了这一点。假设你已经在 gateway 上注册了 GitHub 和 Slack 的 MCP server。某个开发 Agent 的团队需要同时访问这两个 server，但你不希望暴露 delete_project 或 delete_pr 之类的工具。通过虚拟 MCP server，你可以创建一个新的 server，只从 GitHub 和 Slack 中选取安全的工具子集。这个新 server 和其他远程 MCP server 一样可以直接访问，而且不需要单独部署，由 gateway 负责管理。

它带来的实际收益，是让 Agent 遵循最小权限原则。你可以在工具层级决定 Agent 能操作什么，而不是只能在整个 server 层级做选择。

虚拟 MCP server 很适合以下场景：

• Agent 需要使用多个后端中的工具，但不需要其中的全部工具。

• 你希望在 Agent 看到工具之前，就移除具有破坏性或高风险的工具。

• 不同团队或应用需要使用同一批底层 server 的不同工具子集。

• 你希望限定工具访问范围，又不想部署或维护专门的代理 server。

虚拟 MCP server 如何工作

只要底层 server 已经注册到 MCP gateway，整个流程就非常直接。

1. 注册真实的 MCP server。把你希望从中选取工具的后端连接到 gateway，例如 GitHub 和 Slack。

2. 选择安全工具。从这些 server 中挑选 Agent 应当拥有的工具子集，排除任何具有破坏性或超出任务范围的工具。

3. 发布虚拟 server。gateway 会把你选择的工具作为一个虚拟 MCP server 统一暴露。由于它由 gateway 托管，因此不需要单独运行或扩缩容任何部署。

4. 连接应用。通过 streamable HTTP，让你的 Agent 或 MCP client 像连接其他远程 MCP server 一样连接这个虚拟 server。

从 Agent 的角度看，它面对的只是一个干净的 server，里面包含一组合理的工具。所有筛选工作都在 gateway 上完成。

工具名称如何处理

当你把多个 server 中的工具合并到同一个虚拟 server 时，工具重名是一个现实问题。例如，两个后端可能都暴露了 create_issue。TrueFoundry 的处理方式是保留每个工具的原始名称，再附加一段简短的随机后缀，因此 create_issue 会变成类似 create_issue_a1b2c3 的名称。这个后缀可以确保虚拟 server 中的每个工具都有唯一名称。

值得说明的是，为什么采用这种方式，而不是加上 server 名称作为前缀，例如 github-create_issue。MCP spec 建议把工具名称控制在 64 个字符以内，而较长的 server 名称可能会占掉大部分字符预算。由于工具名称是 LLM 判断应当调用哪个工具时最重要的信号，完整保留原始名称并添加简短后缀，既能让名称保持明确含义，也能避免冲突。

虚拟 MCP server 与原始 MCP server

两者并不是竞争关系。虚拟 MCP server 构建在真实 server 之上，为它们增加了一层治理能力。

虚拟 MCP server 在 MCP gateway 中的位置

虚拟 MCP server 只是更大任务中的一项功能：让企业 Agent 在受到治理的前提下访问工具。单独采用 MCP 往往容易失控扩散。每位开发者都会在 Cursor、VS Code 或 Claude Code 中自行配置 server 连接，凭证散落在不同机器上，安全团队也无法知道调用了哪些工具、调用者又是谁。

MCP gateway 可以把这些能力集中起来。TrueFoundry MCP Gateway 为 AI Agent 提供了访问多个 MCP server 的统一入口，同时具备以下能力，让虚拟 server 更适合在生产环境中使用：

• 标准 OAuth 流程。Agent 和开发者通过标准的 OAuth 2LO 和 3LO 流程向企业 MCP server 进行身份验证，不必为每个工具分别配置临时拼凑的密钥。

• 受治理的工具级访问。访问控制由中心统一执行，这让虚拟 server 中经过筛选的工具子集真正具备实际意义，而不只是表面上的整理。

• 工具调用前后的 guardrail。你可以在工具调用前后执行检查，以落实相关策略，因此经过筛选的工具集也可以同时受到 guardrail 保护。

• 完整的审计记录与指标。每一次工具调用都清晰可见，包括每个 server 和每个工具的请求速率、延迟、失败情况及使用模式。

• 更多构建 server 的方式。除了筛选现有 server，gateway 还可以把 OpenAPI spec 转换成 MCP 工具，并将 CLI 风格的 stdio server 作为托管 endpoint 运行。

如果你需要把自定义凭证传递给虚拟 server 背后的后端，gateway 支持使用 x-tfy-mcp-headers header，把各个 server 对应的 header 转发给底层 MCP server。还需要注意目前的一项限制：当前的虚拟 MCP server 支持列出和调用工具；如果你依赖 MCP 的其他功能，就需要围绕这一限制进行规划。

何时使用虚拟 MCP server

当工具访问权限需要精细限定，而不是全量开放时，就适合使用虚拟 MCP server。常见场景包括：

• 最小权限 Agent。只向 Agent 提供完成任务所需的工具，不提供任何可能造成破坏的工具。

• 针对团队或应用的工具集。基于相同的后端，为不同使用方发布不同的精选 server。

• 多租户工具目录。为不同租户提供经过筛选、可被发现的工具集，同时不暴露原始 server。

面向 LLM 应用的 TrueFoundry MCP Gateway：虚拟 server 背后的产品背景

TrueFoundry MCP Gateway 概览（文档）：注册、身份验证与治理

虚拟 MCP Server（文档）：本文所述功能的参考资料

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。