O MCP morreu. Vida longa à CLI

• O MCP está perdendo rapidamente o interesse do setor e agora uma abordagem baseada em CLI é mais prática
• Os LLMs já são muito bons em usar ferramentas de linha de comando e, mesmo sem um protocolo separado, conseguem realizar tarefas apenas com documentação e CLI
• A CLI permite que humanos e LLMs executem e depurem no mesmo ambiente, o que simplifica a identificação da causa dos problemas
• Em termos de composabilidade, autenticação e confiabilidade, a CLI é mais eficiente que o MCP e mais fácil de manter
• O MCP causa atritos constantes no trabalho real, como inicialização instável, reautenticação repetitiva e ausência de controle de permissões
• Na maioria dos casos, a CLI é a opção mais simples e confiável, e as empresas devem priorizar oferecer APIs e CLIs antes de investir em servidores MCP

---

Limitações do MCP e vantagens da CLI

• Desde o anúncio do Model Context Protocol (MCP) pela Anthropic, o setor correu para construir servidores MCP, mas ferramentas importantes como OpenClaw e Pi não o suportam, e os benefícios práticos são limitados
  • Os LLMs já conseguem executar tarefas por meio de CLI e documentação
  • O MCP adiciona novos endpoints e um novo sistema de autenticação, mas apenas duplica funcionalidades existentes
• Os LLMs são otimizados para usar ferramentas de CLI e fazem isso com muita competência
  • Foram treinados com milhões de man pages, respostas do Stack Overflow e shell scripts no GitHub
  • Por exemplo, se você pedir ao Claude para executar um comando como gh pr view 123, ele faz isso diretamente
• O MCP prometia uma interface mais limpa, mas na prática ainda é necessário documentar da mesma forma a descrição de cada ferramenta, seus parâmetros e quando usá-la

A CLI também é útil para humanos

• A CLI permite que humanos e LLMs compartilhem os mesmos comandos
• Quando o Jira tem um comportamento inesperado, é possível reproduzir diretamente executando o mesmo comando jira issue view
• No MCP, as ferramentas existem apenas dentro da conversa com o LLM, então, quando algo dá errado, é preciso vasculhar logs de envio de JSON
• A depuração não deveria exigir um decodificador de protocolo
• Na CLI, entradas e saídas são claras, o que facilita rastrear problemas

Composabilidade

• A CLI pode ser combinada em pipelines com jq, grep, redirecionamento de arquivos e mais
• Exemplo de análise de um plano grande do Terraform:
  • terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
• Com MCP, seria necessário despejar o plano inteiro na janela de contexto (caro e muitas vezes inviável) ou implementar filtragem personalizada no próprio servidor MCP
• A abordagem com CLI aproveita ferramentas que já existem e são bem documentadas, compreensíveis tanto para humanos quanto para agentes

Problemas de autenticação

• O MCP é desnecessariamente opinionated em relação à autenticação
• Ferramentas de CLI já usam esquemas de autenticação comprovados: aws usa perfis e SSO, gh usa gh auth login, kubectl usa kubeconfig
• Seja com um humano usando diretamente ou com o Claude executando, aplica-se o mesmo fluxo de autenticação
• Se houver problemas de autenticação, é possível resolver com métodos já conhecidos como aws sso login e gh auth refresh, sem troubleshooting específico de MCP

Problemas operacionais: sem partes móveis

• Um servidor MCP local precisa iniciar e manter um processo separado e, no Claude Code, ele é criado como processo filho, o que às vezes causa problemas
• Ferramentas de CLI são apenas arquivos binários no disco, sem necessidade de processo em segundo plano, gerenciamento de estado ou procedimentos de inicialização

Incômodos no trabalho real

• Inicialização instável: como o servidor MCP às vezes não sobe, é frequente precisar reiniciar o Claude Code e tentar de novo após resetar o estado
• Reautenticação repetitiva: ao usar várias ferramentas MCP, cada uma exige autenticação, mas esse problema não existe em CLIs que usam SSO ou credenciais de longa duração
• Controle de permissões grosseiro: no Claude Code, é possível permitir ferramentas MCP pelo nome, mas não limitar a modo somente leitura nem definir faixas de parâmetros
  • Com CLI, é possível fazer controle granular de permissões, como permitir gh pr view e exigir aprovação para gh pr merge

Quando o MCP faz sentido

