按产品分类浏览文章 关于本站

Kiro 使用 AgentCore Web Search Tool 替代 EXA Search 的配置 - AgentCore Gateway 配置 CUSTOM_JWT 认证

本文介绍 Kiro IDE、Kiro CLI 及 Claude Code 通过 MCP(Model Context Protocol)协议集成 Amazon Bedrock AgentCore Web Search Tool 的方法,以替代 EXA Search 等第三方联网搜索 MCP 服务。针对开发者本机没有 AWS IAM User Access Key 与 Secret Key 的场景,本文将 AgentCore Gateway 配置为 CUSTOM_JWT 入站认证,以 Amazon Cognito 作为身份提供商,并采用 OAuth 2.0 Authorization Code + PKCE 完成浏览器登录认证。同时,本文引入 mcp-remote 作为本地 stdio 与远程 MCP 服务之间的桥接程序,由多个 AI 开发工具共享本机 OAuth 认证状态,解决 Kiro IDE 与 Kiro CLI 同时运行时争用固定回调端口的问题。该方案不在 mcp.json 中保存 AWS 访问密钥、Cognito Client Secret 或固定 Bearer Token,在保留自动刷新 Token 能力的同时,降低本机长期凭据泄露风险。

内容更新:使用 mcp-remote 解决本机 Kiro CLI/IDE 同时登陆时候造成的回调端口 38123 监听冲突问题。

一、背景

很多开发工具包括 Claude Code、Codex、Kiro、乃至 Amazon Quick 通常使用 EXA Search 等第三方搜索服务商作为 Agent 工具的搜索引擎,使用 MCP 协议将 EXA Search 挂载到常用 AI 开发工具。在 Bedrock AgentCore Web Search Tool 发布后,不再需要 AWS 之外的第三方搜索工具了,用户可为自己的 AI 开发工具集成 Bedrock AgentCore Web Search Tool 替换 EXA Search 等第三方搜索工具。这样做的好处是,整个数据流在 AWS 平台上完全闭环,数据不出 AWS,无须为引入别的供应商而重新评估数据安全边界。

本文介绍 AI 开发工具以 MCP 协议集成 Bedrock AgentCore Web Search Tool 的方法,主要操作配置复杂点在于 Bedrock AgentCore 上配置 MCP Server 的认证方案。本文的操作对象为 Kiro CLI/IDE,需要将其升级到 2026-07 之后最新版本;Kiro IDE 的 MCP 面板在 2026-07 年时候的 1.x 版本也可能正常工作。

二、Bedrock AgentCore Gateway 的认证方案选择

1、Bedrock AgentCore Gateway 支持的认证方式

Bedrock AgentCore Web Search Tool 搜索功能自身不是直接作为网络服务被调用的,而是集成在 Bedrock AgentCore Gateway 这个网关上,Agent 工具以 MCP 协议调用 AgentCore Gateway 网关后获得 Web Search Tool,这是唯一的调用方式。因此 AI 开发工具 Claude Code、Codex、Kiro、乃至 Amazon Quick,都需要以 MCP 协议连接到 AgentCore Gateway。

AgentCore Gateway 网关支持如下几种认证:

  • IAM 身份认证:即 AWS_IAM。调用方使用 AWS IAM 身份的凭证,请求需带 SigV4 签名。Gateway 会校验调用方是否具备 bedrock-agentcore:InvokeGateway 权限。
  • CUSTOM_JWT 令牌认证。使用 OIDC 认证方式,由外部身份提供商(如 Amazon Cognito、Okta、Auth0 等支持 OIDC 的提供商)签发 JWT,即 JSON Web Token,与 AgentCore Gateway 完成认证。
  • Offloaded(授权下放)类型,Gateway 本身不做鉴权决策,共两种子类型:
    • Authenticate only(AUTHENTICATE_ONLY):Gateway 仍会校验调用方的 SigV4 签名以确认身份,但不做任何授权判断,任何签名有效的 IAM 主体都会被转发到 Target,授权逻辑需要下游 Target 或附加的策略引擎(Policy Engine)来完成。
    • No Authorization(NONE):Gateway 对入站请求不做任何鉴权,请求可以是完全未认证的。

以上几种身份认证类型做小结:方式 1 适合在 AWS 云上服务之间调用,因为访问者具备 AWS IAM 身份;方式 2 适合第三方 SaaS 对接中的调用,OAuth 可扩展到各种规模的互联网应用;方式 3 适合网关托管的下级服务自己有认证机制的场景,此处不建议完全开放匿名访问方式。

2、AgentCore Gateway 不使用 IAM 认证的考量

