Eu Deletei Todos os Meus Servidores MCP e Tudo Ficou Mais Rápido

No meu último post, descrevi um sistema PKM mantido por Ansible, git e uma pequena frota de servidores MCP. Oito deles, para ser preciso. ArXiv, Semantic Scholar, Google Workspace, Obsidian, Thoughtbox, QMD, Markitdown, Mermaid. Cada um um processo stdio que Claude Code gera, conecta e mantém ativo durante a sessão.

Se você está executando servidores MCP com Claude Code, você já sabe que há um custo de token. As definições de ferramentas não são gratuitas. Mas há um detalhe sobre quando esse custo entra em cena que mudou a forma como eu penso sobre toda a arquitetura.

O problema do carry

Claude Code não carrega todas as definições de ferramentas MCP no início da sessão. Ele é mais inteligente do que isso. As ferramentas são carregadas de forma preguiçosa — na primeira vez que você realmente usa um servidor, suas definições entram no contexto. Até agora, tudo razoável.

Aqui está a parte que me pegou: uma vez carregadas, essas definições permanecem no contexto para todas as turnos subsequentes. Elas são carregadas para frente, pedido após pedido, até que a compactação finalmente as remova. Usou seu MCP do Semantic Scholar uma vez no turno 3 para procurar um artigo? Suas 33 definições de ferramentas — nomes, descrições, esquemas de parâmetros JSON completos — continuam presentes nos turnos 4, 5, 6, 7... até que o contexto seja compactado.

Não é um custo de inicialização. É um custo de carry. E ele se acumula.

Fiquei curioso sobre o peso real. Abri os logs da API do GoodLemur (JSONL de requisição/resposta bruta que eu salvo para pesquisa) e medi o que cada servidor adiciona a cada requisição uma vez carregado:

O Google Workspace foi o pior infrator. 142 ferramentas. ~37,392 tokens. Verifique seu calendário uma vez no turno 5, e essas definições ocupam o contexto em todos os turnos até a compactação.

Agora, aqui está a questão: o cache de prompt significa que você não está pagando o preço total de entrada por essas definições repetidas. A API as armazena em cache do lado do servidor após o primeiro envio. Portanto, o custo dolar é gerenciável. Mas o cache não reduz a janela de contexto. Esses ~37,392 tokens ainda ocupam espaço. Eles contam contra seu limite de 200k, assim como sua conversa real.

Em todos os meus servidores, uma vez carregados: ~51,000 tokens por turno sentados no contexto. Isso é 25% de uma janela de 200k que não está disponível para histórico de conversação, código ou raciocínio. A compactação é acionada mais cedo. Você perde o contexto da conversa mais rápido. Sua profundidade de sessão efetiva diminui — não porque você ficou sem coisas para dizer, mas porque as definições de ferramentas que você usou uma vez estão ocupando espaço.

Há um segundo ângulo que torna isso pior. A API tem uma estratégia de edição de contexto chamada clear_tool_uses que limpa antigos resultados de ferramentas de turnos passados — conteúdos de arquivos que você já leu, resultados de busca que você já processou. É projetada para liberar exatamente esse tipo de peso acumulado. E funciona muito bem para ferramentas CLI. Quando Claude chama s2-search via Bash, essa saída do Bash é um resultado de ferramenta. Em turnos posteriores, clear_tool_uses pode removê-lo.

Mas as definições de ferramentas MCP não são resultados de ferramentas. Elas são estruturais. Elas vivem no parâmetro tools, enviado com cada requisição da API, imunes à edição de contexto. Nenhuma estratégia de limpeza pode tocá-las. Portanto, as ferramentas MCP recebem o pior de ambos: suas definições persistem para sempre (até a compactação), e elas não se beneficiam do sistema projetado para gerenciar exatamente esse problema.

A ideia

E se as ferramentas fossem apenas comandos CLI?

Um servidor MCP é um processo que fala JSON-RPC sobre stdio. Claude Code o inicia, negocia capacidades e carrega cada definição de ferramenta no contexto quando você a usa pela primeira vez — onde ela permanece até a compactação. Mas se Claude já sabe que um CLI existe — porque você disse a ele no CLAUDE.md — ele pode simplesmente chamá-lo com Bash. Nenhum processo para gerenciar. Nenhuma definição de ferramenta acumulando no contexto. Nenhum custo de carry.

Antes (MCP): Usar o Semantic Scholar uma vez → 33 definições de ferramentas carregadas → carregadas a cada turno até a compactação → imunes a clear_tool_uses.

Depois (CLI): CLAUDE.md diz que s2-search existe → Claude o chama via Bash → resultado pode ser limpo em turnos posteriores → nenhuma definição persiste.

Mesma capacidade. A diferença é o que acontece nos turnos em que você não está usando essa ferramenta.

A migração

Acabei com três abordagens dependendo do servidor:

1. Escrever wrappers CLI finos (arxiv-search, s2-search)

Para ArXiv e Semantic Scholar, escrevi scripts em Python que acessam as APIs diretamente. Sem bibliotecas para S2 — o pacote Python semanticscholar acabou sendo inutilizavelmente lento sem uma chave de API. Sua lógica de repetição bloqueava por mais de 30 segundos. Uma chamada bruta urllib.request retorna em milissegundos.

# s2-search — API direta, sem biblioteca
def api(path, params=None, base=BASE_GRAPH, method="GET", body=None):
    url = f"{base}{path}"
    if params:
        url += "?" + urlencode({k:v for k,v in params.items() if v is not None})
    req = Request(url, method=method,
                  data=json.dumps(body).encode() if body else None,
                  headers=None)