• O MCP pode ser adequado quando não existe nenhuma ferramenta equivalente em CLI
• Reconhece-se o valor de uma interface padronizada e a possibilidade de existirem casos de uso em que o MCP seja mais apropriado que a CLI
• Ainda assim, para a maioria das tarefas, a CLI é mais simples, mais rápida de depurar e mais confiável

Lição principal e pedido aos builders

• As melhores ferramentas são aquelas que funcionam tanto para humanos quanto para máquinas, e a CLI, após décadas de evolução de design, é componível, fácil de depurar e integrada aos sistemas de autenticação existentes
• O MCP tentou criar uma abstração melhor, mas já existia uma abstração boa o suficiente
• Empresas que investem em servidores MCP enquanto não têm uma CLI oficial deveriam repensar sua estratégia, e,
  se fornecerem uma boa API → uma boa CLI, os agentes vão aproveitar isso por conta própria
• Isso reduz complexidade desnecessária de protocolo e melhora produtividade e manutenção

[sonnet]

Não é que o MCP não tenha vantagens; o que aconteceu foi que acordamos da ilusão de usá-lo indiscriminadamente em casos em que suas vantagens não existem. Mesmo ao expor microsserviços para LLMs, você não vai usar CLI, e o MCP é um protocolo de "API".

[brainer]

Naquela época também dava para usar API. Na verdade, o motivo de terem usado MCP era por causa da limitação de contexto longo, mas agora essa limitação já foi superada em grande parte.

[jamsya]

Concordo demais.
Mesmo sem instalar o aws mcp, o Claude Code pega sozinho o que precisa usando o aws cli 😂

[GN⁺]

Comentários do Hacker News

• Evitei dizer isso por muito tempo, mas agora estou convencido de que o MCP não oferece vantagens práticas
  Opero agentes de IA que controlam todo o meu fluxo de trabalho de desenvolvimento por comandos de shell, e eles conseguem entender bem flags de CLI só com a saída de --help, mesmo quando veem essas flags pela primeira vez
  Já os servidores MCP sempre foram instáveis e exigiram manutenção
  A CLI pode ser combinada com jq, grep, redirecionamento de arquivos etc., enquanto o MCP fica preso ao formato retornado pelo servidor
  No fim, acho que a adoção de MCP é mais um sinal de marketing “AI-first” do que uma escolha técnica

  • O MCP cresceu rapidamente em 2024, mas vejo isso como um caso em que a meta mudou rápido no começo de 2025 com o surgimento de agentes de terminal (Claude Code)
  • Eu prefiro MCP. O tratamento de erros e a depuração são muito mais limpos do que na CLI, e dá para restringir flags perigosas ou dividir resultados com paginação
    Dá para entender o MCP simplesmente como um wrapper, como REST ou gRPC
  • Eu também evito MCP. Testei o JIRA MCP e foi uma bagunça. Em vez disso, deixar o LLM chamar a API diretamente e escrever scripts foi muito mais eficiente
    Hoje acho que as ferramentas CLI para LLM estão no topo
  • Na nossa empresa, expomos ferramentas só para web, como uma wiki interna, via MCP para que o Claude consulte logs e métricas diretamente
    Mas é incômodo que o resultado do MCP sempre entre na janela de contexto. Seria bom poder despejar isso no sistema de arquivos
  • Servidores MCP parecem um artefato transitório criado quando os LLMs eram menos avançados. Acho muito melhor treinar com dados de CLI

• O MCP parece uma API de caixa-preta que pode ser chamada na hora, sem instalação nem provisionamento de recursos
  Já a CLI consegue acessar o ambiente local e por isso é muito mais precisa
  Usando jq e a CLI do duckdb, faço amostragem de arquivos de dados grandes, e o Opus 4.6 ajusta automaticamente as consultas enquanto explora
  A CLI tem ótima responsividade em tempo real, então é especialmente útil para análise exploratória de dados
  CLIs que uso com frequência incluem showboat, br, psql e roborev

  • Tive a mesma experiência. A entrada e saída em texto da CLI se encaixam melhor na forma como os LLMs são treinados
    Gostei muito de usar duckdb com o ChatGPT, mas fico curioso se você configura o prompt de sistema para manter um banco local
  • Em vez de CLI, também dá para executar comandos em contêineres Docker e evitar problemas de instalação. Talvez desse até para criar uma “skill” que automatize essa abordagem
  • Como falante não nativo de inglês, acho engraçado usar o plural como em MCPs

