o problema
O MCP resolveu a fragmentação: em vez de uma integração sob medida para cada par agente-sistema, o desenvolvedor implementa o protocolo uma vez e ganha o ecossistema. Desde o lançamento, em novembro de 2024, a comunidade publicou milhares de servidores. O sucesso criou o problema seguinte. Hoje é rotina montar um agente com acesso a centenas ou milhares de ferramentas espalhadas por dezenas de servidores, e a maioria dos clientes MCP carrega todas as definições no contexto logo de saída.
Isso quebra de dois jeitos. Primeiro, o catálogo compete com a tarefa: o agente processa centenas de milhares de tokens de descrição de ferramenta antes mesmo de ler o pedido. Segundo, todo resultado intermediário atravessa o modelo. No exemplo do post, o pedido é “baixe a transcrição da reunião do Google Drive e anexe ao lead no Salesforce”: a transcrição entra no contexto como retorno do getDocument e sai de novo, escrita inteira pelo modelo, como argumento do updateRecord. Numa reunião de duas horas isso são 50.000 tokens extras — e documentos maiores simplesmente estouram a janela e matam o fluxo. Além do custo, há o risco de o modelo errar ao transcrever dados grandes de uma chamada para outra.
a ideia
Se o ambiente do agente já executa código, os servidores MCP não precisam aparecer como ferramentas: podem aparecer como bibliotecas. O agente não chama gdrive.getDocument pelo protocolo de tool call e recebe o texto no contexto; ele escreve um programa que importa gdrive, chama a função e passa a variável adiante. O dado nunca sobe.
Os dois problemas caem juntos porque ambos vinham da mesma premissa — a de que o modelo é o barramento por onde tudo tem que passar. Descoberta vira leitura de arquivo sob demanda; transporte de dados vira atribuição de variável dentro do sandbox.
como funciona
A implementação sugerida gera uma árvore de arquivos a partir dos servidores conectados: ./servers/google-drive/getDocument.ts, ./servers/salesforce/updateRecord.ts, um arquivo por ferramenta, com um index.ts por servidor. Cada arquivo é um wrapper tipado fino sobre callMCPTool, com a interface de entrada, a de resposta e um comentário descrevendo o que a ferramenta faz.
O agente descobre o que existe listando ./servers/, e lê só os arquivos das ferramentas que a tarefa pede. É progressive disclosure usando o filesystem como índice. A alternativa citada é expor um search_tools com parâmetro de nível de detalhe — só o nome, nome e descrição, ou a definição completa com schemas — para o agente escolher quanto contexto quer gastar procurando.
Com isso, a tarefa do Drive para o Salesforce vira quatro linhas de TypeScript, e o post reporta a queda de 150.000 para 2.000 tokens, uma economia de 98,7%. O mesmo mecanismo cobre outros três casos. Filtragem: numa planilha de 10.000 linhas, o filter roda no sandbox e o agente loga cinco linhas para conferência. Controle de fluxo: polling com while e sleep dentro do código, em vez de alternar tool call e espera pelo loop do agente — o if é avaliado pelo runtime, não pelo modelo, o que corta latência até o primeiro token. Privacidade: o cliente MCP pode tokenizar PII antes de qualquer coisa chegar ao modelo, de modo que o agente veja [EMAIL_1] enquanto o e-mail real flui do Google Sheets para o Salesforce via lookup no cliente.
Como há filesystem, há estado. O agente grava resultados intermediários em ./workspace/ e retoma de onde parou, e pode salvar o próprio código como função reutilizável em ./skills/. Um SKILL.md ao lado transforma isso numa skill estruturada.
o que isso custou
Os autores fecham admitindo o preço: código gerado por agente precisa de ambiente de execução seguro, com sandbox, limite de recursos e monitoramento. Isso é overhead operacional e superfície de segurança que a tool call direta não tem — lá, o pior caso é uma chamada malformada; aqui, é código arbitrário rodando na sua infraestrutura.
Vale ler os números como o que são. Os 98,7% saem de um exemplo específico, com dois servidores e uma transcrição grande; não é um benchmark sobre uma carga variada. E a economia depende de o agente acertar quais definições carregar — o post não mede o que acontece quando ele erra a busca e precisa voltar. O texto também é explícito em que a decisão é uma comparação de custos, não um upgrade: token e latência de um lado, complexidade de infra do outro.
onde isso aparece hoje
O argumento é o mesmo que a Cloudflare publicou sob o nome “Code Mode”, citado no próprio post: LLM escreve código bem, então use isso em vez de inventar um canal de invocação paralelo. A continuação natural dentro da Anthropic são as Agent Skills, já que a pasta de funções salvas com um SKILL.md é exatamente o formato delas — o agente acumula um repertório de capacidades de nível mais alto em vez de redescobrir a mesma sequência de chamadas toda vez. E tudo isso pressupõe o Model Context Protocol intacto por baixo: o que muda é a camada de apresentação para o modelo, não o protocolo.