Design de Ferramentas, Integração MCP e Gerenciamento de Contexto: Checklist do Domínio CCA
Este checklist abrange dois domínios do CCA Foundations juntos, Design de Ferramentas e Integração MCP (18%) e Gerenciamento de Contexto e Confiabilidade (15%), porque na prática eles falham juntos com a mesma frequência que falham separadamente.
Uma ferramenta mal dimensionada é frequentemente a causa raiz de um orçamento de contexto estourado, portanto, estudá-los lado a lado corresponde a como os cenários do exame são realmente construídos.
- Trabalhe primeiro em Design de Ferramentas, já que o formato da saída da ferramenta impulsiona diretamente o consumo de contexto.
- Trate cada item como uma pergunta que você deve ser capaz de responder em voz alta sem uma referência aberta, correspondendo ao formato de livro fechado do exame.
- Use a seção específica de MCP, mesmo que sua experiência de produção seja limitada a ferramentas internas personalizadas; os conceitos de MCP se generalizam.
- Revise a seção de Gerenciamento de Contexto por último, pouco antes do exame, pois seus modos de falha são os mais frequentemente esquecidos sob pressão de tempo.
- Clareza de nome e descrição da ferramenta: o nome e a descrição de cada ferramenta devem permitir que o Claude a escolha corretamente sem tentativa e erro.
- Vago: uma ferramenta chamada
handle_data com uma descrição de uma linha.
- Claro: uma ferramenta chamada
lookup_order_status com uma descrição que declara as entradas, saídas exatas e quando chamá-la.
- Rigor do esquema de entrada: defina campos, tipos e enums obrigatórios de forma rigorosa, em vez de aceitar um bloco de texto livre solto.
- Solto:
{"query": "string"} para uma consulta estruturada.
- Rígido:
{"order_id": {"type": "string", "pattern": "^ORD-[0-9]{6}$"}}.
- Disciplina de tamanho de saída: a carga útil de retorno de uma ferramenta deve ser limitada e resumida, não um despejo bruto de um registro inteiro de banco de dados ou resposta de API.
- Idempotência para ferramentas mutáveis: qualquer ferramenta que escreve dados deve ser segura para retentar sem duplicar o efeito, já que os loops do agente às vezes retentam chamadas.
- Exposição de erros, não ocultação: uma chamada de ferramenta falha deve retornar um erro estruturado sobre o qual o agente possa raciocinar, não um resultado vazio silencioso que pareça sucesso.
- Escopo de privilégio mínimo: uma ferramenta deve expor a capacidade mínima necessária para seu trabalho, não uma saída de propósito geral como "executar qualquer consulta".
- Design de fronteira do servidor MCP: cada servidor MCP deve mapear para uma área de capacidade coerente (por exemplo, "sistema de tickets", "documentos internos"), não um amontoado arbitrário de ferramentas não relacionadas.
- Distinção entre recurso e ferramenta: use recursos MCP para contexto gravável e endereçável (documentos, registros) e ferramentas para ações com efeitos colaterais; confundir os dois confunde tanto o agente quanto o cenário do exame.
- Autenticação e escopo por servidor: as credenciais de um servidor MCP devem ser limitadas apenas ao que as ferramentas desse servidor precisam, não uma credencial de administrador compartilhada em todas as integrações.
- Descoberta sobre documentação: a descrição das ferramentas de um servidor MCP bem projetado deve ser autossuficiente; um agente não deve precisar de documentação externa para usá-lo corretamente.
- Consciência de versão e compatibilidade: saiba que as versões do protocolo MCP e as capacidades do servidor podem diferir, e que uma integração de produção deve lidar graciosamente com um servidor que anuncia menos capacidades.
- Sandboxing de servidores MCP externos: trate um servidor MCP de terceiros como uma superfície de entrada não confiável; valide o que ele retorna antes de alimentá-lo de volta ao contexto do agente sem filtragem.
- Isolamento de falhas: a falha de um servidor MCP não deve derrubar a disponibilidade de ferramentas de um agente inteiro se outros servidores forem independentes.
- Planejamento de orçamento de tokens por turno: saiba aproximadamente quantos tokens uma resposta típica de ferramenta, prompt do sistema e histórico de conversação consomem, e orce de acordo antes que o contexto se preencha.
- Disciplina da janela de contexto em execuções longas: para loops de agente de longa duração, remova ou resuma ativamente turnos mais antigos em vez de deixar o histórico crescer sem limites.
- Detecção de contexto obsoleto: reconheça quando o contexto transportado de turnos anteriores não é mais relevante e está adicionando ruído em vez de aterramento útil.
- Consciência de cache de prompt: entenda quando reutilizar um prefixo estável (como um prompt de sistema grande ou um conjunto de esquemas de ferramentas) entre chamadas reduz tanto o custo quanto a latência.
- Transbordamento silencioso é um modo de falha, não um caso extremo: uma janela de contexto que trunca silenciosamente mensagens mais antigas pode produzir respostas confiantemente erradas; o exame testa se você pegaria isso em uma revisão de design.
- Estratégia de retentativa e backoff: um agente confiável lida com limites de taxa e erros transitórios com backoff, não um loop de retentativa apertado que consome orçamento e piora a limitação de taxa.
- Observabilidade no uso do contexto: registre as contagens de tokens por chamada em produção para que falhas relacionadas ao contexto sejam diagnosticáveis após o fato, não apenas adivinhadas.
- Itens 1-6 (Design de Ferramentas): acerte-os primeiro, pois uma ferramenta mal projetada cria problemas de contexto e confiabilidade downstream que são mais difíceis de corrigir depois.
- Itens 7-13 (Integração MCP): aplique assim que o design básico da ferramenta estiver sólido; MCP formaliza os limites de ferramentas e recursos entre sistemas.
- Itens 14-20 (Gerenciamento de Contexto): trate como uma disciplina contínua para qualquer agente que execute mais do que alguns turnos, não uma etapa de configuração única.
Por que Design de Ferramentas e Gerenciamento de Contexto são cobertos em um único checklist?
Porque uma ferramenta mal dimensionada (saída ilimitada, sem idempotência) é uma das causas raiz mais comuns de um orçamento de contexto estourado ou de um agente não confiável, então o exame frequentemente mistura os dois.
Qual é a diferença entre um recurso MCP e uma ferramenta MCP?
- Um recurso é contexto gravável e endereçável, como um documento ou registro.
- Uma ferramenta é uma ação com efeitos colaterais, como criar um ticket ou enviar um e-mail.
Por que a disciplina de tamanho de saída é importante para ferramentas?
Uma resposta de ferramenta ilimitada (um despejo bruto de banco de dados, por exemplo) pode consumir uma grande parte da janela de contexto em uma única chamada, reduzindo o espaço para raciocínio e turnos posteriores.
O que significa escopo de ferramenta com privilégio mínimo na prática?
Uma ferramenta deve expor apenas a capacidade específica que precisa para executar, em vez de uma saída de propósito geral como "executar qualquer consulta", o que expande o raio de explosão de um erro ou injeção de prompt.
Por que a idempotência é importante para ferramentas que escrevem dados?
Loops de agente às vezes retentam uma chamada após um tempo limite ou erro transitório; se a ação subjacente não for idempotente, uma retentativa pode duplicar o efeito (como criar dois tickets em vez de um).
O que é transbordamento silencioso de contexto e por que é perigoso?
É quando uma janela de contexto trunca mensagens mais antigas sem nenhum sinal visível, o que pode fazer com que um agente responda confiantemente com base em informações incompletas em vez de falhar ruidosamente.
Devo tratar cada servidor MCP como confiável por padrão?
Não. Um servidor MCP de terceiros deve ser tratado como uma superfície de entrada não confiável, e sua saída deve ser validada antes de ser alimentada de volta ao contexto do agente sem filtragem.
Como o cache de prompt se relaciona com o gerenciamento de contexto?
Reutilizar um prefixo estável, como um prompt de sistema grande ou um conjunto fixo de esquemas de ferramentas, entre chamadas pode reduzir tanto o custo quanto a latência, o que é uma otimização de gerenciamento de contexto que vale a pena conhecer para o exame.
O que uma ferramenta deve retornar quando falha?
Um erro estruturado sobre o qual o agente possa raciocinar e potencialmente se recuperar, não um resultado vazio silencioso que possa ser confundido com uma chamada bem-sucedida sem resultados.
Por que o escopo de autenticação é importante por servidor MCP?
Se todos os servidores MCP compartilharem uma credencial de administrador ampla, uma vulnerabilidade ou uso indevido em uma integração expõe todos os outros sistemas aos quais essa credencial pode acessar.
Qual é o modo de falha de gerenciamento de contexto mais comumente testado?
Transbordamento ou truncamento silencioso de contexto em uma conversa de agente de longa duração, pois produz resultados confiantemente errados em vez de uma falha óbvia.
A retentativa com backoff é estritamente necessária para confiabilidade?
Sim, para sistemas de produção; um loop de retentativa apertado sem backoff pode piorar a limitação de taxa e consumir orçamento mais rapidamente do que o erro transitório original teria custado.
Versões da Stack: Escrito contra a linha de modelos Claude atual em ~junho de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (o padrão) e Claude Haiku 4.5 - e o SDK oficial anthropic para Python (última versão 0.x). Nomes de modelos, preços, formato do exame e versões do SDK mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs e o guia oficial do exame CCA antes de confiar neles.