在上一篇博客中介绍了使用 Strands Agents 开发一个 Agent,调用 AgentCore Web Search Tool,整个工作链条都是基于 AWS 云服务,因此选择 IAM 身份认证作为 AgentCore Gateway 的决策就非常合理。

针对开发者本机的 AI 开发工具,使用 IAM 认证方式有所不足。AI 开发工具运行在开发者本机,开发者不一定有 AWS IAM User 对应的 Access Key & Secret Key。通常在大型企业中有着严格的安全管理机制,且 DevOps 自动化部署和运维会限制云端特定环境才有 IAM User 和 Access Key & Secret Key,这在大量开发者桌面电脑上是不具备的。因此,如果一定要使用,那么需要定义特定权限的 IAM Policy、只提供最低用户权限,此外还要求 AI 开发工具客户端能支持 IAM 身份验证。

基于以上原因,在普通开发者本机的 AI 开发工具需要调用 Web Search Tool 时候,可以不选择 IAM 认证方式,而是将 AgentCore Gateway 配置为 JWT 认证,其认证过程不依赖于 AWS IAM User 账号体系。

3、为 AgentCore Gateway 选择 CUSTOM_JWT 认证方式

AgentCore Gateway 在使用 CUSTOM_JWT 认证场景时,根据 OAuth 2.0 协议的定义,Kiro 是 OAuth Client,AgentCore Gateway 是 Resource Server,此时还需要有身份认证提供商作为 Authorization Server。这里使用 AWS 云上的 Amazon Cognito 认证服务,或者第三方的 SSO 服务如 Okta 等支持 OIDC 认证的服务来承担这一角色。整套方案中,作为 MCP 调用客户端的 Kiro 的 mcp.json 配置文件中,是完全不写入任何认证密钥的,因此这是与 EXA Search 等 SaaS 形式搜索服务商配置逻辑完全不同的。

Kiro CLI 是运行在开发者本机的 CLI 工具,属于 OAuth 规范中的"公有客户端(Public Client)",Secret 写在本机配置文件里等同于没有保密性,所以是属于无法安全保存 Client Secret 的客户端类型。因此,在安全最佳实践上,使用 PKCE(Proof Key for Code Exchange)机制来提供一次性授权和密钥交换机制,防止认证过程中的密钥被截获。Kiro 原生支持 OAuth 认证方式中的 PKCE 认证。以 Amazon Cognito 作为认证服务为例,采用 OAuth 2.0 的 Authorization Code(授权码)+ PKCE 跳转认证,即 Kiro 客户端发起认证给出认证 URL,用户打开系统浏览器跳转到 Cognito 登录页,输入用户名、密码完成登录后换取短期 Token 通过 Gateway 的认证。

此方案中的 mcp.json 仅写入认证 URL 和 client_id 字段,第一次使用时候需要使用浏览器登录完成认证。认证通过后的 Token 过期时候,由 Refresh Token 自动静默续期,因此后续无需维护 mcp.json 配置文件。

4、不支持完全写死静态密钥的配置方式的说明

JWT 体系下还有一种面向机器对机器(M2M)的 Client Credentials 授权方式,可以用 Client ID 加 Client Secret 直接换取 Bearer Token 并硬编码到 mcp.json 配置文件中,这能省去浏览器登录环节。这种使用体验,非常接近在使用 EXA Search 等搜索服务商时候配置 mcp.json 的体验,在配置文件里边可以硬编码访问密钥。但是,在本方案下 Token 存在有效期限制,无法写“死”,也就是无法做到长期不更换。

这是因为 AgentCore Gateway 使用的 Bearer Access Token 不是永久凭据,而是 Cognito 签发出来的临时凭据,签发 Access Token 有效期限默认是 3600 秒(1小时),最长有效期为 24 小时。由于不能签发长期密钥,这意味着 MCP 客户端调用方需要频繁进行认证。

此外,客户端和服务器端都不支持自动获取/刷新 Token:

  • 作为服务器端的 Amazon Cognito 的 Client Credentials 流程不发放 Refresh Token,因此没有自动更新机制用于 Token Renew。
  • 作为客户端的 Kiro 不会自动执行 Client Credentials Grant,无法自动获取新 Token。

所以除非是写一个 Shell 脚本,自动生成新 Token,自动修改 mcp.json 配置文件,否则没有办法实现把 Token 写“死”,也就是无法做到长期不更换。

5、最终方案推荐

