Construa Servidores MCP que não desperdicem tokens.

Os servidores MCP de primeira geração eram ótimos. Eles davam aos agentes de IA acesso a uma tonelada de aplicativos e dados externos — Jira, Confluence, GitHub, Linear, você nomeia. Mas a maioria deles apenas envolvia APIs REST. E isso causa uma tonelada de inchaço de contexto, alucinações e queima de tokens.

Combinando algumas estratégias do ultra-mcp-toolkit, você pode reduzir esse inchaço dramaticamente — e economizar dinheiro.

Gerar um servidor MCP econômico é fácil. Basta instalar a habilidade e pronto.

Veja como "dramaticamente" se parece

Benchmark real, instância Jira ao vivo, reproduzível:

Tamanho da resposta por chamada

Aquela linha de ticket rico é a que dói. 270 KB → 15.5 KB. ~67k tokens para ~3.9k tokens. O mesmo conteúdo; o payload completo ainda é armazenado em disco e o agente pode buscá-lo via um ref: apenas se realmente precisar do detalhe.

Custo da lista de ferramentas (pago a cada conversa)

Você leu certo. As listas de ferramentas caem de ~10k tokens para ~100 tokens. Em cada. única. conversa.

Por que os servidores MCP vazam tokens

Quatro anti-padrões aparecem quase em todos os lugares:

1. Retornando JSON de API bruto. Um problema do Jira carrega iconUrls, URLs self aninhadas, metadados de esquema, dicas de expansão, três formas diferentes do mesmo campo de status. O agente não precisa de nada disso.
2. Uma ferramenta MCP por endpoint. Um CRM típico tem ~80 endpoints → 80 descrições de ferramentas na lista → ~10k tokens antes que o usuário digite qualquer coisa.
3. Pedir ao LLM para filtrar ou paginar. O modelo não consegue paginar de forma confiável através de estruturas enormes, e a lógica de divisão em si custa tokens. Filtragem pertence ao lado do servidor.
4. Sem disciplina sobre o que é mantido. O corte da lista de negação (delete result.iconUrl) quebra silenciosamente o dia em que a API adiciona um novo campo barulhento. As listas de permissão mantêm o contrato estável.

A solução, em três estratégias

1. Projeções de corte estilo lista de permissão

import { pick } from "ultra-mcp-toolkit/trim";

const issueSummary = (raw) => {
  const r = raw as { key: string; fields: Record<string, unknown> };
  return {
    key: r.key,
    ...pick(r.fields, ["summary", "status", "priority", "assignee"]),
  };
};

Registre o corte uma vez. Cada resposta passa por ele. Novos campos da API são, por padrão, descartados. O modelo vê o que precisa; a resposta completa vive no disco como um ref: que o agente pode desreferenciar sob demanda.

2. Ferramentas consolidadas (discriminadas por ação)

Em vez de 80 ferramentas, exponha ~15 — cada uma recebendo um argumento action:

{ action: "get", issueIdOrKey: "PROJ-1" }
{ action: "create", projectKey: "PROJ", summary: "..." }
{ action: "transition", issueIdOrKey: "PROJ-1", transition: "Done" }

Mesmas operações, 1/5 do custo da lista de ferramentas. O despachante do toolkit lida com a validação Zod por ação, roteamento de manifestos e um full: true escape hatch quando o modelo realmente precisa da resposta bruta.

3. Modo code-api (a alavanca 99×)

Exponha uma única ferramenta MCP que entrega ao agente um caminho para um CLI agrupado mais um endereço de socket:

node <cli-path> issue.get --issueIdOrKey=PROJ-1
# stdout: resumo cortado como JSON
# linha final: `ref: /path/to/full-response.json`

O agente controla toda a API a partir de seu shell. A lista de ferramentas permanece