Dê um shell ao seu agente, não um protocolo

Cada MCP server que você instala é um imposto silencioso sobre todas as conversas que vêm depois. Você paga mesmo que a ferramenta nunca seja chamada.

O instinto faz sentido. Aparece uma capacidade nova. Alguém publica um MCP server para ela. Você instala, configura, esquece. Repete até a sua lista de ferramentas ter catorze itens e toda sessão começar queimando dezoito mil tokens em schemas que o modelo talvez nem use naquele dia.

Uso um agente de IA para código todo dia. Construí sozinho uma fintech cripto com 13 apps usando agentes de IA em 70 dias. Nesse sprint, aprendi uma coisa sobre MCP e CLI mais rápido que qualquer outra: o protocolo não é o gargalo que o ecossistema finge que é. O shell resolve a maior parte disso mais barato, e você só percebe a diferença quando começa a olhar para onde os tokens vão.

MCP adiciona tokens antes de você digitar qualquer coisa

A mecânica é esta. Quando o seu agente inicia, cada MCP server registrado empurra os schemas das suas ferramentas para a context window. Nada de lazy loading. Nada sob demanda. Todos, logo de cara, em toda sessão, usando ou não naquele dia.

Um MCP server popular pode consumir de 13.000 a 18.000 tokens de contexto antes de você digitar um único caractere. Isso é algo como sete a nove por cento de uma janela de 200k, embora. Rode três ou quatro MCP servers e a conta se acumula. Você gastou uma fatia relevante de todo o seu orçamento de contexto com definições de schema para capacidades que talvez nem rodem naquela sessão.

Uma ferramenta de CLI não custa nada disso. Você chama pelo bash. O modelo paga zero tokens para saber que ela existe. Quando precisa descobrir quais flags ela aceita, roda <tool> --help e o schema aparece sob demanda, uma vez, no momento do uso. Isso é progressive disclosure. O MCP é o oposto: carrega tudo de antemão, usa uma fração e paga por tudo a cada turno.

O imposto de tokens adiantado

13k-18k

tokens por MCP servercarregados em toda sessão, com uso ou sem

0

tokens para CLI via bashaté a ferramenta ser de fato chamada

7-9%

da janela consumidapor server popular num contexto de 200k

A assimetria pesa mais em sessões longas ou repetidas. O modelo relê o contexto inteiro a cada turno. Aqueles 18k tokens de schema não são um custo único de inicialização. São um custo por turno, em toda sessão, a ferramenta sendo chamada ou não. Numa semana de uso diário, você pagou por aquele server dezenas de vezes em sessões nas quais ele nunca rodou.

–help é um schema perfeitamente bom

As pessoas tratam a CLI como plano B para quando não existe MCP server. Esse enquadramento está invertido. Uma ferramenta de CLI com uma saída de --help legível é, na maioria dos casos, uma interface melhor para um agente, e não pior.

O motivo: o schema de um MCP server é estático, escrito uma vez pelo autor do server. Se ele é prolixo ou redundante, você paga por isso em toda sessão. O --help de uma CLI também é o schema dela, mas o agente só busca quando é relevante e só para o subcomando de que precisa. O modelo pode rodar <tool> --help <subcommand> para descer exatamente até o nível de detalhe certo. Nenhum MCP server faz isso sozinho.

É o que harness engineering chama de progressive disclosure aplicada na camada de ferramentas: dar menos ao modelo de antemão e deixar que ele peça exatamente o que precisa, no momento em que precisa.

✗

MCP server

1. 01Carrega todos os schemas de ferramentas no contexto ao iniciar a sessão
2. 02Custo de tokens fixo por server por sessão, com uso ou sem
3. 03Schema estático, escrito uma vez pelo autor do server
4. 04Vários servers multiplicam o custo adiantado de forma linear
5. 05Opaco: o modelo lê schemas que você não escreveu

✓

CLI via bash

1. 01Zero tokens até a ferramenta ser de fato chamada
2. 02Custo de tokens proporcional ao uso real
3. 03--help é o schema, carregado só sob demanda
4. 04Progressive disclosure: desce nos subcomandos conforme precisa
5. 05Transparente: você lê exatamente o que o modelo lê

A posição do Pi: quatro ferramentas e um shell

