Números reais de benchmark de MCP ou CLI em agentes de IA: 1.365 tokens contra 44.026 para a mesma tarefa no GitHub, e um teste com Playwright em que a diferença quase desapareceu. Veja para onde vão os tokens, quando o MCP compensa seu custo extra e como reduzir a conta sem abrir mão das ferramentas de que você precisa.
Seu agente ainda não escreveu uma única palavra da resposta e já queimou milhares de tokens. Esse é o verdadeiro argumento por trás de MCP ou CLI para agentes de IA: não qual protocolo é mais organizado, mas qual deles deixa mais espaço na janela de contexto para o trabalho de fato. Um benchmark mediu 1.365 tokens para uma consulta ao GitHub feita pela linha de comando e 44.026 para a mesma consulta via MCP. Outro, baseado em Playwright, encontrou quase nenhuma diferença. Os dois resultados são reais, e a diferença entre eles diz mais do que qualquer um dos números isoladamente. Abaixo você verá para onde vão os tokens, o que as medições mostram, quando o MCP ainda compensa seu peso e como escolher sem adivinhar.
As duas abordagens dão mãos ao modelo. Elas diferem em como o modelo descobre o que essas mãos podem fazer e em quando ele paga por esse conhecimento.
O Model Context Protocol é um padrão JSON-RPC. Quando uma sessão começa, o cliente pergunta a cada servidor conectado quais ferramentas ele oferece. Cada ferramenta chega como um nome, uma descrição e um schema de entrada, e tudo isso fica no contexto do modelo para que ele decida o que chamar. Cada chamada e cada resultado então trafegam como JSON estruturado.
A vantagem é real: entradas tipadas, autenticação tratada do lado do servidor e ferramentas que qualquer cliente compatível consegue encontrar sozinho. A desvantagem é que todo o catálogo é pago logo no início, quer a tarefa precise de uma ferramenta, quer de nenhuma.
Na abordagem CLI, o agente escreve um comando de shell, o ambiente de execução o executa e a saída padrão volta como texto simples. Não há catálogo nem handshake. O modelo já conhece git, grep, curl e jq por causa dos dados de treinamento e, se esquecer alguma flag, executa --help e lê uma página curta.
O custo aparece apenas para os comandos efetivamente usados. Essa diferença de design explica quase tudo o que vem a seguir.
💡 Definição rápida: um token é um pedaço de texto que o modelo lê ou escreve. Definições de ferramentas, comandos e resultados ocupam a janela de contexto, e todos eles contam como entrada no turno seguinte.
O custo de tokens em um loop de agente vem de três lugares: o que o modelo é informado sobre suas ferramentas, o que ele envia e o que volta. MCP e CLI diferem principalmente no primeiro e no terceiro.
Um servidor MCP típico injeta a definição de cada ferramenta na conversa antes de a primeira pergunta ser feita. O servidor oficial do GitHub expõe 43 ferramentas, segundo o benchmark da Scalekit, então até uma consulta trivial carrega 43 schemas. A Checkly mediu apenas as definições do servidor Playwright em 5,9 mil tokens. A Anthropic declara o problema sem rodeios em seu texto de engenharia sobre execução de código com MCP: definições de ferramentas sobrecarregam a janela de contexto.
O segundo custo é mais fácil de passar despercebido. Com chamadas MCP padrão, todo resultado intermediário passa pelo modelo. O exemplo da Anthropic é a transcrição de uma reunião obtida de um serviço e escrita em outro: o texto atravessa o contexto duas vezes, o que pode somar mais de 50.000 tokens em uma gravação longa. Um pipeline de shell pode filtrar, contar ou truncar esses dados antes de o modelo vê-los.
| Fonte de custo | MCP, configuração padrão | CLI |
|---|---|---|
| Catálogo de ferramentas | Todas as definições carregadas no início da sessão | Nenhum, --help sob demanda |
| Formato da chamada | Envelope JSON com nome e argumentos | Uma única string de shell |
| Resultados | Resposta completa devolvida ao modelo | Encaminhada por pipe, filtrada ou gravada em arquivo |
| Busca de ferramenta | Servidor declara suas ferramentas | Modelo lembra os comandos ou lê a ajuda |
Dois testes públicos dão o quadro mais claro, e eles apontam em direções diferentes.
A Scalekit executou cinco tarefas somente de leitura no GitHub com o Claude Sonnet 4, 25 execuções por abordagem, contra o servidor MCP oficial do GitHub. Eles compararam CLI pura, CLI com arquivos curtos de instruções chamados skills e MCP, o que totaliza 75 execuções. Tokens por tarefa:
| Tarefa | CLI | CLI + skills | MCP | MCP vs CLI |
|---|---|---|---|---|
| Linguagem e licença do repositório | 1.365 | 4.724 | 44.026 | 32x |
| Detalhes do PR e status da revisão | 1.648 | 2.816 | 32.279 | 20x |
| Metadados do repositório e instalação | 9.386 | 12.210 | 82.835 | 9x |
| PRs mesclados por contribuidor | 5.010 | 6.107 | 33.712 | 7x |
| Última release e dependências | 8.750 | 6.860 | 37.402 | 4x |
Na média das cinco tarefas, são cerca de 5.200 tokens para CLI contra cerca de 46.000 para MCP, aproximadamente 9x. A estimativa da Scalekit para 10.000 operações por mês é de cerca de US$ 3,20 para CLI contra US$ 55,20 para MCP direto, uma diferença de 17x. A confiabilidade se moveu na mesma direção: a CLI concluiu 25 de 25 execuções, o MCP concluiu 18 de 25 (72%), e todas as sete falhas foram timeouts no nível TCP.
Observe também a coluna de skills. Na última tarefa, a versão com skills usou menos tokens que a CLI pura (6.860 contra 8.750), provavelmente porque um arquivo curto de instruções poupou o agente de tentativas e erros. Nas consultas simples, custou mais, já que as instruções são carregadas a cada vez.
⚠️ Leia os limites: um modelo, um serviço, tarefas somente de leitura. Timeouts são problemas de conexão, não erros de raciocínio, então a diferença de confiabilidade diz mais sobre a configuração daquele servidor do que sobre o protocolo em si.
A Checkly executou um teste diferente: abrir uma loja de demonstração, pesquisar um produto, clicar pelas páginas, adicionar itens ao carrinho e validar o conteúdo. A sessão MCP usou de 48 mil a 50 mil tokens de contexto. A sessão CLI, com skills instaladas, usou de 45 mil a 48 mil. Depois de três execuções, a diferença era insignificante, e a explicação é simples: a CLI do Playwright e o servidor MCP compartilham um backend e gravam os mesmos arquivos de snapshot no disco.
A Checkly também reconhece que as críticas ao MCP eram justas em 2025. Dois fatores as motivaram: os servidores carregavam todas as definições logo no início, e toda ação devolvia um snapshot completo da página embutido na resposta. Ambos foram suavizados desde então, porque os harnesses de agentes modernos adiam o carregamento das ferramentas MCP até que sejam necessárias, e os servidores podem salvar snapshots em disco. O alerta da Checkly vale ser repetido: conselhos sobre IA têm prazo de validade medido em meses.
A lição não é que um dos lados errou. O número de 32x descreve uma implementação com todos os schemas carregados. A quase igualdade descreve outra que evita o overhead. O custo em tokens é uma propriedade de como um servidor é construído, não do rótulo do protocolo.
Quando as duas opções funcionam prontas para uso, a CLI vence com mais frequência. Dois motivos pesam mais.
Décadas de scripts de shell, arquivos README e respostas de fóruns estão nos dados de treinamento de todo modelo grande. O agente não precisa de um schema para usar git log ou grep -r, e um comando de uma linha substitui uma chamada JSON com um nome, um objeto de argumentos e um envelope em volta. Quando não tem certeza, --help custa uma página curta, e não um catálogo inteiro no início de cada sessão.
A vantagem mais subestimada da CLI é a composição. Veja uma forma de listar os títulos dos pull requests mesclados recentemente:
gh pr list --state merged --limit 10 --json title --jq '.[].title'
O modelo vê dez linhas de títulos. Uma chamada MCP padrão a uma ferramenta de pull request costuma devolver o payload completo de cada item: autores, rótulos, URLs, timestamps, estado da revisão. A maior parte é ignorada, mas tudo é lido, e tudo é cobrado.
Uma sessão CLI também é mais fácil de depurar. Você pode colar o mesmo comando no seu próprio terminal e ver exatamente o que o agente viu.
A contagem bruta de tokens é um eixo. Alguns trabalhos precisam do que só um protocolo pode oferecer.
Um comando de shell roda com as permissões de quem o iniciou. Isso é tranquilo no seu próprio notebook e um problema em um produto onde muitos usuários conectam cada um a sua conta. Um servidor MCP pode manter credenciais com escopo por usuário e expor apenas as ações pretendidas, como "ler issues" sem "excluir repositório". Ele também permite que clientes fora do terminal, de assistentes de desktop a painéis de IDE, encontrem ferramentas sem que ninguém instale um binário.
Ferramentas com estado favorecem o MCP. Uma sessão de navegador que precisa sobreviver a dezenas de turnos, ou uma conexão com banco de dados com uma transação aberta, é difícil de reconstruir a partir de comandos de shell isolados.
A geração de mídia é um bom exemplo. Modelos de imagem e vídeo rodam como trabalhos assíncronos: você envia uma requisição, recebe um ID de job e consulta até o resultado estar pronto. O conector da PicassoIA encapsula esse fluxo em nove ferramentas no momento em que este texto foi escrito: geração de imagem, edição de imagem, dois geradores de vídeo, consulta de status, cancelamento, lista de jobs anteriores, lista de modelos e verificação da conta. As ferramentas de geração devolvem um ID de job junto com uma espera sugerida antes da próxima consulta, então o agente sabe quando voltar a verificar em vez de ficar em loop às cegas. Os modelos por trás dele incluem o PicassoIA Image, o PicassoIA Image Editor Pro, o PicassoIA Video e o Seedance 2.5 Lite, com até cinco previsões rodando ao mesmo tempo por conta.
Você pode acessar os mesmos modelos pela API REST em https://api.picassoia.com/v1 com curl simples. Isso funciona bem, mas o agente precisa lembrar do endpoint, anexar credenciais e escrever o próprio loop de consulta. As ferramentas MCP empacotam essas etapas. Observe também como o tamanho do catálogo importa: nove ferramentas pequenas pesam muito menos que as 43 do GitHub, e por isso um servidor enxuto incomoda menos que um servidor cheio de ferramentas.
Se o MCP é a escolha certa, você não precisa aceitar a conta padrão.
A Anthropic chama isso de divulgação progressiva: deixe o modelo ler as definições das ferramentas quando precisar delas, em vez de todas de uma vez. Duas formas funcionam. Uma é uma estrutura de arquivos em que cada ferramenta é um pequeno arquivo que o agente abre sob demanda. A outra é uma função de busca que encontra e carrega apenas as definições relevantes. Seja qual for o nome que o seu harness usa, verifique se o carregamento adiado está ativado e conecte apenas os servidores de que o projeto atual precisa.
O movimento maior da Anthropic é apresentar as ferramentas MCP como código que o agente pode chamar a partir de um sandbox. O agente escreve um script curto, o script conversa com os servidores e apenas um resumo volta ao modelo. No exemplo deles de Google Drive para Salesforce, o uso de tokens caiu de 150.000 para 2.000, uma economia de 98,7%.
Veja o que isso realmente é: um comportamento no estilo CLI, em que os dados são filtrados antes de o modelo vê-los, sobreposto à autenticação e às interfaces tipadas do MCP. Os dois campos acabam tomando emprestado um do outro.
Ganhos rápidos que você pode aplicar hoje:
Em custo bruto de tokens com as configurações padrão, a CLI vence na maioria das vezes, por 4x a 32x no benchmark mais bem documentado. Em controle de acesso, estado de longa duração e serviços hospedados, o MCP vence. E quando as ferramentas MCP são carregadas sob demanda e os resultados grandes ficam fora do contexto, a diferença pode encolher a quase nada, como mostrou o teste com Playwright.
| Situação | Melhor escolha | Por quê |
|---|---|---|
| Trabalho local com git, arquivos e builds | CLI | Comandos familiares, saída filtrada |
| Tarefas curtas em scripts ou CI | CLI | Sem handshake, pegada pequena |
| Servidor com mais de 40 ferramentas nas configurações padrão | CLI ou execução de código | O overhead dos schemas domina |
| Muitos usuários, cada um com suas próprias contas | MCP | Credenciais com escopo por usuário |
| Sessões longas de navegador | MCP | O estado sobrevive entre os turnos |
| Geração de mídia assíncrona | MCP | IDs de job e dicas de consulta |
Escolha CLI quando a ferramenta já existe como comando, o agente roda em uma máquina que você controla e cada token conta.
Escolha MCP quando você precisa de permissões por usuário, estado persistente ou um serviço hospedado sem uma boa ferramenta de linha de comando.
Combine as duas em caso de dúvida. A maioria das configurações reais faz isso: shell para o trabalho local, MCP para alguns serviços hospedados, cada um reduzido ao que a tarefa exige.
Você pode testar essas contrapartidas na sua própria configuração com o Claude Sonnet 5, um modelo criado para programação em várias etapas e uso de ferramentas. Aqui vai um fluxo rápido de auditoria:
low desliga o pensamento estendido e responde mais rápido, o que basta para a triagem. Passe para high quando quiser contrapartidas raciocinadas entre vários servidores.wc -c para uma estimativa rápida de tamanho e use os números de uso do seu provedor para contagens exatas de tokens.💡 Dica: rode a mesma auditoria com o Kimi K2.6 ou o GPT 5.6 Sol e compare quais ferramentas cada modelo cortaria.
Cada foto deste artigo segue um padrão simples: um assunto claro, uma fonte de luz, uma escolha de câmera e lente. Experimente a mesma receita por conta própria. Descreva uma bancada de trabalho às nove da manhã, um trilheiro em uma bifurcação de trilha ou a sua versão de uma mesa cheia de ferramentas, e rode isso no PicassoIA Image. Refine o resultado com o PicassoIA Image Editor Pro e, quando uma imagem parada merecer movimento, envie-a para o PicassoIA Video. Escolha um prompt do seu próximo projeto e veja o que volta.
Escolha seu idioma
