MCP

MCP Gateway 用前指南：把多个 MCP 服务器与 REST API 聚合成固定工具表面（非商业许可）

最适合被多个 MCP 服务器和 REST API 的工具定义撑满上下文的场景：单个 Rust 二进制把所有后端聚合成 14 到 16 个固定元工具，用 gateway_search_tools 搜索、gateway_invoke 调用；使用前最重要的前提是默认许可仅覆盖个人与非商业用途，商业运行需要商业许可。

官方来源 · GitHub - MikkoParkkola/mcp-gateway

安装

brew install MikkoParkkola/tap/mcp-gateway   # 1. install
mcp-gateway setup wizard --configure-client   # 2. import existing servers + wire up clients
mcp-gateway serve                            # 3. run

如果你把多个 MCP 服务器和 REST API 接进同一个 AI 客户端，很快会发现工具定义本身就把上下文撑满了。MCP Gateway 的做法是在客户端与所有工具之间放一个单个 Rust 二进制：各种后端都挂在它后面，agent 看到的是 14 到 16 个工具的紧凑元表面，而不是每个后端的完整定义。上下文里的工具定义越多，留给真正任务的预算就越少；把它收敛成一个固定的小表面，正是它要解决的问题。动手前先确认一个前提：它默认采用非商业许可（非商业用途许可），个人与非商业用途（包括运行完整网关）免费，商业运行需要商业许可。

适合谁

  • 适合已经接入或计划接入多个 MCP 服务器与 REST API、希望工具列表体积保持稳定的用户：不管后面挂多少后端，agent 面对的都是固定的一小组元工具，而不是所有后端定义的总和。
  • 适合能在本机常驻运行一个服务的人：网关以本地 HTTP 服务方式运行，客户端通过本地端点连接它。
  • 不适合商业环境直接使用：商业运行需要商业许可，这是采用前必须解决的前提；只有少量通用构建块组成的 MIT 核心按 MIT 许可开放。
  • 只有少量后端、工具列表本来就不长时，聚合的价值有限；小规模场景下的具体收益，证据未给出对比数据。
  • 支持的客户端名单、远程部署与身份验证方式，证据未给出，属于未确认项，不要自行假设。

3 分钟完成第一次尝试

  • 前提：一个可用 Homebrew 的环境。官方给出的安装入口是 Homebrew tap，其他安装方式证据未给出。
  • 依次执行官方主路径的三条命令：
brew install MikkoParkkola/tap/mcp-gateway   # 1. install
mcp-gateway setup wizard --configure-client   # 2. import existing servers + wire up clients
mcp-gateway serve                            # 3. run
  • 第二步的 setup wizard 会导入你现有的服务器并把客户端接上。注意这是本地状态写入：它会改写网关与客户端的本地配置，不是只读操作；具体写入哪些文件、如何保存，证据未逐项说明。
  • 第三步启动后，网关作为本地 HTTP 服务运行。客户端侧按官方给出的配置片段连接。片段把名为 gateway 的服务声明为 http 类型，指向本机 39400 端口的 /mcp 路径：
{
  "mcpServers": {
    "gateway": {
      "type": "http",
      "url": "http://localhost:39400/mcp"
    }
  }
}
  • 成功信号：客户端连上 http://localhost:39400/mcp 后，工具列表收敛为固定的一小组；此时调用一次 gateway_search_tools，官方描述它用于搜索后端工具——如果搜索能返回你已接入后端的工具，说明客户端到网关的链路已经打通。证据未标注该工具的 readOnlyHint，其只读属性未确认；第一次尝试只做搜索，不执行写入类动作。这时 agent 加载的是固定的一小组元工具，而不是全部后端定义。

使用案例

  • 案例一：给多服务器工具栈瘦身。场景：客户端已接多个 MCP 服务器，每个后端的工具定义都在消耗上下文。做法：把现有服务器交给向导导入，客户端只保留 http://localhost:39400/mcp 这一个端点。预期：agent 的工具表面固定在 14 到 16 个左右，而不是所有后端定义的总和；需要某个具体能力时，先用 gateway_search_tools 检索定位。判断依据：客户端呈现的工具数量是否明显少于你接入后端的工具总数。
  • 案例二：搜索后调用一次真实工具。场景：想执行某个已连接后端（MCP 服务器或 REST API）提供的能力。做法：先用 gateway_search_tools 定位目标工具，再用 gateway_invoke 调用它，官方描述的用法正是搜索加调用这两个元工具。预期：调用被转发到对应后端并返回其结果；具体输出取决于你接入了什么后端，证据中没有固定示例输出。如果搜索不到预期工具，先确认该后端是否已通过向导导入，再重试搜索。

使用边界

  • 许可与限制：个人与非商业用途免费，包括运行完整网关；商业运行需要商业许可；仅少量通用构建块的 MIT 核心按 MIT 开放。这一条决定能不能用、在什么范围用，放在所有判断之前。
  • 读写性质与副作用：网关本身是本地常驻服务；向导会写本地配置；gateway_invoke 会真实驱动后端工具，副作用取决于所调用的那个后端，执行前先确认目标操作的性质与确认点。
  • 依赖：安装依赖 Homebrew；接入现有服务器通过向导导入完成。
  • 未确认项：支持的客户端名单、REST API 的具体接入配置格式、localhost 之外的部署方式、身份验证机制，以及各元工具是否标注 readOnlyHint，证据中均未说明。网关自身是否有访问控制、日志如何记录，证据同样未说明。未找到说明不等于没有风险，采用前请以官方仓库当前文档为准。