企业已经有数百个API，还要为每个Agent再造一遍工具接口吗？客户互动平台MoEngage在10月29日披露的工程复盘，给出另一条路径：把约400个内部REST API的OpenAPI规格变成工具入口，同时让产品团队继续维护业务接口，平台团队集中管理协议接入与权限。工具目录变大，首先要解决的不是让模型看见更多，而是让它只在正确身份下执行。

快速看点：这是一项具名企业实施复盘，不是AgentCore当天首次发布；API需要显式选择才进入工具目录；语义搜索负责缩小候选，不能充当授权；列得出工具，也不保证具体调用一定获准。

规格共用，但不能把所有接口默认暴露

MoEngage的业务包括活动检查、投递健康分析和用户分群等流程。团队不想为每项服务单独维护一套MCP服务器，转而用AgentCore Gateway把现有API接给Agent。这里复用的是接口规格与注册流程，业务执行本身仍由下游服务承担。

其做法是在OpenAPI中增加自定义的x-moe-mcp区块，明确哪些操作可变成工具，并分别描述内部或外部用途。没有这个区块的接口不被自动纳入。工具说明也不直接照抄API开发文档，而是补充面向模型的用途描述及参数处理。

这些约定属于MoEngage自己的工程流程，不是OpenAPI或MCP的通用自动能力。团队通过持续集成校验规格、注册目标并处理策略；“规格是统一入口”仍需要维护发布管线，不能理解成编辑一个文件后，所有线上Agent会立即安全同步。

搜索回答相关性，策略回答能不能做

工具规模增长后，一次把全部定义塞进模型上下文并不划算。案例用搜索工具先找相关候选，再提供实际需要的定义。这减少了模型面对的选择空间，但搜索结果只说明可能相关，不能证明请求具有业务权限。

AgentCore的Policy文档给出了关键区别：工具列表是一种部分授权判断，没有具体调用的完整参数。只要存在某种获准情形，工具就可能出现在列表；真正执行时，还要按完整请求重新判断。因此，同一个工具可以看得见，却因当前参数或身份条件而调用失败。

实施团队应把这类失败当作正常拒绝路径验收，而不是一概要求模型换个提示词绕过去。目录过滤、调用授权、参数检查与下游业务规则需要各自成立；任何一层放行，都不能代替另外几层。

身份从可信链路来，不让模型自己填写

案例中的内部Agent通过IAM角色和签名请求接入，业务租户、用户及角色等上下文由可信客户端身份链路写入请求头，不由模型在工具参数里任意声明。这把“我要查谁的数据”与“我是谁、获准查谁”分开，后者不能只靠自然语言自证。

Gateway的请求头转发也不是全量透传。当前文档要求按目标配置允许列表，并限制数量、大小和字符范围；Authorization头不能在创建目标时直接加入普通允许列表，受信拦截器提供它时另有处理。接入方应逐项核对自己的认证路径，不能照搬一组头名便宣称身份已经贯通。

网络同样分入口和出口。MoEngage内部API走私有连接，Gateway可借助VPC Lattice访问私有目标；这不表示全部产品都没有公网接口。复盘另列了面向人类客户端的公共MCP入口，使用不同的认证安排，两条访问面需要分别测试和治理。

复制这套设计时，可以先选一项只读活动检查：验证未选择的API不会出现，普通身份看不到不应使用的工具，获准工具遇到越权租户或参数仍被拒绝，再测试凭据过期、目标不可达与规格变更。这里给出的是交付检查方法，并非本站已完成这些测试。

原文中的接入规模和实施过程来自客户与AWS共同署名的材料，本文未获得可复算的效率或成本实验，因此不采用节省数月工程时间等收益说法。也没有接入MoEngage账户、执行活动操作，或验证其全部生产权限。

小编判断

这份复盘的启发，不是“有规格就有安全Agent”，而是把接口所有权、工具发现、可信身份与实际授权分清。企业真正该复用的是这条责任链：产品团队决定业务语义，平台团队治理接入，运行时拒绝越权请求。规模越大，越需要证明不该发生的调用确实不会被执行。