O problema não é o MCP — é o design da ferramenta
Muitas equipes começam expondo uma API existente diretamente como uma ferramenta Protocolo de Contexto de Modelo (MCP) e esperam que o agente resolva o resto. Para casos simples, isso até funciona. Mas na maioria das situações, não funciona. O motivo é direto: você precisa projetar suas ferramentas pensando em como os Modelos de Linguagem de Grande Escala (LLMs) e sistemas agênticos realmente operam.
Sem esse cuidado, o resultado é chamadas de ferramenta falhando, parâmetros errados sendo passados e retentativas que consomem contexto e degradam a performance. A AWS publicou um post técnico detalhado sobre esse tema, explorando onde o design de ferramentas MCP costuma falhar e como corrigi-lo com abordagens práticas de engenharia de contexto.
Os dois vilões: inchaço e confusão
Dois problemas estão por trás da maioria das falhas em ferramentas MCP.
O primeiro é o inchaço. Definições de ferramentas são carregadas no contexto do LLM a cada chamada, mesmo que a ferramenta não seja usada. Quando múltiplos servidores MCP estão conectados, o contexto pode ser consumido significativamente antes que o usuário tenha feito sequer uma pergunta. À medida que o contexto enche, a capacidade do modelo de raciocinar pode se degradar, tornando a sessão menos produtiva.
O segundo é a confusão. Com o raciocínio degradado, o LLM passa a fazer escolhas piores: chama a ferramenta errada, usa parâmetros incorretos. As retentativas pioram ainda mais o inchaço. Similaridade semântica entre ferramentas, excesso de opções e nomes ambíguos também contribuem para a confusão.
A solução instintiva — enriquecer as descrições das ferramentas com definições mais claras, mapeamentos de linguagem natural e exemplos de uso — ajuda com a confusão, mas agrava o inchaço. É um ciclo vicioso. Resolver esse equilíbrio é, fundamentalmente, um problema de engenharia de contexto: moldar o que o LLM vê e quando ele vê, para que o modelo produza resultados melhores.
Seis abordagens na prática
Para tornar os conceitos concretos, a AWS construiu seis versões de um servidor MCP que expõe uma API simulada de busca de conteúdo educacional K-12 (ensino básico americano). Cada versão aplica uma abordagem diferente sobre o mesmo backend. Os exemplos podem ser executados localmente usando o Kiro CLI. O repositório de código de exemplo está disponível no GitHub.
V1: Passagem direta (anti-padrão de referência)
A primeira versão é o anti-padrão clássico: expõe a API do backend diretamente, com 14 parâmetros usando nomes internos como discipline, media_type e content_bucket, e apenas uma linha de documentação genérica. O LLM não tem orientação sobre quais valores são válidos. Pode tentar passar “quiz” para media_type quando o valor válido é “Assessment”, ou “math” quando o campo espera “Math”. Cada escolha errada dispara uma retentativa que consome mais contexto. O baixo custo inicial é enganoso, pois a confusão eleva o custo real por meio de tentativas repetidas.
V2: Descrições enriquecidas
Mesma estrutura da V1, sem refatoração do backend. A documentação agora lista valores válidos e mapeamentos de sinônimos para cada campo — por exemplo, media_type indica que “‘quiz’/’test’ → Assessment, ‘worksheet’ → Activity”. Três parâmetros raramente usados são removidos e as mensagens de erro passam a orientar a próxima tentativa em vez de retornar apenas resultado vazio.
A precisão melhora imediatamente porque o LLM vê os valores válidos. A definição da ferramenta fica visivelmente maior — esse é o trade-off do inchaço. Cada chamada paga esse custo, independentemente de a ferramenta ser usada. Porém, menos retentativas frequentemente tornam o custo total menor do que na V1. Segundo pesquisa da Anthropic, adotar uma abordagem sob demanda para saídas detalhadas pode reduzir os tokens de resposta em cerca de dois terços.
V3: Schema e valores padrão
Esta versão renomeia parâmetros para refletir como o LLM pensa no domínio, não como o banco de dados nomeia suas colunas. discipline vira subject; content_bucket vira resource_class. Campos com valores finitos usam o tipo Literal, listando as opções diretamente no schema. Valores padrão sensatos cobrem o caso mais comum: structure='Asset', resource_class='Student Resource', language='en'. Uma ferramenta separada get_resource_detail cuida dos detalhes sob demanda.
Os enums previnem valores errados no nível do protocolo. Os padrões fazem com que o LLM só precise especificar o que varia. A definição fica menor do que na V2, porque nomes e enums fazem o trabalho que antes exigia descrições verbosas. O AWS Prescriptive Guidance para Estratégias MCP recomenda manter a contagem de parâmetros de ferramentas em torno de oito ou menos.
V4: Carregamento preguiçoso (lazy loading)
Em vez de embutir enums e descrições detalhadas na ferramenta de busca, esta abordagem move essas informações para uma ferramenta separada. A ferramenta de busca mantém apenas dicas curtas. Uma ferramenta get_taxonomy recebe uma lista de nomes de campos e retorna valores válidos e mapeamentos de linguagem natural apenas para os campos relevantes à consulta atual.
Para consultas ambíguas, o LLM chama get_taxonomy antes de buscar, para confirmar os valores válidos. Para consultas diretas onde as dicas são suficientes, pode pular essa chamada e buscar diretamente. O Amazon Bedrock AgentCore Gateway aplica esses conceitos em escala. A Anthropic reporta redução de até 85% nos tokens ao carregar definições de ferramentas apenas quando relevantes.
As Skills são outro exemplo de carregamento preguiçoso, mas implementado do lado do cliente. Esses arquivos locais contêm contexto útil para a ferramenta, mas são lidos no contexto apenas quando relevantes. A economia neste exemplo é modesta, mas em ambientes com muitas ferramentas conectadas e schemas complexos, o ganho se acumula rapidamente.
V5: Introspecção via LLM no servidor
Engenharia de contexto se torna desafiadora quando você não controla qual modelo vai interpretar suas instruções. Uma descrição ajustada para um modelo pode confundir outro. Testar todos os modelos possíveis é inviável.
Esta versão adiciona uma ferramenta introspect respaldada pelo Amazon Nova 2 Lite no Amazon Bedrock. A ferramenta introspect_query recebe a pergunta em linguagem natural do usuário e retorna filtros recomendados com justificativa para cada escolha. Por exemplo, interpreta “conteúdo alinhado ao TEKS para crianças trabalhando divisão no ensino médio” e retorna filtros recomendados: subject “Math”, grades 6-8, state_standard “TX-TEKS”, topic “dividing,division”.
Como a introspecção roda em um modelo de sua escolha, engenharia de prompt e testes se tornam confiáveis. A interpretação acontece no servidor, mantendo o contexto do cliente enxuto. O trade-off é custo: você paga pela chamada ao servidor, mas os resultados ficam consistentes independentemente de qual modelo o cliente usa.
V6: Agente como ferramenta
Quando você precisa de precisão e controle total, o próximo passo lógico é sustentar seu servidor MCP inteiro com um agente próprio. Esta versão expõe uma única ferramenta MCP respaldada por um agente Strands Agents com seu próprio system prompt e ferramentas internas. A interface externa é uma ferramenta com um único parâmetro: agentic_search_content(question: str).
O agente cuida internamente de busca de taxonomia, pesquisa, recuperação de detalhes e formatação de resposta — usando suas próprias ferramentas que o LLM cliente não vê. O comportamento é consistente independentemente de qual cliente se conecta, porque seu agente é dono do raciocínio. O histórico de conversa persiste entre chamadas, então perguntas de acompanhamento funcionam naturalmente. O trade-off é custo e latência em troca de controle direto sobre o comportamento.
Comparativo de trade-offs
Cada versão troca um custo por outro. O post original resume assim:
- V2 – Descrições enriquecidas: precisão aumenta, mas a definição da ferramenta fica maior
- V3 – Schema e padrões: precisão aumenta e a definição fica menor
- V4 – Reestruturação com lazy loading: contexto base mais enxuto, mas com uma viagem extra de ida e volta
- V5 – Introspecção no servidor: lida bem com ambiguidade, mas você paga pela inferência
- V6 – Agente como ferramenta: controle direto total, maior custo de infraestrutura
Nenhuma versão vence em todas as dimensões. A escolha certa depende da quantidade de campos, da estabilidade do vocabulário, do orçamento de latência e de quanto você precisa de comportamento consistente entre diferentes clientes.
Para ir mais fundo
O protocolo MCP continua evoluindo. O Roadmap MCP 2026 aborda escalabilidade de transporte, comunicação entre agentes e funcionalidades para implantação empresarial. Para aprofundamento, a AWS indica os seguintes recursos:
- Estratégias MCP na AWS — cobre a arquitetura mais ampla: quais padrões MCP usar, quando conectar múltiplos servidores e como estruturar seu sistema MCP além de uma única ferramenta.
- AWS MCP Server — servidor MCP gerenciado que dá a agentes de codificação IA acesso a APIs da AWS, busca de documentação e skills de agente curadas por uma única conexão.
- Strands Agents SDK — para aprofundar na abordagem agêntica da V6, com agentes multi-turno, orquestração de ferramentas e comportamento testável.
- Amazon Bedrock AgentCore — implante seu servidor MCP sem gerenciar infraestrutura, com hospedagem em runtime, gateway para descoberta de ferramentas multi-servidor e memória persistente entre sessões.
- Servidores MCP Open Source para AWS — 56 servidores MCP de código aberto cobrindo documentação, infraestrutura, IA/ML, dados, ferramentas de desenvolvedor e mais.
- Amazon Bedrock AgentCore Samples — guias de início rápido, demos de funcionalidades, exemplos de casos de uso, blueprints e workshops para o AgentCore.
- Servidores MCP Serverless de Exemplo — implementações de referência para hospedar servidores MCP no AWS Lambda e no Amazon Elastic Container Service (Amazon ECS).
Fonte
MCP tool design: Practical approaches and tradeoffs (https://aws.amazon.com/blogs/machine-learning/mcp-tool-design-practical-approaches-and-tradeoffs/)
Leave a Reply