跳到主要内容

MCP 网关

随着 MCP 的流行，已经有很多的 MCP 服务器可供使用。这些 MCP 服务器可以使用 stdio 方式在本地启动，也可以使用 HTTP 方式连接到远程服务器。在使用时，只需要根据 MCP 客户端的要求，配置 MCP 服务器的连接方式即可。配置方式基本是相似的。

下面的 JSON 内容展示了 MCP 服务器的常见配置方式。其中包含了一个使用 stdio 和一个使用 HTTP SSE 的服务器。

MCP 服务器的配置方式
{
  "mcpServers": {
    "local-stdio-server": {
      "command": "/path/to/my-mcp-server",
      "args": ["--option", "value"],
      "env": {
        "MY_ENV_VAR": "some_value"
      }
    },
    "remote-http-sse": {
      "url": "https://my-mcp-server.example.com/sse",
      "additionalHeaders": {
        "Authorization": "Bearer YOUR_API_TOKEN"
      }
    }
  }
}

应用的 MCP 客户端与多个 MCP 服务器建立一对一的连接。实际的连接方式如下图所示。

这种连接方式存在一些问题。这些 MCP 服务器的配置由应用自行维护，无法统一管理。比如，stdio 服务器的新版本中可能增加新的启动参数，或者 HTTP 服务器的URL增加了新的查询参数。客户端需要手动更新 MCP 服务器的配置来应用这些修改。

对于这种由分散式管理所带来的问题，通常的解决方案是增加一个管理中心。类似的问题也出现在开放 API 的使用中。API 网关解决了这些问题，提供了单一的访问入口，以及非常多的附加功能。在 MCP 的使用场景中，MCP 网关也可以解决同样的问题。实际上，对于使用 HTTP 传输方式的 MCP 服务器来说，MCP 网关本质上也是 API 网关。只不过，MCP 有提示模板、资源和工具这样的特定实体，有特殊的处理方式。

使用了 MCP 网关之后，应用的 MCP 客户端连接到 MCP 网关，MCP 网关连接到实际的 MCP 服务器。客户端的配置简化了很多，只需要 MCP 网关的连接配置即可。网关可以提供 MCP 服务器的集中管理，包括 MCP 服务器的添加和删除，工具的过滤，服务器和工具的权限控制等。

换个角度来说，客户端所连接的是一个虚拟的 MCP 服务器。该服务器所包含的提示模板、资源和工具，由网关从多个MCP服务器聚合而来。网关可以采用不同的聚合策略，既可以简单地聚合全部 MCP 服务器的工具，也可以根据用户的权限来控制工具的可见性。

下图是 MCP 网关的连接方式。

MCP 网关有很多实际的使用场景。比如，某个 MCP 服务器可能包含一些存在安全风险的工具，接入到网关之后，可以在网关上禁用这些工具，使得它们不出现在工具列表中，客户端无法使用。又比如下面的场景，文件服务器在不同的目录下保存了共享的文件。可以在文件服务器上，启动多个使用 stdio 的 MCP 文件服务器，再使用 MCP 代理转换为 HTTP 传输方式，最后接入到 MCP 网关。在网关层次，可以根据用户的权限，限制对这些 MCP 服务器的访问，从而限制用户所能访问的文件目录。

下图是该使用场景的连接方式。

如果只是简单的聚合多个 MCP 服务器，当 MCP 服务器的数量增大时，所包含的工具数量也会增大。直接把这些工具全部提供给大模型，由大模型来选择，会影响大模型选择工具的效果。如何为特定的任务找到最合适的工具，就成了一个需要考量的问题。

这里介绍几种可供参考的方案。Nacos 的 MCP router 提供了一个路由模式。在这个模式下，MCP router 作为一个 MCP 服务器，提供了3个工具。search_mcp_server 工具的作用是，根据任务描述及关键字搜索 MCP 服务器。服务器的信息保存在向量数据库 Chroma 中。可以基于关键词和语义进行搜索。对于搜索到的 MCP服务器，使用工具 add_mcp_server 来安装这些 MCP 服务器。use_tool 工具的作用是调用 MCP 服务器上的工具。

还有一种方案是每个 Agent 或应用的场景，创建其独有的虚拟 MCP 服务器。这个虚拟 MCP服务器聚合不同的MCP服务器和其中的工具。聚合的方式，可以手动选择，也可以根据规则来选择。MCP 服务器和工具，可以是动态的，但是并不会根据发送给大模型的提示而有所不同。举例来说，编写代码的 Agent 和进行代码审核的 Agent，它们所使用的工具是不同的，但是也会存在一些相似之处。在 MCP 网关上，可以创建与这两个 Agent 所对应的虚拟 MCP 服务器，配置给这两个 Agent 使用。

在下面的图中，MCP 网关上管理了3个 MCP服务器，分别是GitHub、代码执行和 Playwright。在编写代码时，会用到代码执行和 Playwright 这两个 MCP 服务器。在审核代码时，会用到代码执行和 GitHub 这两个 MCP 服务器。在 MCP网关上，为两个 Agent 创建了各自的虚拟 MCP 服务器，Agent 只需要连接到对应的 MCP 服务器即可。这两个虚拟 MCP服务器所实际聚合的 MCP服务器，可以根据需要进行调整。Agent 的配置不需要修改。

目前已经有很多 MCP 网关的实现。这里介绍几个开源的选项。

Docker MCP Gateway，最大的优势在于与 Docker 深度集成。使用Docker来运行 MCP 服务器，解决了MCP 服务器部署的问题。该网关提供了一个 MCP 服务器的目录。可以安装 MCP 服务器到网关中。Docker MCP 网关使用的是简单的聚合策略。网关上 MCP 服务器的添加或删除，都会影响网关对外提供的工具。

IBM 的 ContextForge，功能强大，提供了很多企业级的功能，包括管理界面，部署，可观测性支持等。

Octelium 是一个零信任（zero trust）资源访问工具，目标是替换 VPN。MCP 网关只是它提供的一个子功能。服务器端使用的是 AGPLv3 协议，可能并不适合在企业内部使用。

除了这几个新创建的项目之外，一些 API 网关提供者也在往 AI 和 MCP 方向上靠拢。比如开源的 API 网关 Kong，就提供了新的 AI 网关功能，其中也包括 MCP 网关。Kong 的实现方式是依靠已有的插件体系，推出了与大模型和 MCP 相关的插件。

标签：
最后于 更新