Prompt & Deploy
Artigo 8 de 12
Kiro & AWS

O arsenal de ferramentas do Kiro: MCP, skills, knowledge base, code intelligence, ACP e planning agent

Um agente só é tão bom quanto o contexto que ele enxerga e as ferramentas que ele pode acionar. Este é o mapa das seis peças que transformam o Kiro de "chat que escreve código" em plataforma de engenharia.

15 de julho de 2026 · Prompt & Deploy

TL;DR

  • MCP (Model Context Protocol) conecta o Kiro a servidores externos (docs da AWS, APIs internas, bancos). Config em .kiro/settings/mcp.json, /mcp lista o que carregou, kiro-cli mcp add registra pela linha de comando.
  • Agent skills são capacidades reutilizáveis em .kiro/skills/<nome>/SKILL.md, referenciáveis via skill:// no array resources de um agente customizado.
  • Knowledge base indexa código/docs/PDF/CSV para busca semântica (recurso experimental do CLI) — útil quando o contexto excede o que cabe em resources.
  • Code intelligence faz parsing AST, busca fuzzy de símbolos, extração de assinaturas e reescrita estrutural — precisão que grep não dá em codebases grandes.
  • ACP (Agent Client Protocol) leva o Kiro para JetBrains, Eclipse, Zed e outros IDEs compatíveis. Planning agent explora e planeja sem tocar no código até você aprovar.
  • No fim, tudo se combina num único agente: resources (file:// + skill://) + mcpServers = contexto + padrões + integração + automação.

O problema: um agente cego é um agente perigoso

Quando você pede a um agente “corrija o bug de autenticação”, ele faz uma aposta. Se ele não conhece o padrão de erro do seu projeto, inventa um. Se ele não tem a documentação atualizada do serviço AWS que você usa, alucina uma flag que não existe. Se ele não sabe onde a função validateToken está definida entre 4.000 arquivos, ele adivinha — e adivinhar é como se produz código que compila e quebra em produção.

A qualidade de um agente não vem só do modelo. Vem de quanto do seu mundo ele consegue enxergar e do que ele pode fazer com isso. Um modelo de fronteira com contexto pobre perde para um modelo mediano com o contexto certo, sempre.

O Kiro trata isso como um problema de arsenal: seis mecanismos que injetam contexto real (documentação viva, símbolos indexados, padrões da casa) e estendem o alcance (integrações externas, execução planejada, uso em qualquer IDE). Este artigo abre cada um, com a sintaxe exata — nada de flag inventada.

Um modelo de fronteira com contexto pobre perde para um modelo mediano com o contexto certo. O arsenal é onde essa diferença mora.

1. MCP — conectar o agente ao mundo

O Model Context Protocol é um padrão aberto para expor ferramentas e dados a um agente por meio de servidores. Em vez de o Kiro precisar de um plugin nativo para cada sistema, você aponta para um servidor MCP e ele passa a oferecer suas tools ao agente. Documentação da AWS, um banco de dados interno, uma API de tickets — tudo vira ferramenta acionável.

A configuração vive em dois lugares: <root>/.kiro/settings/mcp.json (por workspace) ou ~/.kiro/settings/mcp.json (por usuário). O caso mais comum e útil é o servidor de documentação da AWS, servido via uvx:

{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": { "FASTMCP_LOG_LEVEL": "ERROR" },
      "disabled": false
    },
    "http-server": {
      "type": "http",
      "url": "https://api.example.com/mcp",
      "oauth": { "redirectUri": "127.0.0.1:8080", "oauthScopes": ["read"] }
    }
  }
}

Repare nos dois estilos: aws-docs é um servidor local por processo (o Kiro sobe o uvx sob demanda); http-server é um servidor remoto via HTTP, com fluxo OAuth para autenticação. Com o servidor aws-docs ativo, quando você pergunta “qual o limite de payload do SQS FIFO?”, o agente consulta a documentação real em vez de recitar de memória.

Prefere registrar pela linha de comando? O CLI faz o mesmo sem você editar JSON na mão:

kiro-cli mcp add \
  --name "awslabs.aws-documentation-mcp-server" \
  --scope global \
  --command "uvx" \
  --args "awslabs.aws-documentation-mcp-server@latest" \
  --env "FASTMCP_LOG_LEVEL=ERROR"

Depois de configurar, o slash command /mcp lista os servidores carregados e o estado de cada um — o primeiro lugar para olhar quando uma tool “sumiu”.

Há um detalhe importante para agentes customizados: por padrão um agente não herda automaticamente o mcp.json do workspace. Se você quer que ele use esses servidores, ligue includeMcpJson no JSON do agente (veja a seção de síntese). Isso é intencional — mantém agentes com escopo previsível de ferramentas em vez de puxar tudo que estiver configurado na máquina.

2. Agent skills — capacidades reutilizáveis

Uma skill é uma capacidade especializada empacotada como conhecimento. Em vez de repetir as mesmas instruções (“como fazemos revisão de segurança aqui”, “o passo a passo do nosso deploy”) em todo prompt, você as escreve uma vez e referencia. Cada skill vive em .kiro/skills/<nome>/SKILL.md.

O que a torna reutilizável é o esquema skill:// no array resources de um agente. Você lista as skills que aquele agente deve carregar, e elas passam a fazer parte do contexto dele. Um agente enxuto pode carregar exatamente as skills do seu domínio — nem mais, nem menos:

{
  "name": "security-reviewer",
  "description": "Revisa PRs contra os padrões de segurança da casa.",
  "tools": ["read", "grep"],
  "allowedTools": ["read", "grep"],
  "resources": [
    "file://README.md",
    "file://.kiro/steering/security.md",
    "skill://.kiro/skills/security-assessment/SKILL.md",
    "skill://.kiro/skills/deal-risk/SKILL.md"
  ],
  "prompt": "Você é um revisor de segurança. Aplique as skills carregadas em toda análise. Aponte HRIs e MRIs com severidade.",
  "model": "claude-sonnet-4"
}

O padrão skill://.kiro/skills/**/SKILL.md também vale, se você quer carregar todas as skills de uma vez. A diferença entre uma skill e um trecho de steering é o propósito: steering são regras sempre presentes do projeto; skill é uma capacidade que você invoca quando o agente precisa executar um tipo específico de trabalho — e que pode ser compartilhada entre vários agentes.

3. Knowledge base — busca semântica sobre o seu material

Nem sempre o contexto relevante cabe no array resources. Você pode ter um manual de 200 páginas em PDF, um dump de CSV com o catálogo de produtos, ou uma base de código grande demais para carregar inteira. A knowledge base (recurso experimental do CLI) resolve isso indexando esse material para busca semântica.

Os tipos suportados incluem código, docs, PDF e CSV. Uma vez indexado, o agente não carrega tudo no contexto — ele busca os trechos relevantes por significado, não por palavra-chave exata. Pergunte “qual é a política de retenção de logs?” e a busca traz a seção certa do PDF de compliance, mesmo que o texto use “período de armazenamento” em vez de “retenção”.

Isso muda a economia do contexto. Em vez de gastar tokens carregando um documento inteiro que talvez nem seja usado, você indexa uma vez e recupera sob demanda apenas o que a pergunta pede. Por ser experimental, trate como um recurso em evolução — confirme o comportamento antes de depender dele em fluxo crítico —, mas o conceito é sólido: RAG embutido no agente, sobre o seu próprio material.

4. Code intelligence — entender código como estrutura, não como texto

Grep enxerga texto. Um agente que só faz grep confunde a função parse do seu módulo com a palavra “parse” num comentário, num nome de variável e em três bibliotecas de terceiros. Em um arquivo, tudo bem. Em um monorepo com milhares de arquivos, isso vira ruído — e ruído vira erro.

Code intelligence trata código como o que ele é: uma estrutura. Os mecanismos:

  • Parsing AST — o código é lido como árvore sintática, não como string. parse a função é distinta de parse o comentário.
  • Busca fuzzy de símbolos — encontra a definição de uma classe, função ou método por nome aproximado, sem você saber o caminho exato.
  • Extração de assinaturas — puxa a assinatura de uma função/classe sem despejar o corpo inteiro no contexto. O agente entende a interface gastando poucos tokens.
  • Busca e reescrita estrutural — encontra padrões por forma (ex.: “toda chamada a foo(x) onde x é literal”) e reescreve estruturalmente, não com regex frágil.
  • Navegação — segue definições e referências entre arquivos.

Por que isso importa em codebases grandes: precisão e economia. Quando você pede “renomeie getUserName para getUsername”, a busca de símbolos encontra as ocorrências reais — não os falsos positivos em strings e comentários. E quando o agente precisa entender 40 funções para planejar uma mudança, a extração de assinaturas dá a ele o mapa da interface sem estourar o contexto com corpos de função irrelevantes. É a diferença entre um agente que “leu o arquivo” e um que entende o código.

5. ACP — o Kiro dentro do seu IDE

Nem todo mundo troca de editor. Se seu time vive no IntelliJ, forçar uma migração para outra IDE só para usar um agente é fricção que mata adoção. O Agent Client Protocol (ACP) resolve isso: é o protocolo que permite usar o Kiro dentro de JetBrains, Eclipse, Zed e outros IDEs compatíveis.

Na prática, você mantém o ambiente onde já é produtivo — atalhos, plugins, debugger — e ganha o agente do Kiro como cliente. A mesma assinatura de capacidades que você tem no Kiro IDE, no CLI e na web passa a estar disponível ali dentro. É a materialização da ideia de que o Kiro é uma capacidade com a mesma assinatura em várias interfaces, não um app isolado que exige que você abandone suas ferramentas.

6. Planning agent — planejar antes de mexer

O momento mais perigoso de um agente é quando ele começa a editar sem você entender o que ele vai fazer. O planning agent inverte a ordem: ele explora e planeja sem modificar código. Ele lê, investiga dependências, entende a estrutura e produz um plano. Você revisa esse plano, aprova — e só então a execução acontece.

É o antídoto para o “revisor de caixa-preta”: em vez de aprovar 300 linhas já escritas, você aprova a estratégia antes de qualquer linha existir. Para mudanças que cruzam vários módulos ou tocam código sensível, essa separação entre planejar e executar é o que mantém você no controle da decisão em vez de no papel de auditor do fato consumado.

Aprovar um plano antes da execução é decidir; aprovar código depois de escrito é apenas auditar. As duas coisas não são iguais.

Mão na massa: um agente que junta tudo

O poder real aparece quando as ferramentas se combinam. Um agente customizado bem montado é a soma de quatro camadas:

  1. Contexto — steering e docs do projeto via file://.
  2. Padrões — capacidades reutilizáveis via skill://.
  3. Integração — servidores externos via mcpServers (ou herdando o workspace com includeMcpJson).
  4. Automação — o controle de quais tools rodam sem aprovação (allowedTools), fechando o least-privilege.

Veja um agente que reúne as quatro camadas. Ele é um especialista de plataforma AWS: lê o steering e o README do projeto (file://), carrega skills de arquitetura e custo (skill://), consulta a documentação viva da AWS via MCP e ainda herda os servidores MCP do workspace:

{
  "name": "aws-platform-expert",
  "description": "Especialista de plataforma AWS: usa steering, skills e docs vivas via MCP.",
  "tools": ["read", "write", "execute_bash"],
  "allowedTools": ["read", "grep"],
  "resources": [
    "file://README.md",
    "file://.kiro/steering/**/*.md",
    "skill://.kiro/skills/wa-review/SKILL.md",
    "skill://.kiro/skills/cost-optimization-audit/SKILL.md"
  ],
  "prompt": "Você é um especialista de plataforma AWS. Siga o steering do projeto. Ao citar limites ou comportamento de serviços AWS, consulte a documentação via MCP em vez de assumir. Aplique as skills de Well-Architected e custo nas revisões.",
  "model": "claude-sonnet-4",
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": { "FASTMCP_LOG_LEVEL": "ERROR" }
    }
  },
  "includeMcpJson": true
}

Leia esse JSON como uma declaração de capacidades. resources mistura contexto (file://) com padrões (skill://). mcpServers declara a integração externa própria do agente, e includeMcpJson: true faz ele também herdar os servidores configurados no workspace. E allowedTools deixa só read e grep rodarem sem confirmação — write e execute_bash existem, mas pedem aprovação. É contexto + padrões + integração + automação, tudo em um arquivo versionado.

Para criar e usar:

# criar de forma assistida por IA (ele te entrevista e gera o JSON)
kiro-cli agent create aws-platform-expert

# ou iniciar uma sessão já com o agente
kiro-cli --agent aws-platform-expert

Dentro do chat, /agent swap troca de agente no meio da sessão e /mcp confirma que o aws-docs subiu. Se ele não aparecer, o problema quase sempre é includeMcpJson desligado ou o uvx indisponível no PATH.

Armadilhas comuns

  • Esquecer o includeMcpJson. O agente não herda o mcp.json do workspace por padrão. Se as tools de MCP “não existem” para ele, é quase sempre isso.
  • Confundir tools com allowedTools. tools é o que o agente pode usar; allowedTools é o que roda sem pedir aprovação. Deixar tudo em allowedTools joga fora o least-privilege.
  • Tratar knowledge base como estável. É experimental. Ótima para explorar material grande, mas confirme o comportamento antes de colocar em fluxo crítico.
  • Usar grep onde code intelligence resolveria. Para renomear símbolos ou entender interfaces em codebase grande, busca estrutural evita os falsos positivos que o grep traz.
  • skill:// vs steering. Steering é regra sempre presente; skill é capacidade invocável e compartilhável. Misturar os dois papéis polui o contexto.

Principais aprendizados

  • O arsenal do Kiro resolve dois problemas: injetar o contexto certo (MCP, skills, knowledge base, code intelligence) e estender o alcance (ACP para outros IDEs, planning agent para separar decisão de execução).
  • MCP conecta ferramentas externas; configure em mcp.json, liste com /mcp, e lembre do includeMcpJson nos agentes.
  • Skills empacotam capacidades reutilizáveis referenciadas por skill://; knowledge base faz busca semântica sobre material grande; code intelligence entende código como estrutura, não texto.
  • ACP te deixa no seu IDE; planning agent te deixa aprovar a estratégia antes do código existir.
  • O ganho composto está em juntar tudo num agente customizado: resources (file:// + skill://) + mcpServers = contexto + padrões + integração + automação, versionado no repositório.

Referências

Este artigo foi publicado originalmente no Medium. Preços, nomes de modelos e detalhes de produto refletem o estado do Kiro em meados de 2026 e podem mudar — confirme em kiro.dev antes de tomar decisões. Este é um conteúdo educacional independente, sem vínculo oficial com a AWS.

Tags: kiro, aws, mcp, ai-agents, developer-tools

Publicado originalmente em prompt.victorbatistax.com. Se você chegou por outra plataforma, esta é a versão canônica.