O Pi, o coding agent open source do Mario Zechner, vem com zero MCP servers por padrão. Ele dá ao modelo quatro ferramentas: read, write, edit e bash. Essa é toda a superfície de ferramentas.

É uma decisão de design deliberada, não um descuido. O argumento do Zechner é que os harnesses mais populares ficaram opacos e instáveis porque as listas de ferramentas e o contexto injetado mudavam o tempo todo pelas costas do usuário. O modelo é capaz o suficiente sozinho. Cada ferramenta que você adiciona é uma aposta de que ela vai ser usada com frequência suficiente para justificar o overhead. A maioria dessas apostas não se confirma.

O bash é a válvula de escape que torna o resto desnecessário. Precisa de git? Bash. Precisa de grep, jq, curl ou algo para transformar JSON? Bash. Toda ferramenta de CLI feita nos últimos cinquenta anos funciona por ele na hora, com custo zero de integração e zero overhead de schema. O shell é uma interface de ferramentas incrivelmente capaz. A aposta do Pi é que ele cobre a grande maioria do que os MCP servers são instalados para oferecer, por uma fração do custo de contexto.

Leia o detalhamento do custo de tokens para a contabilidade completa de para onde vão os tokens entre saída de ferramentas, histórico da conversa e reexplicação a cada sessão. O overhead de schema do MCP entra na camada de saída de ferramentas desse mesmo modelo.

Quando o MCP realmente se paga

Nada disso é um argumento de que o MCP está errado. O protocolo resolve problemas reais em situações específicas, e essas situações existem.

O MCP se paga quando uma capacidade não tem um equivalente limpo em CLI. Algumas APIs exigem fluxos OAuth, sessões com estado ou navegação estruturada por recursos, coisas que chamadas via bash resolvem mal. Um MCP server bem feito para um sistema interno autenticado é uma troca legítima. Você paga o custo do schema e ganha algo que não conseguiria replicar direito com um comando de shell. É uma troca justa.

O MCP também justifica o overhead quando você usa a ferramenta na maioria das sessões. Se você abre o agente e consulta um banco em nove de cada dez sessões, o custo adiantado do schema se dilui no uso real. A relação token por valor se sustenta. Se você consulta em uma de cada vinte sessões, pagou dezenove vezes por nada, e uma chamada via bash na única sessão em que precisou teria custado menos no total.

A recomendação não é remover todos os MCP servers. É ser intencional sobre quais ficam registrados. Mantenha os que você usa na maioria das sessões, ou os que cobrem capacidades sem caminho via CLI. Corte o resto.

A auditoria

Uma auditoria rápida do seu setup de MCP leva dez minutos e se paga na hora.

Auditoria de MCP

• ✓Obrigatório:
  Liste todos os MCP servers registrados hoje no seu agente
• ✓Obrigatório:
  Confira nas suas últimas 20 sessões quais servers foram de fato chamados
• ✓Obrigatório:
  Mantenha os servers chamados em mais da metade das sessões recentes
• ✓Obrigatório:
  Para servers pouco chamados: veja se existe um equivalente em CLI
• ✓Obrigatório:
  Troque os servers que têm equivalente em CLI por uma chamada via bash
• •Opcional:
  Mantenha os MCP servers que cobrem capacidades sem caminho via CLI
• ✗Anti-pattern:
  Instalar servers por garantia para cobrir todo edge case possível
• ✗Anti-pattern:
  Adicionar um server sem antes checar o custo em tokens

A auditoria é uma correção única que rende para sempre. Depois que você corta um server, para de pagar o overhead dele em cada turno de cada sessão futura. O retorno não é linear. É permanente.

A regra de decisão

MCP ou CLI não é um debate filosófico. É uma questão de orçamento de tokens com duas entradas: com que frequência você usa a capacidade, e existe um equivalente em CLI?

Se a capacidade é essencial na maioria das sessões e não tem um caminho limpo via CLI, instale o MCP server. Aceite o overhead como o custo de uma lacuna real. Se a capacidade é ocasional, ou se uma CLI resolve, use bash. O modelo descobre as flags. Sempre descobriu.

O princípio mais amplo é o mesmo que faz o harness minimalista do Pi funcionar: menos suposições sobre o que o modelo vai precisar, e custo menor para as suposições que se provarem erradas. Dê um shell ao seu agente. A maior parte do que você busca num MCP, o shell já resolve.

