MCP Morreu; Vida Longa ao MCP — Por Que o Debate CLI vs Protocolo Erra o Alvo

A reação chegou no prazo previsto.

Depois de um ano de adoção frenética do MCP, o pêndulo oscilou. Vozes influentes agora declaram o Model Context Protocol morto na chegada, argumentando que ferramentas CLI simples são mais baratas em tokens e mais eficazes. Basta usar jq com pipe para curl e pular o overhead do protocolo.

Eles não estão errados. Também não estão certos. Estão respondendo a pergunta errada.

A análise recente de Charles Chen faz a distinção que o debate vinha ignorando: uso individual é diferente de adoção organizacional. O que funciona para um desenvolvedor solo em um ambiente homogêneo não se sustenta para times e organizações em ambientes heterogêneos.

O debate MCP vs CLI não é sobre protocolos. É sobre quem controla as ferramentas, quem vê a telemetria e quem é dono da camada de governança.

Onde CLIs Vencem

O argumento pró-CLI tem mérito técnico legítimo.

Vantagem dos dados de treino. Ferramentas como jq, curl e git aparecem extensivamente nos dados de treino dos modelos. Agentes já sabem usá-las. Sem carregamento de schema, sem overhead de descoberta de ferramentas, sem contexto consumido por descrições.

Extração encadeada. Pipes Unix permitem que agentes transformem dados progressivamente, descartando contexto irrelevante a cada passo. Uma cadeia grep | awk | sort pode reduzir megabytes às três linhas que importam.

Revelação progressiva. A saída de --help do CLI carrega sob demanda. O agente descobre capacidades incrementalmente em vez de ingerir um schema inteiro de ferramentas logo de início.

Para um desenvolvedor individual rodando Claude Code ou Cursor contra um codebase local, CLIs frequentemente são a escolha certa. Menos overhead, menos partes móveis, iteração mais rápida.

Esse não é o cenário que a maioria das organizações enfrenta.

A Distinção Que Ninguém Está Fazendo

O debate atual confunde dois modelos de deploy do MCP fundamentalmente diferentes:

MCP sobre stdio roda localmente, na mesma máquina, no mesmo limite de processo. É essencialmente um wrapper estruturado para ferramentas locais. Para esse caso de uso, um CLI é mais simples e o wrapper adiciona atrito sem valor proporcional.

MCP sobre HTTP roda remotamente, centralizado, compartilhado entre times e ambientes. Chen chama isso de “um divisor de águas absoluto”, e as razões não são sobre experiência do desenvolvedor. São sobre governança.

Todo o debate CLI-vs-MCP foi conduzido da perspectiva do stdio. É como avaliar Kubernetes rodando um único container no seu laptop.

Cinco Funcionalidades de Governança Disfarçadas de Funcionalidades de Protocolo

1. Segurança Centralizada

Com ferramentas CLI, cada desenvolvedor precisa de chaves de API, credenciais de banco de dados e tokens de serviço distribuídos no seu ambiente local. Cada laptop é uma superfície de ataque. Cada funcionário que sai é um evento de rotação de credenciais.

MCP sobre HTTP centraliza a autenticação. OAuth substitui segredos distribuídos. O agente conecta ao servidor; o servidor mantém as credenciais. Revogação é uma operação única. Auditoria é um log único.

Isso não é uma funcionalidade de conveniência. É uma decisão de arquitetura de segurança.

2. Telemetria em Escala Organizacional

Quando ferramentas rodam localmente via CLI, a organização não tem visibilidade sobre o que os agentes estão fazendo. Quais ferramentas produzem saídas úteis? Quais geram alucinações? Onde as falhas se concentram? Quanto os agentes estão realmente sendo usados?

Servidores MCP com OpenTelemetry respondem todas essas perguntas a partir de um único ponto de instrumentação. A telemetria existe porque o tráfego é centralizado. Nenhum scaffolding adicional necessário.

Uma organização não pode governar o que não consegue observar.

3. Compatibilidade com Runtimes Efêmeros

