MCP 网关：如何用一个端点管理多个 MCP 服务器

一开始你只有一个 MCP 服务器。然后两个。然后五个。很快，你就要在 Claude Code、Cursor、自定义 Agent 以及接下来采用的任何客户端里维护十几个 MCP 服务器——每个都有自己的配置文件、自己的一份 API Key 副本、自己的运行时进程。加一个服务器，你要改每个客户端；换一次密钥，你还要改每个客户端。

MCP 网关（MCP Gateway） 就是这种蔓延的架构解法。本文讲清楚：MCP 网关到底是什么、它在协议层如何工作、它和代理（Proxy）或注册表（Registry）有什么区别、什么时候值得用，以及 MCP2Skill 如何用工作区、分级端点和调用级可观测性实现这个模式。

什么是 MCP 网关

MCP 网关是一个位于 AI 客户端和 MCP 服务器之间的、符合 MCP 协议的统一端点。 每个客户端不再直接连接每个服务器，而是只连接网关一次；网关负责聚合上游服务器、筛选对外暴露哪些工具、把每次调用路由到真正拥有该工具的服务器，并记录发生了什么。

如果你对协议本身还不熟悉，可以先看 什么是 MCP（Model Context Protocol）——本文默认你已经知道“工具调用”是什么。

网关通常承担五项职责：

为什么“每个客户端各配一份”会崩

一个客户端配两个服务器时，直连是够用的。规模一上来，它会在五个具体的地方退化。

1. 配置重复是 N × M 增长

N 个客户端、M 个服务器，你要维护 N × M 份配置。三个客户端、八个服务器就是 24 段需要手工保持一致的配置。而它们不会保持一致——你会得到配置漂移，表现为某个工具在这个客户端里存在、在那个客户端里悄悄不见了。

2. 进程重复

stdio 服务器是由连接它的一方作为子进程拉起来的。三个客户端使用文件系统 MCP，就意味着三个文件系统 MCP 进程、三套文件句柄、三份内存占用。乘上十几个服务器，你的电脑一整天都在跑冗余基础设施。

3. 密钥散落

每一份直连配置，都是你的 GitHub Token、数据库连接串或厂商 API Key 明文落盘的又一个地方。轮换一次凭据，你得先找齐所有副本；想收回某个客户端的访问权，只能去改那个客户端的文件——没有一个集中的开关。

4. 未经筛选的工具表面

客户端会把它连接的每个服务器的完整工具列表都加载进来。光 GitHub MCP 服务器就暴露了几十个工具。连上四五个服务器，你的上下文窗口里就有很大一块是当前任务永远用不到的工具 Schema——而 Agent 还没开始干活。（这个问题的详细测算见 如何用 Skills 减少 MCP 的 Token 浪费。）

5. 零可观测性

调用失败时，大多数客户端只告诉你“失败了”。是客户端问题、传输问题、服务器问题、OAuth 授权过期，还是工具自身返回的错误？没有集中的请求与响应记录，你只能猜。

MCP 网关是如何工作的

从架构上看，网关对客户端而言是一个 MCP 服务器，对上游而言是一个 MCP 客户端：

  Claude Code  ─┐                                  ┌─► 文件系统 MCP   (stdio，1 个进程)
  Cursor       ─┼─►    MCP 网关端点     ───────────┼─► GitHub MCP     (Streamable HTTP)
  自定义 Agent ─┘   一个 URL + 一个 API Key        └─► 内部 MCP       (SSE + OAuth)
                    一份运行时，一份日志

一次请求会走完这条链路：

1. 连接并声明能力。 客户端打开网关 URL，交换当前请求所需的协议元数据与能力信息。为了兼容旧版 MCP 客户端，网关也可以处理早期规范中的 initialize 握手。
2. 列出工具。 收到 tools/list 时，网关向它前置的每个上游服务器查询，合并结果，去掉你筛掉的部分，返回一份列表。
3. 消解重名。 两个服务器都可以暴露一个叫 search 的工具。MCP 规范并没有为聚合场景定义命名空间——工具 name 只是被要求唯一——所以处理冲突是网关的责任，通常是给工具名加上来源服务的标识前缀。
4. 路由调用。 收到 tools/call 时，网关把（带命名空间的）工具映射回它所属的服务器，附上该服务器的凭据后转发。
5. 转换传输。 上游 stdio 服务器是本地子进程；网关对客户端说 Streamable HTTP，对这些进程说 stdio。正是这层转换，让一个只能本地运行的服务器可以被只会说 HTTP 的客户端使用。
6. 落盘记录。 请求、响应、耗时和错误会先写进网关日志，再把结果返回给客户端。

评估网关时，有两个协议细节值得知道：

• Streamable HTTP 是目前推荐的 HTTP 传输方式，在 2025-03-26 版本中引入。更早的 HTTP+SSE 传输自那时起已被弃用并计划移除，所以一个只对客户端提供旧版 SSE 的网关是个隐患。较新的规范修订也在转向无状态、面向请求的模型，同时保留对旧客户端的兼容指引。
• MCP 中的授权是可选的，且只适用于 HTTP 传输。 启用时它是 OAuth 2.1 的一个子集：服务器通过受保护资源元数据（RFC 9728）声明自己的授权服务器，客户端必须使用 PKCE。而 stdio 服务器的凭据来自环境变量——这恰恰说明，把凭据集中托管在一个网关里，比散落在各个客户端配置文件里更合理。

网关、代理、聚合器、注册表：区别在哪

这四个词经常被混用，但它们并不是一回事。

网关是运行时的控制点，注册表是目录。大多数团队最终两个都要——从注册表里发现服务器，然后放到网关后面运行。

网关跑在哪：三种部署形态

MCP2Skill 是桌面优先的网关：运行时就在你自己的机器上，紧挨着你的本地服务器和密钥；当你确实需要别的机器接入时，再打开可选的远程访问开关。

选 MCP 网关时该看什么

一份实用的对比清单：

1. 两侧的传输覆盖——上游支持 stdio、SSE 和 Streamable HTTP；对客户端提供 Streamable HTTP。
2. 工具级筛选，而不只是服务器级的启用/禁用。
3. 多个分级端点，让同一份安装能给不同客户端呈现不同的工具集。
4. 命名空间，能扛住两个服务器暴露同名工具的情况。
5. 凭据托管，包括远程服务器的 OAuth 授权流程。
6. 网关自身的访问控制——至少要有 API Key，并且对“仅本地监听 vs. 远程可达”有明确的态度。
7. 带请求与响应内容的调用日志，而不只是成功计数。
8. 上游进程的服务日志，让你能区分“服务器崩了”和“调用被拒了”。
9. 配置导入 / 导出，让迁移现有配置不等于重新录入一遍。
10. 对 Token 成本给出答案——筛选有帮助，但要追问：筛完之后列表仍然很大时怎么办。

具体使用场景

三个客户端共用一套配置。 八个 MCP 服务器只配一次，把同一段网关 JSON 分别粘进 Claude Code、Cursor 和你自己的 Agent。以后加第九个服务器是改一处，不是改三处。

按项目划分工具范围。 frontend 端点只暴露浏览器和文件系统工具，data 端点只暴露数仓和 BI 工具。同一份安装，两个工具表面，不用复制服务配置。

对破坏性工具做最小权限。 一个同时暴露 read_file 和 delete_file 的服务器，没必要对所有 Agent 都暴露两个。在自动化 Agent 使用的端点上关掉破坏性工具，在你手动驱动的端点上保留它。

让本地服务器可被复用。 桌面上的 stdio 服务器，只会说 HTTP 的客户端本来用不了；放到网关后面，它就变成了一个 HTTP 端点——开启远程访问并设置 API Key 之后，局域网里的另一台机器也能用。

排查不稳定的服务器。 “工具列表看着没问题，但调用就是失败”这种问题，在客户端那一侧无解。从网关这边，你先在调用日志里找到那次失败的请求，再去服务日志里看那个服务器挂掉时打印了什么。

在进入上下文窗口之前先削减工具表面。 每一个你从端点上筛掉的工具，都是一份永远不会进入模型上下文的 Schema。这是网关对 Token 成本的诚实贡献——它与 Skills 的分工见后文。

MCP2Skill 如何实现网关模式

MCP2Skill 是一个桌面应用：它把你的 MCP 服务器统一运行一次，再通过受管理的端点对外暴露。

服务是能力来源

你可以按 STDIO（命令、参数、环境变量、工作目录）、SSE 或 Streamable HTTP（URL 加自定义请求头）添加服务器，也可以直接导入你已经在用的客户端配置。需要 OAuth 的远程服务会有明确的授权状态——需要授权、授权中、已授权、已过期——所以授权过期是看得见的，而不是表现为一堆莫名其妙的调用失败。

工作区定义边界

工作区把若干 MCP 服务组合在一起，再逐个工具地决定保留哪些。筛选是两层的：一个工具必须同时在服务级别和工作区级别保持启用，客户端才能真正看到它。正因如此，同一个服务可以在一个工作区里暴露较宽的能力、在另一个工作区里只暴露刻意收窄的部分，而不必维护几份几乎相同的服务配置。

三种端点粒度

每个工作区都会生成自己的网关端点，你按场景选粒度：

日常稳定使用应该默认用你自己创建的工作区端点，ALL 是调试工具。详见 工具筛选与工作区端点。

复制端点，或者复制 JSON

在服务或工作区详情页，你可以选择复制原始端点 URL（如果你更愿意自己手写客户端配置），或者复制一段现成的 JSON——里面已经填好服务名称、连接类型、网关 URL 和所需的请求头。如果你启用了 API Key，认证请求头也已经在这段 JSON 里了，这也是优先复制 JSON 的主要理由。客户端侧的完整步骤见 连接外部 AI 客户端。

