Agent Toolkit for AWS dá a Claude Code, Cursor e Kiro acesso guiado à sua conta

Se você já usou Claude Code, Cursor ou Kiro para escrever infraestrutura na AWS, conhece o problema: o agente sabe o que é um bucket do Amazon S3, mas não necessariamente sabe qual é a API atual, qual parâmetro virou obrigatório ou qual serviço novo resolveria o seu caso melhor. O Agent Toolkit for AWS ataca exatamente isso. É um recurso do AWS CLI que instala, com um único comando, um catálogo de conhecimento curado e uma conexão segura via Model Context Protocol (MCP) para o seu agente de código conversar diretamente com a sua conta.

O toolkit é formado por duas peças. A primeira são as AWS skills: arquivos Markdown mantidos pelos próprios times de serviço da AWS, que ensinam ao agente como aquele serviço funciona na prática, incluindo boas práticas de segurança. A segunda é o AWS MCP Server, uma ponte auditável que dá ao agente acesso a milhares de APIs da AWS usando as credenciais do AWS Identity and Access Management (IAM) que você já tem configuradas. Com isso o agente lista recursos reais da sua conta, busca documentação atualizada e chama API de verdade, em vez de alucinar nome de parâmetro.

Pré-requisitos antes de instalar

Você precisa do AWS CLI na versão 2.35.0 ou mais recente. Confira com aws --version e, se estiver desatualizado, siga o guia oficial de instalação do AWS CLI v2. Também precisa de pelo menos um agente de código suportado instalado localmente: Kiro, Claude Code, Codex, Cursor e outros populares entram na lista.

Para saber quais agentes o toolkit enxerga na sua máquina antes mesmo de instalar nada, rode:

aws configure agent-toolkit

Esse mesmo comando dispara o assistente interativo de configuração, detecta os agentes suportados presentes no seu ambiente e deixa você escolher quais configurar.

Instalando e configurando passo a passo

O fluxo é simples porque o assistente faz o trabalho pesado:

1. Rode aws configure agent-toolkit no terminal.
2. Escolha, na lista detectada, quais agentes você quer configurar (por exemplo Claude Code e Cursor, se os dois estiverem instalados).
3. Para cada agente selecionado, o CLI instala um conjunto padrão de skills e configura a conexão com o AWS MCP Server.
4. Abra uma nova sessão de chat no agente: a expertise AWS já está carregada.

Segundo o post do AWS Developer Tools Blog, o processo inteiro costuma levar poucos segundos. Se você está rodando isso num pipeline de integração contínua ou num devcontainer, sem interação humana disponível, use a flag que aceita os padrões sem perguntar nada:

aws configure agent-toolkit --yes

Para ver todas as opções disponíveis, rode aws configure agent-toolkit help.

Ajustando skills conforme o projeto cresce

O conjunto padrão de skills cobre fluxo de trabalho comum, mas seu projeto vai pedir mais cedo ou mais tarde. O exemplo que a AWS usa no próprio post é revelador do problema real: uma aplicação serverless de processamento de documentos que guarda arquivos no Amazon S3 e precisa de busca semântica, implementada com Amazon S3 Vectors, um recurso lançado recentemente. Como é uma capacidade nova, o agente pode não ter orientação atualizada sobre ela por padrão.

Para resolver isso sem esperar uma atualização geral do toolkit, você mesmo busca e instala a skill que falta:

aws agent-toolkit list-installed-skills

Se a skill de vetores não aparecer na lista, procure no catálogo completo:

aws agent-toolkit search-skills --search-query vectors
aws agent-toolkit add-skill --skill-name storing-and-querying-vectors

O search-skills casa a busca com nome e descrição de todas as skills do catálogo. O add-skill baixa a skill e instala em cada agente detectado; use a flag --agent se quiser mirar só um deles, útil quando você usa Claude Code num projeto e Cursor em outro com necessidades diferentes.

Mantendo o catálogo atualizado (ou tirando o que não serve mais)

Skills evoluem junto com os serviços da AWS, então atualizar e remover faz parte da rotina, não é exceção. O mesmo padrão de comando serve para os dois casos:

aws agent-toolkit update-skill aws-cdk
aws agent-toolkit remove-skill aws-cdk

Vale rodar list-installed-skills de vez em quando, principalmente depois de trocar de stack: uma skill de AWS CDK instalada num projeto que migrou para Terraform só ocupa espaço de contexto do agente sem ajudar em nada.

O ponto de atenção que o post não destaca: suas credenciais, sua responsabilidade

Aqui está o detalhe que todo vibe coder precisa internalizar antes de rodar aws configure agent-toolkit: o MCP Server não cria uma permissão nova e mais restrita para o agente. Ele usa exatamente as credenciais IAM que a sua sessão do AWS CLI já tem configuradas. Se o seu profile local tem a política AdministratorAccess, o agente passa a ter, na prática, o mesmo alcance: criar, alterar e apagar recursos em qualquer serviço.

Antes de configurar o toolkit, vale a pena parar e checar com qual identidade você está autenticado:

aws sts get-caller-identity

Se o resultado apontar uma role ou um usuário com permissão ampla, considere criar um profile dedicado para trabalhar com o agente, com uma política IAM escopada aos serviços do projeto em questão. Isso evita o cenário clássico de agente de código que, tentando corrigir um erro de deploy, decide apagar e recriar um bucket inteiro porque tinha s3:* disponível e ninguém tinha restringido a ação.

As skills em si são arquivos Markdown de instrução carregados no contexto do agente, curados pelos times de serviço da AWS, o que reduz (mas não elimina) o risco de orientação ruim. O ponto fraco continua sendo o mesmo de sempre com agente de código na nuvem: a permissão que você concede, não o conhecimento que ele carrega.

O que ainda fica em aberto

O post da AWS não detalha o tamanho total do catálogo de skills nem com que frequência cada uma é revisada pelos times de serviço, então não dá para prometer cobertura total logo de início; a lista cresce conforme mais equipes contribuem. Também não há, no material publicado, benchmark comparando a taxa de acerto do agente com e sem o toolkit instalado. Quem quiser medir isso na prática vai precisar rodar o próprio teste A/B num projeto real antes de confiar cegamente na promessa de "acertar o serviço certo na primeira tentativa".

Fonte: AWS Developer Tools Blog