Agentes no GitHub Actions, pipelines CI/CD, funções cloud — esses ambientes são efêmeros. Instalar ferramentas CLI, configurar ambientes e gerenciar dependências em cada runtime é overhead de engenharia que escala linearmente com o número de ambientes.

Um servidor MCP é uma URL. O agente efêmero conecta, usa as ferramentas, desconecta. Sem instalação. Sem configuração de ambiente. Sem gestão de dependências.

4. Entrega Dinâmica de Conteúdo

Os prompts e resources do MCP são funcionalidades sem equivalente em CLI. Prompts entregam habilidades padronizadas de planejamento. Resources entregam documentação. Ambos atualizam em tempo real sem sincronização no cliente.

Quer que cada agente em cada time use o mesmo playbook de resposta a incidentes? Atualize o resource do MCP uma vez. Cada agente conectado recebe a versão atual na próxima requisição. Sem git pulls, sem fixação de versão, sem drift.

Essa é a diferença entre distribuir conhecimento e centralizá-lo.

5. Interfaces Padronizadas de Ferramentas

Exploramos em MCP Design Patterns como o design do servidor determina a eficácia do agente. O mesmo princípio se aplica na escala organizacional: interfaces padronizadas de ferramentas significam comportamento padronizado de agentes.

CLIs não têm contrato de interface além do texto de --help. Cada ferramenta tem suas próprias convenções, seu próprio formato de saída, seus próprios padrões de tratamento de erro. Um agente precisa aprender cada uma individualmente.

MCP fornece schemas estruturados, argumentos tipados, valores de retorno documentados. O contrato de interface é legível por máquina e aplicável. Quando a organização decide mudar como uma ferramenta se comporta, a mudança se propaga pelo schema, não pela esperança.

A Comparação Real

Dimensão	Ferramentas CLI	MCP sobre HTTP
Custo em tokens	Menor para ferramentas conhecidas	Schema inicial maior
Complexidade de setup	Por ambiente	Uma vez, centralizado
Modelo de segurança	Segredos distribuídos	OAuth centralizado
Telemetria	Nenhuma por padrão	Embutida com OTel
Atualização de conteúdo	Git pull / redeploy	Tempo real no servidor
Governança	Manual, por ferramenta	Estrutural, nível de protocolo
Melhor para	Desenvolvedores individuais	Times e organizações

A economia de tokens dos CLIs é real mas modesta — e desaparece quando agentes precisam interpretar schemas OpenAPI customizados ou navegar workflows complexos com múltiplas ferramentas. As vantagens de governança do MCP são estruturais e se acumulam ao longo do tempo.

O Sinal da Amazon

A Amazon agora exige que engenheiros seniores aprovem mudanças de código assistidas por IA após uma série de incidentes. Essa é a trajetória inevitável: organizações precisarão operacionalizar e manter os sistemas de software que seus agentes de IA produzem.

Essa operacionalização requer visibilidade. Visibilidade requer telemetria. Telemetria requer centralização. Centralização é o que MCP sobre HTTP fornece.

A abordagem CLI dá velocidade ao desenvolvedor individual. A abordagem MCP dá controle à organização. Ambas são válidas. Servem a mestres diferentes.

Não Morreu. Diferenciou-se.

MCP não morreu. Está sendo avaliado por pessoas resolvendo problemas individuais e considerado insuficiente para esse caso de uso. Essa avaliação está correta dentro do seu escopo e é irrelevante fora dele.

As organizações que terão sucesso com agentes de IA não são as que economizam mais tokens por requisição. São as que sabem o que seus agentes estão fazendo, podem controlar como fazem, e conseguem provar conformidade quando perguntadas.

Isso requer um protocolo. Não um pipe.

Fontes

Chen, Charles. “MCP is Dead; Long Live MCP!” chrlschn.dev, Março 2026.
Especificação MCP (2025-11-25): prompts e resources.
Ars Technica. “Amazon exige aprovação de engenheiros seniores para código assistido por IA.” Março 2026.

Victorino Group ajuda organizações a implementar MCP com a camada de governança que faz a entrega centralizada de ferramentas valer o overhead do protocolo: contato@victorino.com.br | www.victorino.com.br