访问控制集中在一处

设置页统一管理网关端口、远程访问开关，以及 API Key 认证（启用、查看、复制、重新生成）。开启远程访问是一个需要主动做出的决定：只在确实需要非本机客户端接入时才打开，并且同时启用 API Key。重新生成密钥会让已连接客户端里的配置失效，之后记得重新复制 JSON。详见 常规与 MCP 设置。

可观测性是这个边界的附赠品

因为每次调用都经过网关，MCP2Skill 可以呈现：

• 仪表盘 — 已安装服务数、运行中服务数、可用工具数、今日调用次数、成功率、平均响应时间、最近调用记录、活跃热力图、服务负载，以及告诉你流量究竟来自哪个客户端的客户端排行。
• 统计 — 同一幅图景，按时间范围回顾。
• 调用日志 — 哪一次调用失败、什么时候失败、来自哪个服务 / 工作区 / 客户端，以及请求和响应内容。
• 服务日志 — 上游服务器在启动、连接、认证或崩溃时到底打印了什么。

实用的闭环是：改完配置 → 发起一次真实调用 → 回到仪表盘或日志里确认。完整的排查路径见 日志与诊断。

网关路径 vs. Skill 路径

网关解决的是配置、复用和可见性问题。它不改变工具定义何时加载——连到网关的客户端，仍然会一次性拉取（已被筛选过的）整份工具列表。要从结构上砍掉这笔开销，靠的是 Skill 路径：Skill 先只暴露一段简短描述，只有当任务真正匹配时才加载完整指令。Anthropic 自己的代码执行示例里，让 Agent 按需发现工具后，工具定义开销从 15 万 Token 降到 2,000——降幅 98.7%。

MCP2Skill 的默认建议是：如果你的 Agent 支持 Skills，最常用的那批工具就走 Skill 路径，其余的留给网关。从工作区生成的 Skill 仍然调用该工作区的端点，所以你配置的工具筛选在两条路径下都生效——两条路共用同一个边界。决策框架见 MCP vs Skills，转换流程见 如何把任意 MCP 转成 Skill。

五步开始

1. 把你的 MCP 服务器添加到 MCP2Skill（只需一次）——手动添加，或直接导入你在 Claude Code、Cursor 里已有的配置。
2. 创建工作区，把工具收窄到这个场景真正需要的那些。
3. 复制工作区 JSON，粘贴到每个需要标准 MCP 访问的客户端。
4. 先启用 API Key，再打开远程访问。
5. 发起一次真实调用，然后看仪表盘——只要调用记录出现，说明客户端、网关和服务器整条链路是通的。

之后再把调用频次最高的工作流转成 Skills，并实测转换前后的 Token 差异。最终你得到的是：一套配置、每个服务器一份运行时、一个由你亲自决定的工具表面，以及一份记录了 Agent 实际做过什么的日志。

常见问题

什么是 MCP 网关？

MCP 网关是位于 AI 客户端和 MCP 服务器之间的、符合 MCP 协议的统一端点。它把多个服务器聚合成一份工具列表，筛选每个端点暴露哪些工具，托管上游凭据，把每次 tools/call 路由到真正拥有该工具的服务器，并记录每一次调用。客户端只需要配置一个连接，而不是每个服务器配一个。

MCP 网关和 MCP 代理是一回事吗？

不是。代理把流量转发给单个上游服务器，通常用于桥接传输方式或加一层认证；网关聚合多个服务器，并在其上叠加策略层——工具筛选、分级端点、凭据托管和可观测性。聚合器介于两者之间：它合并工具列表，但通常止步于此，不提供按客户端分级和日志能力。

MCP 网关能减少 Token 消耗吗？

只能间接减少。网关让你决定某个端点上存在哪些工具定义，所以把 60 个工具的表面筛到 12 个，就等于从上下文窗口里移走了 48 份 Schema。但留下来的定义仍然是一次性加载的。要改变定义何时加载，需要把 MCP 工具转成 Skills——先暴露简短描述，任务匹配时才加载完整指令，这正是 Anthropic 实测出 98.7% 降幅 背后的机制。

哪些 AI 客户端可以接入 MCP 网关？

任何兼容 MCP 的客户端——Claude Code、Cursor、自定义 Agent，以及其他会说这个协议的工具。网关在它们看来就是一个普通的 MCP 服务器，因此客户端侧不需要任何改造，只要把配置指向网关 URL，并在启用密钥时带上认证请求头即可。

如果两个 MCP 服务器有同名工具会怎样？

MCP 规范把工具的 name 当作唯一标识，并没有为聚合场景定义命名空间，所以消解冲突是网关的职责——通常是给工具名加上来源服务的标识前缀。在 MCP2Skill 中，服务的名称标识会被用作工具命名空间和端点标识，因此建议一开始就选一个稳定的名字，不要随意改动。