Seu agente de IA está desperdiçando 13.000 tokens antes d...

E você provavelmente nem sabe disso.

Se você tem um agente com 50 tools MCP instaladas, aqui está o que acontece antes de qualquer mensagem do usuário ser processada:

{
  "name": "gmail_send_email",
  "description": "Sends an email message via the Gmail API to one or more 
    recipients. Use this tool when the user explicitly requests to send, 
    compose and send, or deliver an email message to someone.",
  "input_schema": {
    "type": "object",
    "required": ["to", "subject", "body"],
    "properties": {
      "to": {
        "type": "string",
        "description": "The recipient email address or comma-separated list"
      },
      "subject": {
        "type": "string", 
        "description": "The subject line of the email"
      },
      "body": {
        "type": "string",
        "description": "The body content of the email in plain text or HTML"
      }
    }
  }
}

Isso é ~195 tokens. Por ferramenta. Antes de qualquer coisa.

50 tools × 195 tokens = 9.750 tokens de overhead puro.

E isso é só o catálogo. Ainda não chegou no contexto do usuário, na memória da conversa, nos documentos, em nada.

"Mas tem prompt caching, não?"

Sim. E reduz o custo financeiro para ~10% do valor original.

Mas caching não reduz o custo de atenção.

Esses tokens continuam ocupando a janela de contexto. O modelo ainda processa tudo na atenção a cada request. E se você usa retrieval dinâmico de tools — selecionando ferramentas diferentes por request — o cache quebra em cada seleção diferente.

A conta não some. Ela só fica mais barata.

O problema real que ninguém fala

O MCP JSON Schema foi projetado como contrato de execução de ferramenta. Não como contrato semântico de seleção.

Resultado: informação crítica para o LLM raciocinar está ausente ou enterrada em texto livre:

Sem contrato de erro — o LLM não sabe o que fazer quando auth_failed
Sem trigger explícito — tem que inferir "quando usar essa tool" de uma description de parágrafo
Sem taxonomia de retrieval — não tem como agrupar ou filtrar tools por domínio

Ou seja: verboso E semanticamente incompleto. O pior dos dois mundos.

TTC — TERSE Tool Catalog

Passei as últimas semanas resolvendo esse problema. O resultado é uma extensão do TERSE Format chamada TTC — TERSE Tool Catalog.

A mesma ferramenta acima em TTC:

TOOL gmail_send_email
  PURPOSE: send email via Gmail
  IN: to:string, subject:string, body:string, cc:string?
  OUT: message_id:string
  ERR: auth_failed | quota_exceeded | invalid_recipient
  WHEN: user wants to send or compose an email
  TAGS: gmail, email, communication

~55 tokens. Redução de 73.6%.

E repara no que foi adicionado, não só no que foi removido:

Campo	MCP JSON	TTC
ERR — contrato de falha	❌ ausente	✅ explícito
WHEN — trigger de seleção	❌ enterrado	✅ explícito
TAGS — taxonomia de retrieval	❌ ausente	✅ explícito

Não é compressão. É realocação.

Esse é o ponto mais importante do spec, e vale deixar claro:

TTC não economiza tokens removendo conteúdo semântico. Ele elimina overhead sintático e documental do JSON Schema — que serve legibilidade humana, não raciocínio de LLM — e reinveste parte dessa economia em semântica explícita de seleção de ferramentas.

A conta real:

MCP JSON Schema:        ~195 tokens por tool
TTC sem campos novos:    ~35 tokens
TTC com todos os campos: ~65 tokens

Os 30 tokens de "reinvestimento" compram:
  ERR  → contrato de falha (ausente no MCP)
  WHEN → trigger semântico (ausente no MCP)  
  TAGS → taxonomia de retrieval (ausente no MCP)

Resultado: 195 → 65 tokens. -66.6%.
Mas os 65 tokens carregam mais sinal de raciocínio
do que os 195 originais.

É ganho líquido de sinal de raciocínio, não ganho de informação no sentido clássico.

Benchmark real — 10 tools medidas

Medi com tokenizador BPE (cl100k_base) em 10 definições reais de tools MCP:

Tool	JSON Schema	TTC	Redução
gmail_send_email	208	55	73.6%
calendar_create_event	262	78	70.2%
github_create_issue	269	84	68.8%
jira_create_ticket	254	77	69.7%
slack_send_message	206	69	66.5%
Total (10 tools)	1.948	650	66.6%

Projeção para catálogos maiores:

Catálogo	JSON Schema	TTC	Economia
20 tools	~3.896	~1.300	~2.596 tokens
50 tools	~9.740	~3.250	~6.490 tokens
100 tools	~19.480	~6.500	~12.980 tokens

A economia absoluta cresce linearmente. Quanto maior o catálogo, maior o ROI.

Vocabulário normativo para WHEN

Um campo de linguagem natural sem padrão cria outro problema: dois autores de servidores MCP diferentes escrevem WHEN de formas incompatíveis, degradando a acurácia de seleção em catálogos grandes.

O TTC v1.0 resolve isso com vocabulário normativo:

WHEN: user [wants|requests|asks|needs|intends] to [ação] [objeto]

Exemplos conformantes:
  WHEN: user wants to send an email message
  WHEN: user requests to list files in Google Drive
  WHEN: user needs to create a calendar event

Não-conformante:
  WHEN: send email          ← falta verbo de intenção
  WHEN: user email          ← falta verbo de ação

Simulação de acurácia (TF-IDF cosine similarity, 12 tools, 36 queries):

Condição	Acurácia
MCP description livre	63.9%
TTC WHEN vocabulário controlado	72.2%
Delta	+8.3 pp

Caveat: simulação TF-IDF, não benchmark real com LLM. Evidência direcional.

Onde funciona melhor

✅ Catálogos grandes (20+ tools) — onde a economia absoluta justifica a migração

✅ Modelos locais e menores — Qwen 7B, Llama 3, Mistral — sem cache, janelas estreitas

✅ Pipelines multi-agente — o overhead se acumula a cada passagem de contexto

✅ RAG de tools — TTC compacto é ideal para indexar em vetor DB e injetar subsets

❌ Catálogos pequenos com LLM grande e contexto amplo — ganho marginal

❌ Substituir JSON Schema em contratos de API — não é o propósito

推荐订阅源

DEV Community