综上所述,没有办法像 EXA Search 等第三方 MCP 一样在 mcp.json 配置文件中使用写死 Token 的方式。当然,在配置文件中硬编码长期 Token 也存在安全隐患。因此最终给出的使用场景建议是:

  • 如果是云上应用环境/生产环境嵌入 APP 中:使用 AWS IAM 认证,分配 Access Key & Secret Key。
  • 开发者客户端的 AI 开发工具:使用 JWT 认证,配置认证服务,用户跳转到浏览器完成认证,后续能自动 Renew。

本文即讲解后者场景下的配置。第三章和第四章是 AWS 管理员配置 Cognito 为 AgentCore 提供 JWT 认证,第五章讲解最终用户如何挂载 MCP。

三、配置 Amazon Cognito 认证服务(需要 AWS 管理员权限)

注意:本章节需要 AWS 管理员权限,并且安装 AWS CLI 工具,创建并设置好 Access Key/Secret Key,以便于快速部署。

1、设置脚本需要的所有环境变量

本章创建 Kiro 认证所需的全部 Cognito 资源:用户池、Hosted UI 域名、应用客户端与测试用户。如果之前创建过使用 IAM 认证方式的 Bedrock AgentCore Gateway,这里会重新创建一个新的。

以下管理员配置中均需要这些变量。区域固定为 us-east-1。注意:截止本文编写时候,Web Search Tool 目前仅在该区域可用。所以 Cognito 服务也需要创建在这一区域。

REGION="us-east-1"
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
ROLE_NAME="AgentCoreWebSearchKiroGatewayRole"
GATEWAY_NAME="websearch-kiro-jwt-gateway"
USER_POOL_NAME="websearch-kiro-pool"
COGNITO_DOMAIN_PREFIX="websearch-kiro-${ACCOUNT_ID}"

2、创建 Cognito 用户池

USER_POOL_ID=$(aws cognito-idp create-user-pool \
  --pool-name "$USER_POOL_NAME" \
  --region "$REGION" \
  --query 'UserPool.Id' --output text)
echo "USER_POOL_ID=$USER_POOL_ID"

返回结果类似如下(形如 us-east-1_xxxxxxxxx):

USER_POOL_ID=us-east-1_o2qx89QGH

3、创建 Cognito 认证服务入口

现在创建 Cognito 认证服务的入口。

Cognito 对外提供认证的门户网页有两个版本,版本 1 无需额外配置即可直接使用;若使用新版 Managed Login(版本 2),必须先为应用客户端创建 branding style,否则浏览器打开登录页时无法渲染。为简化测试过程,下文的命令中显式指定 --managed-login-version 1,即使用经典 Hosted UI 版本的登录页。

此外,域名前缀需要在 Cognito 命名空间内全局唯一,因此在前一章节处理环境变量的时候,这里用账号 ID 拼接实现唯一 ID,避免名称冲突。

aws cognito-idp create-user-pool-domain \
  --domain "$COGNITO_DOMAIN_PREFIX" \
  --user-pool-id "$USER_POOL_ID" \
  --managed-login-version 1 \
  --region "$REGION"

命令执行成功后回显所设置的托管登录版本:

{
    "ManagedLoginVersion": 1
}

域名创建后需要 3-5 分钟才能生效,最终形成的 Hosted UI 根地址可用如下命令打印出来:

echo https://${COGNITO_DOMAIN_PREFIX}.auth.${REGION}.amazoncognito.com

4、创建应用客户端与用户

(1) 创建应用客户端

Kiro 在认证时会在本机 localhost 上启动回调监听服务,为了规避端口冲突,这里建议使用不常见的端口,例如这里修改为 38123 端口。

CLIENT_ID=$(aws cognito-idp create-user-pool-client \
  --user-pool-id "$USER_POOL_ID" \
  --client-name "kiro-websearch-authcode-client" \
  --no-generate-secret \
  --allowed-o-auth-flows code \
  --allowed-o-auth-scopes openid \
  --allowed-o-auth-flows-user-pool-client \
  --callback-urls "http://localhost:38123/oauth/callback" "http://localhost:38123/callback" "http://localhost:38123" \
  --supported-identity-providers COGNITO \
  --prevent-user-existence-errors ENABLED \
  --region "$REGION" \
  --query 'UserPoolClient.ClientId' --output text)
echo "CLIENT_ID=$CLIENT_ID"

创建成功后返回 client_id 信息类似如下:

CLIENT_ID=xxxxxxxxxxxxxxxxxx

这个 client_id 不是针对某一个用户的,而是挂接在 Cognito 服务上的应用客户端的 ID,因此需要与用户登录时候的用户名/密码区分开。

(2) 创建用户

