Vamos Colocar um Fim ao Debate MCP vs CLI (EU GANHEI)

Um debate estruturado que resolve o argumento mais quente sobre a arquitetura de agentes de IA de 2026.

No final de fevereiro de 2026, Eric Holmes publicou "MCP está morto. Viva o CLI" e isso atingiu a primeira página do Hacker News como uma granada. Garry Tan, CEO da YC, seguiu no X com um "MCP é uma droga, honestamente." A comunidade de agentes de IA se dividiu em dois grupos da noite para o dia.

Um lado diz que o MCP (Modelo de Protocolo de Contexto) é uma abstração desnecessária. O outro diz que cada grande empresa de tecnologia já se comprometeu com isso. Benchmarks foram lançados. Posts de blog se multiplicaram. Todo mundo tinha uma opinião.

Então, debatemos isso — de forma adequada. Ponto a ponto, afirmação por afirmação, até que não houvesse mais nada a discutir. Aqui está como tudo aconteceu e onde chegamos.

Os Números Que Começaram a Guerra

Antes das opiniões, os dados. Benchmarks recentes pintam um quadro claro:

A Perplexity retirou publicamente o MCP de sua arquitetura de agentes. Benchmarks internos mostraram uma sobrecarga de 15-20x de tokens para tarefas equivalentes. Isso não é um erro de arredondamento. Essa é uma estrutura de custo fundamentalmente diferente.

Rodada 1: O Argumento de Segurança

A afirmação do MCP: Dar a um agente acesso direto ao banco de dados é perigoso. Um servidor MCP somente leitura é inerentemente mais seguro do que entregar ao agente uma conexão psql.

A resposta do CLI: Construa um wrapper CLI.

#!/bin/bash
# mydb — um wrapper CLI somente leitura
psql -h $DB_HOST -U readonly_user --set=ON_ERROR_STOP=on -c "$1"

Mesma segurança. Fração dos tokens. Levou 30 segundos para escrever. O servidor MCP que resolve esse problema é uma camada de transporte JSON-RPC, definições de esquema, negociação de capacidade e um processo de longa duração — tudo envolvendo a mesma chamada psql por baixo.

Veredicto: CLI vence. O wrapper é trivialmente simples e estritamente mais barato de construir e executar.

Rodada 2: Autenticação Multi-Tenant

A afirmação do MCP: CLI é de usuário único. O MCP lida com OAuth, autenticação dinâmica entre múltiplos usuários, SSO empresarial. Você precisa do MCP para multi-tenancy.

A resposta do CLI: Temos autenticação multi-tenant CLI há anos.

• aws sts assume-role — credenciais com escopo entre contas
• gcloud auth login --account — multi-identidade
• docker context use — alternar entre ambientes
• terraform workspace select — estado isolado por inquilino
• kubectl config use-context — troca de cluster

Essas ferramentas atendem milhões de usuários em milhares de organizações. O problema multi-tenant é resolvido no nível do SO e das credenciais, não no nível do protocolo.

Veredicto: CLI vence. A infraestrutura de autenticação testada em batalha já existe. O MCP reinventa isso com menos maturidade.

Rodada 3: Fluxos de Trabalho Complexos

A afirmação do MCP: CLI desmorona para fluxos de trabalho complexos e de múltiplas etapas. O protocolo estruturado do MCP lida melhor com a orquestração.

A resposta do CLI: O que é mais complexo do que ffmpeg?

ffmpeg -i input.mp4 -filter_complex \
  "[0:v]split=2[v1][v2]; \
   [v1]crop=iw/2:ih:0:0[left]; \
   [v2]crop=iw/2:ih:iw/2:0[right]; \
   [left][right]hstack" \
  -c:v libx264 -crf 23 output.mp4

Se um agente de IA pode compor pipelines ffmpeg com filtros, codecs, mapeamento de streams e gráficos de filtros complexos — um dos CLIs mais notoriamente complexos já construídos — então "CLI não pode lidar com fluxos de trabalho complexos" está morto na chegada.

Pipes e composição do Unix (|, &&, >, <()) têm orquestrado fluxos de trabalho complexos desde antes da maioria de nós nascer.

Veredicto: CLI vence decisivamente. A complexidade é o território natal do CLI.

Rodada 4: Descoberta de Ferramentas

A afirmação do MCP: Agentes não conseguem descobrir ferramentas CLI desconhecidas. O tools/list do MCP fornece um esquema estruturado em tempo de execução. O CLI não tem equivalente.

A resposta do CLI: --help tem sido o mecanismo universal de descoberta por décadas. Funcionou para humanos. Funciona para agentes.

$ gh --help
Trabalhe perfeitamente com o GitHub a partir da linha de comando.

USO
  gh <comando> <subcomando> [flags]

COMANDOS PRINCIPAIS
  pr:       Gerenciar pull requests
  issue:    Gerenciar issues
  repo:     Gerenciar repositórios
  ...

CLIs amigáveis para agentes estão agora surgindo que otimizam a saída do --help para eficiência de tokens — descrições compactas, listagens de flags estruturadas, ruído mínimo. A nova geração de CLIs é construída com agentes como usuários de primeira classe.

E aqui está a pegadinha: a saída do --help é extremamente inconsistente entre as ferramentas, sim. Mas os esquemas do MCP também são inconsistentes — apenas consistentemente verbosos. Um esquema inchado não é melhor do que um --help conciso.

Veredicto: Aproximadamente igual, mas o CLI tem a vantagem no custo de tokens. A descoberta via --help é "boa o suficiente" e custa tokens apenas quando necessário, não antecipadamente.

Rodada 5: Quem Constrói a Integração?

A afirmação do MCP: Alguém constrói um servidor MCP uma vez, publica e qualquer agente compatível com MCP pode usá-lo. É uma interface padrão. Construa uma vez, use em qualquer lugar.

A resposta do CLI: Este argumento contém sua própria refutação.

"Alguém constrói um servidor MCP" — sim, um desenvolvedor humano. Esse mesmo desenvolvedor poderia construir um CLI em menos tempo e com menos complexidade. Um servidor MCP é estritamente mais trabalho: é um CLI mais um transporte JSON-RPC, definições de esquema, negociação de capacidade e um processo de servidor de longa duração.

E "qualquer agente compatível com MCP" é na verdade um público mais restrito do que "qualquer agente com acesso ao shell." Todo agente na terra pode chamar um binário. Nem todo agente fala MCP.