• O MCP faz sentido quando você descobre ferramentas que não existem na CLI e as invoca de forma contextual
  Por exemplo, meu echomindr fornece via MCP um banco de dados que extrai decisões de fundadores a partir de podcasts
  Quando o Claude recebe perguntas sobre startups, ele pesquisa experiências reais de fundadores para responder
  A CLI é adequada quando a pessoa já sabe qual ferramenta usar, enquanto o MCP é melhor para seleção de ferramentas por descoberta

• Parece que o autor olhou para o uso de IA apenas do ponto de vista de desenvolvedores
  A maioria dos usuários usa LLMs por interfaces web como o ChatGPT
  Do ponto de vista das empresas, o MCP é muito mais adequado para conectar ferramentas de marketing, vendas e gestão de projetos

• O MCP em si não é ruim, mas o stdio MCP é excessivamente projetado
  Em vez disso, o modelo Streamable HTTP + OAuth Discovery é hoje a forma mais eficiente de integração com IA
  Por exemplo, o Sentry MCP permite autenticação e acesso a dados com uma única URL
  O problema é a forma de implementação do MCP. Em vez de chamar via bash, se você expuser o MCP como endpoint HTTP, ele funciona de forma muito mais flexível

  • Tanto CLI quanto MCP precisam ter um sistema de permissões projetado de forma consistente no nível da API. A parte de Streamable HTTP precisa de mais explicação
  • Também penso assim. Autenticação e telemetria centralizadas são muito mais simples. Só é preciso usar isso para os casos certos

• Alguns dos meus clientes não têm servidor MCP, mas os desenvolvedores pedem isso
  No fim, exportamos a API do Postman em JSON e entregamos assim, mas os desenvolvedores queriam um servidor MCP
  A realidade é que ter suporte a MCP funciona como item de checklist de marketing

• Este blog parece enviesado para a perspectiva de desenvolvedores
  Ao conectar ferramentas ou serviços voltados a não desenvolvedores, o MCP é muito mais natural

  • Exato. Numa interface de chat não dá para executar CLI, e serviços voltados a não desenvolvedores nem sequer têm CLI
  • Eu também me perguntava se dá para rodar CLI em interfaces web e mobile como ChatGPT ou LeChat
  • Interfaces para não desenvolvedores já estão evoluindo para formatos como OpenClaw e Claude Cowork

• Vagas como “procuramos alguém com 5 anos de experiência em MCP” acabaram virando um meme sem sentido

• Uma das razões pelas quais a CLI é melhor que o MCP é que ela tem um formato otimizado do ponto de vista da teoria da informação
  A saída de ferramentas Unix coloca informações relacionadas próximas entre si, então o mecanismo de atenção do LLM funciona de forma eficiente
  JSON é fácil de fazer parse, mas desconfortável para ler e raciocinar
  O formato de CLI é intuitivo tanto para humanos quanto para LLMs
  Referência relacionada: Entropy and Information Layout

• Comparar MCP com CLI é como comparar OpenAPI e strings (JSON)
  O MCP é formalmente definido, enquanto a CLI é uma interface abstrata no nível de (String, List String, Map Int Stream) -> PID
  No fim, ambos são apenas APIs, e o importante é escolher a ferramenta adequada para alcançar o objetivo

  • Mas a CLI fornece documentação completa com --help, então, se o LLM consegue entender isso, fica difícil dizer que a padronização do MCP é melhor
  • Mais importante do que teoria é a experiência de uso real. Para dizer que MCP e CLI são iguais, seria preciso montar um exemplo mostrando, por exemplo, que a CLI e o MCP do Playwright têm o mesmo consumo de tokens e configurabilidade
    Caso contrário, na prática você vai sentir diretamente que as duas abordagens são diferentes

[develosopher]

Se alguém desenvolveu um SaaS e estiver em dúvida entre cli e MCP para integração com IA, provavelmente vai escolher MCP primeiro. Dar suporte a CLI significa aumentar os pontos de manutenção. Eles podem coexistir, mas não parece que algum deles vá desaparecer.

[hanje3765]

Parece que, à medida que a inteligência dos LLMs aumenta, a necessidade do MCP fica mais nebulosa.
Eu também tenho sentido isso na prática.

[m00nlygreat]

Parece que a organização está ficando assim: execução remota com MCP, execução local com skills.

[hulryung]

Eu também comecei a criar e usar minhas próprias ferramentas direto pela CLI, em vez de usar MCP.