Toda discussão técnica que passa de um ano vira briga de torcida. A de MCP contra CLI já tem camisa, hino e gente xingando o juiz no fórum. O preprint MCP vs CLI for AI Agents (abre em nova aba), publicado no arXiv em 21 de outubro de 2026, entra em campo como o árbitro que apita o empate e manda todo mundo para casa satisfeito. Pelo veredito, CLI fica com quem trabalha sozinho na própria máquina, MCP com quem tem auditor e a produção com uma arquitetura híbrida. A conclusão é sensata, mas sensatez não é prova. Segundo o próprio resumo, o artigo entrega análise comparativa, exemplos trabalhados e modelagem econômica, e nenhuma das três é medição independente.
Minha tese é que o mérito do artigo está em mudar a pergunta. O placar de tokens é justamente onde ele está mais exposto. A questão de fundo nunca foi quanto custa descrever uma ferramenta para o modelo, e sim quem segura a chave.
O que o resumo afirma
Os autores comparam as duas abordagens em 14 dimensões de avaliação. O resumo menciona exemplos trabalhados, uma avaliação de segurança contra "frameworks de conformidade estabelecidos" e modelagem econômica. De um lado está o CLI, em que o agente executa comandos de shell diretamente. Do outro está o Model Context Protocol (abre em nova aba), descrito como um protocolo JSON-RPC estruturado que dá acesso tipado e governado às ferramentas.
O veredito tem três partes:
- CLI oferece eficiência superior em fluxos de um único usuário e só locais.
- MCP atende requisitos que, nas palavras dos autores, o CLI "fundamentalmente não consegue" satisfazer: controle de acesso granular, isolamento de credenciais, auditoria estruturada e governança multi-tenant.
- Progressive disclosure, a técnica de expor as ferramentas aos poucos em vez de despejar todas as definições no contexto, eliminaria a fraqueza histórica do MCP, o custo de janela de contexto. Com ela, o MCP chegaria a uma eficiência de tokens "comparável" à do CLI sem perder os benefícios arquiteturais.
Como base, o artigo cita uma orientação formal da NSA (CSI U/OO/6030316-26), padrões de segurança da OWASP (abre em nova aba) e modelagem econômica da BCG e do Gartner. É uma bibliografia de respeito: governo, padrão de segurança e consultoria. Convém lembrar, porém, que projeção de consultoria é premissa, não dado de laboratório. Quando um paper estima custo apoiado no Gartner, o desenvolvedor deve fazer o mesmo que faz diante de um "na minha máquina funciona": pedir a configuração do ambiente.
Onde o shell ganha, e por que ganha
O CLI tem a vantagem de quem chegou primeiro. O modelo já viu grep, git e curl mais vezes do que qualquer estagiário verá na vida. Um comando de shell é curto, combina com outros por pipe e não exige que o agente carregue no contexto o esquema de cada ferramenta antes de começar a trabalhar. Quem já usou um agente de código no terminal conhece a sensação: ele lê, testa, quebra, conserta, e ninguém precisou escrever contrato para nada disso.
No desenvolvimento local e com um único usuário, essa informalidade é virtude. O agente roda com as suas permissões, mexe nos seus arquivos e usa as suas credenciais, e o único prejudicado se algo der errado é você. É como emprestar a chave de casa a um amigo de confiança: o risco existe, mas é seu e foi você quem decidiu corrê-lo. Os autores concordam que, nesse terreno, o CLI é mais eficiente.
Onde o shell não chega
O problema começa quando a casa deixa de ser só sua. Um agente com acesso a shell lê variáveis de ambiente, arquivos de configuração e o diretório onde a credencial está guardada, porque a credencial vive no mesmo espaço que o agente. Isolamento, ali, é questão de boa vontade.
O controle granular sofre do mesmo jeito. Liberar git e proibir git push --force na branch principal significa escrever regras sobre strings de comando, o que em segurança equivale a trancar a porta e deixar a janela aberta com um bilhete pedindo que ninguém entre. A auditoria também é frágil. O histórico do shell é texto corrido, e reconstruir quem fez o quê, com qual permissão e em nome de qual cliente vira trabalho de arqueólogo.
No MCP, a chamada é tipada, a credencial fica no servidor e não no agente, e cada invocação pode ser registrada como evento estruturado e separada por tenant. É aqui que o artigo tem razão, embora eu trocasse o "fundamentalmente não consegue" por algo mais modesto: o CLI não consegue nada disso sem reconstruir, aos pedaços e sem especificação, algo que acaba parecido com um protocolo.
O ponto mais frágil é justamente o que mais importa
A alegação sobre progressive disclosure é a que decide a discussão para a maioria das equipes. O custo de contexto sempre foi o argumento mais forte contra o MCP: cada servidor conectado empurrava definições de ferramentas para dentro da janela, e a conta chegava antes do resultado. Se esse custo desaparece, sobra pouca razão técnica para preferir o shell fora da máquina pessoal.
O mecanismo é plausível. Em vez de entregar o catálogo inteiro, o sistema mostra um índice e carrega o esquema só quando a ferramenta vai ser usada. Mas "comparável" é uma palavra que carrega muito peso. Comparável em qual carga de trabalho, com qual modelo e com quantas ferramentas? Pelo que o resumo descreve, essa conclusão vem da análise dos próprios autores, não de replicação independente.
Há ainda uma hipótese que vale testar antes de comemorar. Carregar esquemas sob demanda acrescenta idas e voltas entre o agente e o servidor, e parte da economia de tokens pode reaparecer como latência. Não sei se acontece, e o resumo não diz. É exatamente o tipo de coisa que se mede, não que se modela.
O melhor contraponto: o protocolo também tem porta dos fundos
O argumento mais sério contra o otimismo do artigo é que a governança do MCP governa a chamada, não o conteúdo. A descrição de uma ferramenta é texto que entra no contexto do modelo, e tudo o que o modelo lê é superfície de ataque. Um servidor malicioso ou comprometido pode esconder instruções na descrição da ferramenta ou no retorno de uma chamada, o que a literatura de segurança chama de tool poisoning e de prompt injection. Embrulhar o texto em JSON tipado não o torna confiável. Além disso, cada servidor MCP instalado é mais uma dependência na cadeia de suprimentos, com o mesmo histórico de descuido que conhecemos dos pacotes de npm.
O resumo não informa se a avaliação ancorada na OWASP e na orientação da NSA cobre esses vetores com a profundidade necessária. Antes de citar o paper numa revisão de arquitetura, vale ler essa seção inteira.
Esse contraponto qualifica a tese, mas não a derruba. O MCP oferece o lugar onde a governança pode morar, mas não entrega a governança pronta. Um porteiro com prancheta só serve se alguém lê a prancheta.
Os defensores do CLI têm outra objeção legítima: sandbox, container efêmero e token de vida curta resolvem boa parte do problema sem protocolo novo. Resolvem, e isso não contradiz o artigo. É o próprio híbrido que ele recomenda, só que com outro nome.
Como eu leria o "híbrido" na prática
O resumo recomenda arquitetura híbrida para produção, mas não detalha o desenho. A divisão a seguir é minha leitura, não uma afirmação dos autores:
- Desenvolvimento local, um usuário: CLI sem culpa. Se o agente roda sozinho por muito tempo, coloque-o numa sandbox, por precaução.
- Ambiente corporativo regulado ou multi-tenant: MCP na fronteira onde ficam credenciais e dados de terceiros, com progressive disclosure, logs estruturados e uma lista curta e revisada de servidores permitidos.
- Automação em nuvem: shell dentro de container descartável para o trabalho no próprio workspace, e MCP para tudo que toca sistemas de outra equipe ou de clientes.
A regra que resume tudo cabe numa linha: shell para o que é seu, protocolo para o que é dos outros.
Conclusão
O preprint não prova que o MCP venceu, nem que o CLI morreu. Prova, no máximo, que a pergunta estava mal formulada. Comparar as duas abordagens por consumo de tokens é como escolher entre fechadura e chave pelo peso. O artigo serve como mapa, não como laudo: aponta onde cada abordagem se encaixa e deixa sem resposta medida justamente a parte que mais interessa ao bolso.
No fundo, escolher entre MCP e CLI é a velha escolha entre confiar e conferir. Para quem trabalha sozinho, confiar sai mais barato. Para quem responde a alguém, conferir é o trabalho.
Perguntas frequentes
O artigo traz benchmark de consumo de tokens?
Pelo resumo, as conclusões sobre custo vêm de exemplos trabalhados e de modelagem econômica com referências da BCG e do Gartner. Não há indicação de medição independente que confirme a eficiência de tokens "comparável" atribuída ao progressive disclosure.
O MCP resolve prompt injection?
Não por si só. Ele estrutura a chamada e isola credenciais, mas descrições e retornos de ferramentas continuam sendo texto que o modelo lê. A defesa contra conteúdo malicioso depende de curadoria dos servidores e de controles adicionais.
Vale usar só CLI em produção?
Sim, se a produção tiver um único usuário, rodar isolada e não envolver credenciais de terceiros. Com múltiplos clientes, exigência de auditoria ou dados regulados, a recomendação do próprio artigo é a arquitetura híbrida.