用管理员身份创建一个用户并设置永久密码:

TEST_USERNAME="user01"
TEST_PASSWORD="<自定义一个满足密码策略的强密码>"

aws cognito-idp admin-create-user \
  --user-pool-id "$USER_POOL_ID" \
  --username "$TEST_USERNAME" \
  --user-attributes Name=email,Value="kiro-tester@example.com" Name=email_verified,Value=true \
  --message-action SUPPRESS \
  --region "$REGION"

aws cognito-idp admin-set-user-password \
  --user-pool-id "$USER_POOL_ID" \
  --username "$TEST_USERNAME" \
  --password "$TEST_PASSWORD" \
  --permanent \
  --region "$REGION"

5、汇总创建好的资源名称以便于后续配置

以下信息在下一步以管理员身份配置 AgentCore 时候将会用到:

名称 用途
User Pool ID $USER_POOL_ID(形如 us-east-1_xxxxxxxxx 管理员配置 AgentCore Gateway 的 JWT Authorizer
Discovery URL https://cognito-idp.${REGION}.amazonaws.com/${USER_POOL_ID}/.well-known/openid-configuration 管理员配置 AgentCore Gateway 的 JWT Authorizer
Hosted UI 域名 https://${COGNITO_DOMAIN_PREFIX}.auth.${REGION}.amazoncognito.com 管理员配置 AgentCore 浏览器跳转登录与令牌兑换

以下信息在最终用户以 MCP 协议挂载时将会用到,注意保存:

名称 用途
Client ID $CLIENT_ID 最终用户以 MCP 协议挂载时使用的 oauth.clientId
测试用户 user01 及其密码 最终用户以 MCP 协议挂载时使用的浏览器登录验证
跳转 URL localhost:38123

至此 Cognito 配置完毕。下面开始 AgentCore Gateway 配置。

四、配置 AgentCore Gateway 与 Web Search Tool(需要 AWS 管理员权限)

注意:本章节的环境变量是继承了第三章的第 1 节的环境变量,继续配置。

1、创建 AgentCore 需要的 IAM Role

Gateway 出站调用 Web Search 后端时,需要代入一个 IAM 服务角色。信任关系仅允许 bedrock-agentcore.amazonaws.com 代入该角色,权限策略仅授予 bedrock-agentcore:InvokeWebSearch,用于调用 Web Search 后端。

补充说明:本文 Gateway 的入站认证采用 CUSTOM_JWT,Kiro 调用 Gateway 时由 JWT Authorizer 完成认证,因此 AgentCore 服务认证不依赖 IAM,所以 Gateway 服务角色中不需要授予 bedrock-agentcore:InvokeGateway

执行如下命令创建 IAM 角色,写入信任策略,允许 bedrock-agentcore 服务代入该角色:

aws iam create-role \
  --role-name "$ROLE_NAME" \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"bedrock-agentcore.amazonaws.com"},"Action":"sts:AssumeRole"}]}' \
  --description "AgentCore Web Search demo gateway service role (for Kiro JWT auth)"

为该角色写入权限策略,仅授予调用 Web Search 后端所需权限。其中 Web Search Tool 的资源 ARN 由 AWS 拥有,account 段固定为 aws

aws iam put-role-policy \
  --role-name "$ROLE_NAME" \
  --policy-name "WebSearchInvokePolicy" \
  --policy-document "{
    \"Version\": \"2012-10-17\",
    \"Statement\": [
      {
        \"Sid\": \"InvokeWebSearch\",
        \"Effect\": \"Allow\",
        \"Action\": \"bedrock-agentcore:InvokeWebSearch\",
        \"Resource\": \"arn:aws:bedrock-agentcore:${REGION}:aws:tool/web-search.v1\"
      }
    ]
  }"

新建的 IAM 角色需要数秒钟才能完全生效,建议等待 1 分钟左右后再创建 Gateway,以降低 PassRole 校验失败的概率。

2、创建认证为 CUSTOM_JWT 类型的 AgentCore Gateway

Gateway 的 JWT Authorizer 指向第三章用户池的 Discovery URL,并同时配置 allowedClientsallowedScopesallowedClients 填入第三章创建的 Cognito 应用客户端 ID,仅允许该应用客户端下的用户通过 Gateway 校验;即使同一个 Cognito User Pool 用户池日后新增其他应用客户端,其 Token 也不能访问本 Gateway。

ROLE_ARN=$(aws iam get-role --role-name "$ROLE_NAME" --query Role.Arn --output text)
DISCOVERY_URL="https://cognito-idp.${REGION}.amazonaws.com/${USER_POOL_ID}/.well-known/openid-configuration"

