Como Reduzir o Uso de Tokens MCP: Projetando Esquemas de Ferramentas Eficientes em Contexto para Reduzir a Fragilidade do Agente em Produção

Design prático de esquemas e padrões do lado do servidor para reduzir descrições de ferramentas, enxugar respostas e manter a janela de contexto do seu agente reservada para raciocínio em vez de inchaço.

Resumo: Projete ferramentas MCP pequenas e específicas em vez de envolver APIs inteiras. Retorne apenas os campos que o agente precisa, use divulgação progressiva para adiar grandes cargas úteis e mova a transformação de dados para blocos de execução de código. Isso mantém as descrições de ferramentas e respostas compactas, preservando a janela de contexto para raciocínio e reduzindo erros na seleção de ferramentas.

Projete Ferramentas em Torno de Fluxos de Trabalho, Não de Endpoints de API

Projete ferramentas em torno das tarefas específicas que seu agente realiza, em vez de expor todos os endpoints de API subjacentes. Um catálogo compacto de ferramentas orientadas a fluxos de trabalho consome muito menos espaço na janela de contexto e reduz a chance de o LLM selecionar a operação errada.

O erro mais tentador no design de servidor MCP é envolver toda a sua API—gerando 200 ferramentas a partir de 200 endpoints. Quando o LLM vê 200 descrições de ferramentas, ele consome espaço da janela de contexto analisando-as e ainda escolhe a errada porque 200 opções não são um menu, é uma carga fantasma. Em vez disso, projete ferramentas em torno de fluxos de trabalho específicos do agente. Agrupe operações relacionadas em ferramentas únicas e específicas com descrições concisas. Uma abordagem comum é limitar a área de superfície ao pequeno conjunto de ações que o agente realmente realiza, mantendo o catálogo de ferramentas compacto o suficiente para caber na janela de contexto sem obstruir o espaço de raciocínio. Cada descrição extra compete pelo mesmo espaço limitado, então cada endpoint redundante aumenta diretamente o risco de uma chamada de ferramenta equivocada.

Em vez de forçar o modelo a escolher entre endpoints CRUD granulares, dê-lhe uma operação alinhada à intenção. Expor ferramentas separadas para criação de usuário, atualizações de e-mail e exclusão desperdiça tokens; em vez disso, consolide-as em uma única ferramenta alinhada ao fluxo de trabalho:

{
  "name": "manage_user",
  "description": "Criar, atualizar ou excluir um registro de usuário em uma única chamada.",
  "parameters": {
    "type": "object",
    "properties": {
      "action": { "enum": ["create", "update", "delete"] },
      "user_id": { "type": "string" },
      "email": { "type": "string" }
    },
    "required": ["action", "user_id"]
  }
}

Esse padrão colapsa várias operações CRUD em um único esquema compacto. Ele elimina descrições redundantes e mantém o catálogo de ferramentas pequeno, preservando tokens para raciocínio real em vez de navegação. Busque um catálogo pequeno o suficiente para que toda a lista de ferramentas caiba na janela de contexto ao lado das instruções do sistema e do histórico da conversa.

Retorne Apenas os Campos que o Agente Necessita

Reduza cada resposta de ferramenta ao menor payload que o agente realmente requer, permitindo que os chamadores solicitem projeções de campos específicos e fatias paginadas, para que uma única chamada nunca desperdice milhares de tokens em dados não utilizados. Uma resposta JSON inchada com 50 campos pode consumir milhares de tokens de uma só vez quando o agente só precisava de três. Sem essa proteção, uma única chamada de super-requisição pode obstruir a janela de contexto necessária para raciocínio em múltiplas etapas. Em vez de despejar objetos completos, opte pelo menor payload viável e omita metadados e relações aninhadas quando o consumidor a montante só precisa de identificadores e status. Arrays vazios, espaços reservados nulos e objetos de relação profundamente aninhados ainda consomem tokens mesmo quando não carregam dados acionáveis, então projete o esquema para excluí-los completamente em vez de retornar ruído. Exponha um parâmetro de campos explícito no esquema da ferramenta para que o agente possa declarar exatamente o que precisa antes que o servidor construa a resposta.

{
  "tool": "get_user",
  "params": {
    "user_id": "u_4821",
    "fields": ["id", "status", "last_seen"]
  }
}

Para endpoints de lista, retorne fatias paginadas em vez de coleções completas. Retornar um array não limitado de registros completos pode monopolizar a janela de contexto, enquanto uma resposta paginada com um limite apertado e apenas os campos de superfície solicitados preserva espaço para raciocínio em múltiplas etapas.

{
  "tool": "list_orders",
  "params": {
    "status": "pending",
    "limit"