Perguntas comuns

MCP vs CLI importa se eu tenho uma context window grande?+

Sim. Uma janela maior não torna o desperdício gratuito. Só torna mais fácil ignorá-lo.

Um server que consome de 13k a 18k tokens por sessão continua consumindo, seja qual for o tamanho total da janela. Numa janela de 200k, isso dá nove por cento. E o custo não é uma taxa única de inicialização: o modelo relê o contexto inteiro a cada turno, então você paga esses tokens de schema de novo em cada passo de cada tarefa.

A qualidade do contexto importa tanto quanto a quantidade. Encher uma janela grande com schemas de ferramentas que o modelo não vai usar tira espaço do contexto de trabalho de verdade: a spec, o diff, a mensagem de erro de que o modelo precisa para corrigir o bug agora. Uma janela maior deixa você ignorar o problema por mais tempo; não resolve.

Posso usar MCP e CLI no mesmo agente?+

Sim, e a maioria dos setups em produção faz isso. O objetivo não é banir o MCP. É ser intencional sobre quais servers ficam registrados. Mantenha MCP para as capacidades que você usa na maioria das sessões, ou para as que não têm equivalente em CLI. Mande todo o resto pelo bash. As duas abordagens não se excluem. A auditoria é sobre ser deliberado em vez de acumular servers no reflexo.

Como estimo o custo em tokens de um MCP server antes de instalar?+

Veja quantas ferramentas o server registra e quão verbosas são as descrições. Cada definição de ferramenta entra na conta de tokens adiantada. Um server que registra oito ferramentas com schemas de parâmetros detalhados vai custar mais que um com três ferramentas simples.

O método prático: instale o server numa sessão de teste e peça ao agente para mostrar a lista completa de ferramentas ou o system prompt. Conte esses tokens. Uma estimativa grosseira é de 200 a 500 tokens por definição de ferramenta, mais os schemas de recursos. Um server com dez ferramentas verbosas chega fácil na faixa de 13k a 18k antes de você fazer qualquer coisa.

O que 'progressive disclosure' significa para ferramentas de agentes de IA?+

Progressive disclosure significa que o agente só carrega informação sobre uma ferramenta quando precisa usá-la, não antes. A CLI faz isso naturalmente: o modelo não tem schema de uma ferramenta de CLI até rodar --help, que carrega só a documentação relevante naquele momento. O MCP é o inverso: todos os schemas carregam no início da sessão, o modelo chamando essas ferramentas ou não. Progressive disclosure mantém a context window reservada para o trabalho de verdade, em vez de pré-preenchida com definições de capacidades que talvez nem importem naquela sessão.

Cortar MCP servers afeta o que o meu agente consegue fazer?+

Só nas sessões específicas em que você os usaria, e mesmo assim só se não existir caminho via CLI. Se você corta um server e troca por chamadas via bash, o agente continua fazendo tudo o que fazia antes, com comandos de shell em vez do protocolo. Para tarefas comuns de desenvolvimento, a diferença prática é invisível.

A exceção real são as capacidades sem caminho via CLI: APIs baseadas em OAuth sem alternativa por token, sistemas de recursos com estado ou navegação estruturada de dados que exigiria construir uma ferramenta própria considerável para replicar. Mantenha MCP para essas. Para todo o resto, bash é mais rápido de configurar e mais barato de rodar a cada turno.

A abordagem sem MCP é prática para times, e não só para quem constrói sozinho?+

Para times pequenos fazendo desenvolvimento comum, é bem prática. O bash cobre a grande maioria das operações do dia a dia sem nenhum setup extra, e o ganho de transparência é maior em time, porque todo mundo consegue ler exatamente o que o agente recebe.

Times maiores, com infraestrutura compartilhada, têm mais casos legítimos de MCP: acesso autenticado a sistemas internos, recursos estruturados que são inconvenientes via CLI pura ou capacidades que exigem estado persistente entre chamadas de ferramenta. O argumento não é que quatro ferramentas sejam a resposta para todo time em qualquer escala. É que o instinto padrão de adicionar servers merece mais escrutínio antes da instalação do que costuma receber.