aws bedrock-agentcore-control create-gateway \
  --name "$GATEWAY_NAME" \
  --role-arn "$ROLE_ARN" \
  --protocol-type MCP \
  --authorizer-type CUSTOM_JWT \
  --authorizer-configuration "{
    \"customJWTAuthorizer\": {
      \"discoveryUrl\": \"${DISCOVERY_URL}\",
      \"allowedClients\": [\"${CLIENT_ID}\"],
      \"allowedScopes\": [\"openid\"]
    }
  }" \
  --description "Web Search demo gateway for Kiro integration (CUSTOM_JWT inbound auth)" \
  --region "$REGION"

获取 Gateway ID 与状态,等待 status 变为 READY

GATEWAY_ID=$(aws bedrock-agentcore-control list-gateways \
  --region "$REGION" \
  --query "items[?name=='${GATEWAY_NAME}'].gatewayId | [0]" \
  --output text)

aws bedrock-agentcore-control get-gateway \
  --gateway-identifier "$GATEWAY_ID" \
  --region "$REGION" \
  --query '{status:status, gatewayUrl:gatewayUrl}'

返回结果类似如下:

{
    "status": "READY",
    "gatewayUrl": "https://websearch-kiro-jwt-gateway-aechsb1ccn.gateway.bedrock-agentcore.us-east-1.amazonaws.com/mcp"
}

3、挂载 Web Search Tool

注意:本步骤要求 AWS CLI 版本不低于 2.35.19,否则不支持 Web Search 连接器参数。

Web Search Tool 创建时候可以写入 MCP Tool 的描述信息,便于 Agent 发现 Tool 的能力并在适当的场合使用这个 Tool。以下命令中写入了一段中文描述信息,可按需自行修改。

aws bedrock-agentcore-control create-gateway-target \
  --gateway-identifier "$GATEWAY_ID" \
  --name "web-search" \
  --target-configuration '{"mcp":{"connector":{"source":{"connectorId":"web-search"},"configurations":[{"name":"WebSearch","description":"在互联网上检索当前的公开网页信息,返回标题、URL、发布日期与摘要片段,适用于回答实时事件、最新版本号、价格等训练数据之外的问题。","parameterValues":{}}]}}}' \
  --credential-provider-configurations '[{"credentialProviderType":"GATEWAY_IAM_ROLE"}]' \
  --region "$REGION" \
  --query targetId --output text

配置完成后,Kiro 执行 /mcp 或调用工具时能看到这段描述文本。命令执行成功后返回目标 ID,形如:

VP1YHEVFU5

查询目标状态,等待其变为 READY

aws bedrock-agentcore-control list-gateway-targets \
  --gateway-identifier "$GATEWAY_ID" \
  --region "$REGION" \
  --query "items[?name=='web-search'].{targetId:targetId, status:status}"

返回结果如下:

[
    {
        "targetId": "VP1YHEVFU5",
        "status": "READY"
    }
]

当显示 READY 即表示 Web Search 目标已可用。

4、汇总本章需要记录的值

名称 Kiro mcp.json 字段
Cognito Client ID $CLIENT_ID oauth.clientId
Gateway URL get-gateway 返回的 gatewayUrl url

至此配置完成。AgentCore Gateway 本身处于空闲状态不产生额外费用,实际计费发生在调用 Web Search 目标检索时。

下面开始 Kiro 用户的 MCP 配置。

五、最终用户使用 mcp-remote 配置 MCP(开发者本机无须 AWS IAM/Access Key & Secret Key)

本章使用 mcp-remote 统一代理 Kiro IDE、Kiro CLI 或 Claude Code 的 OAuth 认证状态,避免多个客户端争用 Cognito 预先登记的固定回调端口。

1、Kiro 原生 OAuth 方式的端口冲突

Kiro IDE 与 Kiro CLI 原生连接远程 MCP Server 时,各自维护 OAuth 状态并启动本机回调监听器。本文在 Cognito App Client 中预先登记了 http://localhost:38123/oauth/callback,因此两个客户端不能通过随机端口规避冲突。原生方式的问题链路如下:

Kiro IDE
  ├── 独立 OAuth 状态
  └── localhost:38123 回调监听

Kiro CLI
  ├── 独立 OAuth 状态
  └── 也尝试监听 localhost:38123
               端口冲突

mcp-remote 是一个本地 MCP 桥接程序:面向 Kiro 暴露 stdio MCP Server,再通过远程 Streamable HTTP 连接 AgentCore Gateway。不同客户端启动的 mcp-remote 实例共享 ~/.mcp-auth 中的 OAuth Token,因此只需要一个实例完成浏览器登录,其他实例可以复用已经取得的 Token。换成 mcp-remote 后的链路如下:

Kiro IDE ──stdio──> mcp-remote 实例 A ─┐
                                      ├── ~/.mcp-auth 共享 Token
Kiro CLI ──stdio──> mcp-remote 实例 B ─┘
                         └── Bearer Token → AgentCore Gateway

mcp-remote 仍然使用第三章配置的 Authorization Code + PKCE 流程,没有改变 Gateway 的 CUSTOM_JWT 入站认证类型,也不需要 AWS AKSK 或 Cognito Client Secret。--static-oauth-client-info 中的“static”表示使用预先注册的 Cognito Client ID,而不是使用静态 Token。Token 过期后由 mcp-remote 使用 Refresh Token 自动续期。

注意:mcp-remote 0.8.6 使用 ~/.mcp-auth/mcp-remote-v1 保存当前认证状态。该目录中的 Token 文件属于敏感凭据,应保持仅当前用户可读写,不要提交到代码仓库。旧版本遗留的 ~/.mcp-auth/mcp-remote-0.x.y 目录不会作为新版的长期共享存储使用。

2、安装最新版本的 mcp-remote

mcp-remote 通过 npm 发布,要求本机 Node.js 版本不低于 18。先查询 npm Registry 当前标记为 latest 的版本:

npm view mcp-remote version

本文在 2026 年 9 月 10 日查询到的版本如下:

0.8.6

为了保证安装过程可复现,使用查询到的固定版本号安装,而不是直接在配置文件中使用会持续变化的 @latest

npm install -g mcp-remote@0.8.6

本机实际返回结果如下:

added 1 package, and changed 81 packages in 3s

查询全局安装结果和可执行文件路径:

npm list -g --depth=0 mcp-remote
command -v mcp-remote

本机返回结果如下:

/opt/homebrew/lib
└── mcp-remote@0.8.6

/opt/homebrew/bin/mcp-remote

后续配置中的 command 应使用 command -v mcp-remote 返回的真实路径。使用绝对路径可以避免 Kiro IDE 进程的 PATH 与交互式终端不一致。

3、使用 mcp-remote 配置 Kiro

~/.kiro/settings/mcp.json 中新增 agentcore-gateway。将 Gateway URL、Cognito Client ID 和 mcp-remote 路径替换为前文记录的真实值:

{
  "mcpServers": {
    "agentcore-gateway": {
      "command": "<command -v mcp-remote 返回的路径>",
      "args": [
        "<第四章创建的 Gateway URL>",
        "38123",
        "--use-id-token",
        "--static-oauth-client-info",
        "{\"client_id\":\"<第三章创建的 CLIENT_ID>\"}",
        "--static-oauth-client-metadata",
        "{\"scope\":\"openid\",\"token_endpoint_auth_method\":\"none\"}"
      ],
      "env": {},
      "disabled": false
    }
  }
}

代入本文示例值后的配置如下:

{
  "mcpServers": {
    "agentcore-gateway": {
      "command": "/opt/homebrew/bin/mcp-remote",
      "args": [
        "https://websearch-kiro-jwt-gateway-aechsb1ccn.gateway.bedrock-agentcore.us-east-1.amazonaws.com/mcp",
        "38123",
        "--use-id-token",
        "--static-oauth-client-info",
        "{\"client_id\":\"38d1ierl6pv39i2kv6f41eg8t9\"}",
        "--static-oauth-client-metadata",
        "{\"scope\":\"openid\",\"token_endpoint_auth_method\":\"none\"}"
      ],
      "env": {},
      "disabled": false
    }
  }
}

--use-id-tokenmcp-remote 0.8.6 对 Cognito 与 AgentCore Gateway 的兼容参数。它要求代理向 Gateway 发送 OIDC ID Token,而 Refresh Token 和自动续期流程保持不变。由于 ID Token 只在请求包含 openid scope 时签发,因此配置中同时通过 --static-oauth-client-metadata 明确设置 openid

配置中不建议使用 autoApprove: ["*"]。目前 Gateway 只挂载 Web Search Tool,但如果将来增加带写操作的 Target,通配符会使新工具也被自动批准。

4、完成首次登录并验证 Kiro CLI

保存配置并重新启动 Kiro CLI。mcp-remote 第一次连接时会自动打开系统浏览器,进入 Cognito Hosted UI。实际授权 URL 形如:

