Seu agente de IA desperdiça 13.000 tokens antes de dizer 'olá'
E você provavelmente não tem ideia.
Se você tem um agente com 50 ferramentas MCP instaladas, veja o que acontece antes que qualquer mensagem do usuário seja processada:
{
"name": "gmail_send_email",
"description": "Envia uma mensagem de email via a API do Gmail para um ou mais
destinatários. Use esta ferramenta quando o usuário solicitar explicitamente enviar,
compor e enviar, ou entregar uma mensagem de email para alguém.",
"input_schema": {
"type": "object",
"required": ["to", "subject", "body"],
"properties": {
"to": {
"type": "string",
"description": "O endereço de email do destinatário ou lista separada por vírgulas"
},
"subject": {
"type": "string",
"description": "A linha de assunto do email"
},
"body": {
"type": "string",
"description": "O conteúdo do corpo do email em texto simples ou HTML"
}
}
}
}
Isso é ~195 tokens. Por ferramenta. Antes de qualquer outra coisa.
50 ferramentas × 195 tokens = 9.750 tokens de pura sobrecarga.
E isso é apenas o catálogo. Você ainda não tocou no contexto do usuário, histórico de conversas, documentos ou qualquer coisa útil ainda.
"Mas há cache de prompt, certo?"
Sim. Isso reduz o custo financeiro para ~10% da taxa base.
Mas o cache não reduz o custo de atenção.
Esses tokens ainda ocupam a janela de contexto. O modelo ainda presta atenção a todos eles em cada solicitação. E se você usar recuperação dinâmica de ferramentas — selecionando ferramentas diferentes por solicitação com base na intenção do usuário — o cache quebra em cada seleção diferente.
A conta não desaparece. Ela apenas fica mais barata.
O verdadeiro problema que ninguém fala
O esquema JSON do MCP foi projetado como um contrato de execução de ferramenta. Não como um contrato de seleção de ferramenta semântica.
O resultado: informações críticas para o raciocínio do LLM estão ausentes ou enterradas em texto livre:
-
Sem contrato de erro — o LLM não sabe o que fazer quando
auth_failed - Sem gatilho explícito — ele tem que inferir "quando usar esta ferramenta" a partir de um parágrafo de descrição
- Sem taxonomia de recuperação — nenhuma maneira padrão de agrupar ou filtrar ferramentas por domínio
Verbose E semanticamente incompleto. O pior de ambos os mundos.
TTC — Catálogo de Ferramentas TERSE
Passei as últimas semanas resolvendo esse problema. O resultado é uma extensão do Formato TERSE chamado TTC — Catálogo de Ferramentas TERSE.
A mesma ferramenta acima no TTC:
FERRAMENTA gmail_send_email
PROPÓSITO: enviar email via Gmail
ENTRADA: to:string, subject:string, body:string, cc:string?
SAÍDA: message_id:string
ERRO: auth_failed | quota_exceeded | invalid_recipient
QUANDO: o usuário quer enviar ou compor um email
ETIQUETAS: gmail, email, comunicação
~55 tokens. Redução de 73,6%.
E note o que foi adicionado, não apenas removido:
| Campo | MCP JSON | TTC |
|---|---|---|
| ERRO — contrato de falha | ❌ ausente | ✅ explícito |
| QUANDO — gatilho de seleção | ❌ enterrado | ✅ explícito |
| ETIQUETAS — taxonomia de recuperação | ❌ ausente | ✅ explícito |
Não é compressão. É realocação.
Este é o ponto mais importante na especificação:
O TTC não reduz tokens removendo conteúdo semântico. Ele reduz a sobrecarga sintática e documental do esquema JSON — que serve à legibilidade humana, não ao raciocínio do LLM — e reinveste parte dessas economias em semântica explícita de seleção de ferramentas.
A matemática real:
Esquema JSON do MCP: ~195 tokens por ferramenta
TTC sem novos campos: ~35 tokens
TTC com todos os campos: ~65 tokens
Os 30 tokens de "reinvestimento" compram:
ERRO → contrato de falha (ausente no MCP)
QUANDO → gatilho de seleção (ausente no MCP)
ETIQUETAS → taxonomia de recuperação (ausente no MCP)
Resultado: 195 → 65 tokens. -66,6%.
Mas esses 65 tokens carregam um sinal de raciocínio mais alto
que os 195 originais.
Isso é ganho líquido de sinal de raciocínio — não ganho de informação no sentido clássico. Um crítico pode dizer que você removeu conteúdo (descrições de parâmetros, restrições do esquema JSON). Correto. Conteúdo que serve à documentação humana, não à inferência do LLM.
Benchmark real — 10 ferramentas medidas
Medido com o tokenizador BPE (cl100k_base) em 10 definições reais de ferramentas MCP:
