MoEngage用AgentCore Gateway将约400个私有API转为AI工具，称节省约6个月工程量
MoEngage与AWS联合撰文介绍，其约400个内部REST API跨越7个AWS区域，通过Amazon Bedrock AgentCore Gateway生成MCP工具，并用Cedar策略按调用者裁剪可见工具，全程不暴露公网端点。MoEngage称系统已在生产运行三个月，估算节省约六个月平台工程工作量。
AI解读：MoEngage将约400个内部REST API注册到Amazon Bedrock AgentCore Gateway，由网关根据OpenAPI规范生成MCP工具并路由调用，产品团队不需要编写MCP服务器代码。
系统要求所有内部API保持VPC私有、无公网端点；网关入站仅通过VPC接口端点访问，出站经AgentCore托管出口通过Amazon VPC Lattice到达内部服务。
调用者身份（租户、用户、角色、数据库上下文）由客户端库转为X-MOE-*请求头，模型不可见也不可设置；每个代理使用独立IAM角色，由Cedar策略在工具列表序列化前决定其能看到和调用哪些工具。
MoEngage估算，若每个团队各自建MCP服务器，将超过20个部署需要维护；采用统一网关后，新增API只需在现有OpenAPI规范中加注解并跑CI，耗时从数天降为小时级。
为控制上下文占用，网关提供语义搜索能力，MoEngage客户端库只向模型暴露一个search_tools元工具，按任务描述返回候选工具，避免把约400个工具定义（按每工具约50 token计超过2万token）全部送入上下文。
MoEngage称架构已运行三个月，服务10个内部代理，覆盖活动质检、送达健康监控和分群构建等场景；AgentCore功能可用区域因区域而异。以上效果数字与节省估算均为MoEngage方面说法。
MoEngage与AWS联合发布文章，介绍其如何用Amazon Bedrock AgentCore Gateway把约400个内部REST API转成权限受控的AI代理工具。文章作者包括MoEngage的Nikhil Kumar和Shakir Khan。
MoEngage称其平台被超过1350个消费品牌用于推送、邮件、应用内消息、短信、WhatsApp和RCS等渠道的个性化触达；这些内部API由25个工程团队构建，运行在7个AWS区域的私有VPC中，出于数据驻留承诺按区域隔离，且不暴露于公网。
文章称该方案已在生产运行三个月，网关向10个内部代理提供约400个已注册API操作，没有产品团队编写MCP服务器代码，也没有为代理集成单独配置网络。
为什么不给每个团队各建一个MCP服务器
MoEngage评估了让每个工程团队各自暴露MCP服务器的直接做法，并予以否决。文章给出的理由是：超过20个MCP服务器意味着超过20个部署需要监控、打补丁，并随MCP协议演进保持兼容；跨域代理需要连接多个服务器并做结果合并；每个团队还得掌握与其产品工作无关的MCP知识。
由此确立的分工原则是：各工程团队只构建REST API，并声明哪些操作应成为工具；AI平台团队端到端拥有MCP层。团队的责任止于一份描述良好的OpenAPI规范。
- 文章称若自建统一MCP服务器，仍需自行实现工具生成流水线、策略文件格式、工具别名注册表和熔断器。
- MoEngage设定四项必须同时满足的约束：无公网端点；身份不能由模型决定；约400个工具的定义不能全部塞进上下文窗口；不能为每个新API重建网络。
网关如何对应四项约束
AgentCore Gateway是托管的MCP服务器：注册OpenAPI规范作为目标，网关据此生成MCP工具并把调用路由到后端服务。每个操作生成名为Target___operationId的工具，例如CampaignsAPI___searchCampaigns；规范变更时工具随之变更，无需部署或与AI平台团队协调。
权限方面，网关的策略引擎在工具列表被序列化之前做部分求值，按调用主体过滤tools/list。每个代理以自己的IAM角色认证，Cedar策略决定它能看见和调用哪些工具。文章举例，一个活动质检机器人获得活动和分群工具的读权限，但看不到写操作工具，因为那些工具根本不会被发送。
网络方面，网关通过AgentCore托管出口经Amazon VPC Lattice到达MoEngage内部服务；入站只能通过带私有DNS的VPC接口端点访问。新增API只需增加一个目标，不需要改动网络拓扑，这解决了乘以7个区域的问题。
- 身份随请求头传递：租户、用户、角色和数据库上下文由客户端库从Identity对象转换为X-MOE-*请求头，模型看不到也设置不了。
- MoEngage对内部网关选择SigV4签名而非JWT，因为代理是已有IAM角色的服务；其面向Claude等人类认证会话的独立公共MCP服务器则在AgentCore运行时上使用OIDC JWT。
- 由于SigV4占用Authorization头，调用方转发的持有者令牌改由MoEngage前缀的专用请求头传递，且请求头传播设有上限。
- 列出和搜索工具不带租户身份，只有tools/call带身份，文章称这使发现成本低且审计记录清晰。
用语义搜索控制上下文占用
文章估算，按每个工具约50个token的JSON schema计算，一次性列出全部约400个工具会超过2万token，且发生在代理做任何有用事情之前；客户端过滤（如ADK或MCP SDK中的tool_filter）不能解决这个问题，因为完整目录已经传输过来，且按客户端约定过滤不构成授权边界。
MoEngage的做法是客户端库只向模型暴露一个search_tools元工具：模型描述需求，网关的语义搜索返回候选工具，只有这些候选在当轮对话中变为可调用。文章称这还降低了重命名带来的脆弱性，因为匹配基于描述而非标识符。
- AgentCore Gateway提供x_amz_bedrock_agentcore_search能力，代理可按任务描述查找工具，而无需记住工具名。
接入新API的流程与已运行情况
团队在现有OpenAPI规范中增加x-moe-mcp块即可将操作暴露为工具：是否暴露为显式选择加入，没有该块的端点不会成为工具；internal和external标志可分别控制面向内部代理或公共MCP服务器。文章特别指出，工具描述不是API描述，直接复用面向开发者的API描述会导致工具选择效果不佳，因此提供tool_description和param_overrides字段单独撰写面向模型的文本。
CI流水线负责校验x-moe-mcp块、向AgentCore Gateway注册目标并应用Cedar策略，无需人工步骤或向AI平台团队提工单。文章称一个从未接触过MCP的团队也能在一次流水线运行的时间内把操作变成代理工具。
文章称当前部署覆盖7个AWS区域，服务10个内部代理，包括活动质检、送达健康监控和分群构建；MoEngage估算该方案节省约六个月工程工作量，新增API接入从数天网络配置和安全审查变为数小时的规范注解。文章注明AgentCore功能可用性因区域而异。
- 客户端库有两种模式：插件模式把网关MCP服务器包装为LangChain、Google ADK或兼容MCP框架的工具提供者；代理运行器模式为不想采用框架的团队提供完整代理循环。
- 以上节省估算、接入耗时和运行效果均为MoEngage方面的说法，文章未给出独立的第三方验证或量化业务结果。