面向所有内部 API 的单一 MCP Gateway：聚合模式

文章讨论企业规模下 MCP 集成的架构问题：单服务对应单个 MCP server 已较成熟，但中型平台团队往往有数十个服务，各自有独立 spec、认证和 staging/production 主机。若每个团队各自发布 MCP 端点，会导致 Agent 需配置大量 URL 和 OAuth 授权、工具目录超出多数客户端暴露给模型的上限而静默消失、list_users 与 create_order 等工具名冲突，且缺少统一的限流、审计日志和撤销入口。作者提出的方案是 MCP gateway：Agent 只对一个端点认证，由 gateway 将多个后端 API 聚合为带命名空间、可治理的工具目录，并统一处理 OAuth 2.1 授权与令牌。

AI推荐理由 文章提出在企业规模下用单一 MCP gateway 聚合多个内部 API 的架构模式，具体指出多端点带来的问题：Agent 需配置数十个 URL 和 OAuth 授权、工具目录超出客户端上限导致工具静默消失、list_users/create_order 等命名冲突、缺乏统一限流与审计撤销点。这些是开发者在多服务场景落地 MCP 时的实际工程约束，对 Agent 工具集成有参考价值；但内容为个人博客的架构建议，未提供实测数据或生产验证，属经验性方案而非已验证结论。