https://websearch-kiro-<ACCOUNT_ID>.auth.us-east-1.amazoncognito.com/oauth2/authorize?response_type=code&client_id=<CLIENT_ID>&redirect_uri=http%3A%2F%2Flocalhost%3A38123%2Foauth%2Fcallback&scope=openid&code_challenge=<PKCE_CHALLENGE>&code_challenge_method=S256&state=<随机状态值>

使用第三章创建的测试用户登录后,浏览器回调本机地址:

http://localhost:38123/oauth/callback?code=<一次性授权码>&state=<随机状态值>

认证完成后,在 Kiro CLI 中执行 /mcp

/mcp

确认 agentcore-gateway 显示为已连接,并能发现 web-search 工具。然后输入一个需要实时资料的问题,确认 Kiro 能通过 AgentCore Gateway 调用 Web Search Tool。

5、验证 Kiro IDE 与 Kiro CLI 同时使用

保持 Kiro CLI 运行,再启动 Kiro IDE。Kiro IDE 会启动另一个 mcp-remote 进程,但会复用 ~/.mcp-auth/mcp-remote-v1 中已有的认证状态,通常不需要再次输入 Cognito 用户名和密码。

分别在 Kiro CLI 与 Kiro IDE 中查看 MCP Server 状态,并各执行一次联网检索。两端均能调用 Web Search Tool,即表示共享认证状态生效。认证完成后还可以检查 38123 端口:

lsof -nP -iTCP:38123 -sTCP:LISTEN

没有返回结果表示 OAuth 回调服务已经关闭。该端口只在需要首次认证或重新认证时临时监听,不会在正常工具调用期间持续占用。

如果需要切换账号或修复失效认证,应先退出全部使用该 Gateway 的 MCP 客户端,再备份并清理对应的 ~/.mcp-auth/mcp-remote-v1 认证文件。删除认证文件会使所有共享该状态的客户端退出登录,不应在其他客户端仍在调用时执行。

6、Claude Code 配置示例

Claude Code 也可以通过同一个 mcp-remote 连接 Gateway,从而与 Kiro IDE、Kiro CLI 共享认证状态。配置示例如下:

{
  "mcpServers": {
    "agentcore-gateway": {
      "command": "/opt/homebrew/bin/mcp-remote",
      "args": [
        "<第四章创建的 Gateway URL>",
        "38123",
        "--use-id-token",
        "--static-oauth-client-info",
        "{\"client_id\":\"<第三章创建的 CLIENT_ID>\"}",
        "--static-oauth-client-metadata",
        "{\"scope\":\"openid\",\"token_endpoint_auth_method\":\"none\"}"
      ]
    }
  }
}

重新启动 Claude Code 后执行 /mcp,确认 agentcore-gateway 已连接。只要 Gateway URL、OAuth Client 信息和认证缓存目录一致,Claude Code 启动的 mcp-remote 就可以复用已有 Token,无须再占用 38123 端口重复登录。

六、参考文档

mcp-remote 项目与配置说明

mcp-remote npm 软件包

Bedrock AgentCore Gateway 入站认证配置说明

Bedrock AgentCore CUSTOM_JWT Authorizer 字段说明

Amazon Cognito CreateUserPoolClient API 参考

Kiro CLI MCP 配置文档

Kiro CLI Agent 配置参考(OAuth 配置字段)

七、删除实验相关资源(不含 Kiro)

本章删除第三章和第四章创建的 AWS 云端资源,不修改或删除开发者本机的 Kiro 配置。删除操作不可逆,Cognito User Pool 删除后,其中的应用客户端和测试用户也会被永久删除。执行前需要确认这些资源没有被其他应用复用。

删除时必须遵循以下依赖顺序:

AgentCore Gateway Target
AgentCore Gateway
Gateway 专用 IAM Role

Cognito 托管域名
Cognito User Pool(同时删除 App Client 与测试用户)

1、设置资源名称

重新设置本文使用的区域和资源名称:

REGION="us-east-1"
ROLE_NAME="AgentCoreWebSearchKiroGatewayRole"
GATEWAY_NAME="websearch-kiro-jwt-gateway"
USER_POOL_NAME="websearch-kiro-pool"

2、删除 AgentCore Gateway Target 和 Gateway

先按名称查询 Gateway ID:

GATEWAY_ID=$(aws bedrock-agentcore-control list-gateways \
  --region "$REGION" \
  --query "items[?name=='${GATEWAY_NAME}'].gatewayId | [0]" \
  --output text)
echo "GATEWAY_ID=$GATEWAY_ID"

如果 Gateway 存在,删除该专用 Gateway 下的全部 Target,等待 Target 删除完成后再删除 Gateway:

if [[ -n "$GATEWAY_ID" && "$GATEWAY_ID" != "None" ]]; then
  TARGET_IDS=$(aws bedrock-agentcore-control list-gateway-targets \
    --gateway-identifier "$GATEWAY_ID" \
    --region "$REGION" \
    --query 'items[].targetId' \
    --output text)

  if [[ -n "$TARGET_IDS" && "$TARGET_IDS" != "None" ]]; then
    for TARGET_ID in $TARGET_IDS; do
      aws bedrock-agentcore-control delete-gateway-target \
        --gateway-identifier "$GATEWAY_ID" \
        --target-id "$TARGET_ID" \
        --region "$REGION"
    done

    while [[ "$(aws bedrock-agentcore-control list-gateway-targets \
      --gateway-identifier "$GATEWAY_ID" \
      --region "$REGION" \
      --query 'length(items)' \
      --output text)" != "0" ]]; do
      sleep 3
    done
  fi

  aws bedrock-agentcore-control delete-gateway \
    --gateway-identifier "$GATEWAY_ID" \
    --region "$REGION"

  while [[ "$(aws bedrock-agentcore-control list-gateways \
    --region "$REGION" \
    --query "length(items[?gatewayId=='${GATEWAY_ID}'])" \
    --output text)" != "0" ]]; do
    sleep 3
  done
fi

删除请求返回的状态通常为 DELETING。循环结束且按 ID 查询数量为 0 后,表示 Target 和 Gateway 已删除。

3、删除 Gateway 专用 IAM Role

本文创建的 IAM Role 仅供该 Gateway 使用。先删除内联策略,再删除角色:

if aws iam get-role --role-name "$ROLE_NAME" >/dev/null 2>&1; then
  if aws iam get-role-policy \
    --role-name "$ROLE_NAME" \
    --policy-name "WebSearchInvokePolicy" >/dev/null 2>&1; then
    aws iam delete-role-policy \
      --role-name "$ROLE_NAME" \
      --policy-name "WebSearchInvokePolicy"
  fi

  aws iam delete-role --role-name "$ROLE_NAME"
fi

注意:如果自行向该角色附加了其他内联策略或托管策略,必须先逐一删除内联策略并解除托管策略关联,否则 delete-role 会失败。不要删除已被其他工作负载复用的 IAM Role。

4、删除 Cognito 托管域名和 User Pool

按名称查询 User Pool ID。删除 User Pool 前,先读取并删除其 Cognito 托管域名:

USER_POOL_ID=$(aws cognito-idp list-user-pools \
  --max-results 60 \
  --region "$REGION" \
  --query "UserPools[?Name=='${USER_POOL_NAME}'].Id | [0]" \
  --output text)
echo "USER_POOL_ID=$USER_POOL_ID"

if [[ -n "$USER_POOL_ID" && "$USER_POOL_ID" != "None" ]]; then
  COGNITO_DOMAIN=$(aws cognito-idp describe-user-pool \
    --user-pool-id "$USER_POOL_ID" \
    --region "$REGION" \
    --query 'UserPool.Domain' \
    --output text)

  if [[ -n "$COGNITO_DOMAIN" && "$COGNITO_DOMAIN" != "None" ]]; then
    aws cognito-idp delete-user-pool-domain \
      --domain "$COGNITO_DOMAIN" \
      --user-pool-id "$USER_POOL_ID" \
      --region "$REGION"
  fi

  aws cognito-idp delete-user-pool \
    --user-pool-id "$USER_POOL_ID" \
    --region "$REGION"
fi

删除 User Pool 会同时删除其中的 kiro-websearch-authcode-client 应用客户端和 user01 测试用户,无须分别执行删除命令。

5、验证资源已删除

分别按名称查询 Gateway、User Pool 和 IAM Role:

aws bedrock-agentcore-control list-gateways \
  --region "$REGION" \
  --query "items[?name=='${GATEWAY_NAME}'].{name:name,gatewayId:gatewayId}" \
  --output json

aws cognito-idp list-user-pools \
  --max-results 60 \
  --region "$REGION" \
  --query "UserPools[?Name=='${USER_POOL_NAME}'].{Name:Name,Id:Id}" \
  --output json

aws iam list-roles \
  --query "Roles[?RoleName=='${ROLE_NAME}'].{RoleName:RoleName,Arn:Arn}" \
  --output json

三条命令均应返回空数组:

[]

至此,第三章和第四章创建的 AWS 云端实验资源已全部删除,本机 Kiro 配置不受影响。


最后修改于 2026-07-16