- A CLI surgiu como a nova tendência para interfaces de ferramentas de agentes, mas CLIs personalizadas também sofrem do mesmo problema de contexto do MCP e precisam abrir mão de estruturação e de várias vantagens
- O MCP em modo local
stdio e o MCP remoto baseado em Streamable HTTP atendem a casos de uso completamente diferentes, e essa distinção está sendo ignorada no debate atual
- Os recursos de Prompts e Resources do MCP funcionam como um mecanismo para distribuir habilidades e documentação padronizadas em tempo real para toda a organização, sendo centrais na transição de vibe coding para engenharia agentic sistemática
- Servidores MCP centralizados padronizam autenticação OAuth, telemetria e observabilidade, possibilitando segurança em nível organizacional e medição da eficácia das ferramentas
- Para desenvolvedores individuais, a CLI pode ser adequada, mas em escala organizacional e enterprise o MCP é a ferramenta do presente e do futuro para garantir consistência, segurança e qualidade
Ciclo de hype liderado por influenciadores
- Até 6 meses atrás, o Model Context Protocol (MCP) era o maior assunto da indústria, e todo fornecedor queria lançar produtos relacionados ao MCP
- Já naquela época havia ceticismo do tipo “é só uma API, por que precisamos de um wrapper?”, e de fato existiam equipes que pularam o ciclo de hype do MCP e optaram por escrever wrappers de ferramenta simples sobre endpoints REST API
- Em muitos casos de uso, espalhou-se a percepção de que o MCP era um overhead desnecessário em comparação com chamar a API diretamente
- Agora o discurso da indústria mudou para críticas ao MCP e exaltação da CLI, o que também se relaciona com a dinâmica em que influenciadores de IA precisam criar constantemente novas tendências para manter a atenção
- Até nomes conhecidos como Garry Tan e Andrew Ng tendem a generalizar experiências pessoais, e a cultura de influenciadores que gera FOMO e hype está distorcendo o debate nesse campo
- De fato há casos em que a CLI é mais apropriada como interface de ferramentas para agentes, mas isso não vale para todos os casos
Economia de tokens com CLI: realidade e limites
Ferramentas CLI presentes nos dados de treinamento
- Utilitários CLI como
jq, curl, git, grep, psql e aws, que já estão incluídos no dataset de treinamento dos LLMs, podem ser usados imediatamente pelo agente sem instruções adicionais, schema ou contexto
- Como o MCP precisa declarar previamente as ferramentas na resposta
tools/list, há overhead em relação a ferramentas CLI que o modelo já conhece
- Se a ferramenta CLI já está nos dados de treinamento, faz sentido sempre priorizá-la em vez do MCP
Limites de CLIs personalizadas
- Ferramentas CLI personalizadas (bespoke) não têm como ser compreendidas pelo LLM sem orientação, então é preciso fornecer explicações em
AGENTS.md ou README.md
- Dá para apontar um diretório
/cli-tools e confiar em nomes descritivos, mas o agente costuma errar com frequência dessa forma, e no fim são necessários mais documentos explicativos
- Mesmo ferramentas como
curl perdem a vantagem de economia de tokens no momento em que precisam entender um schema OpenAPI personalizado
Extração e transformação em cadeia
- Cadeias de CLI podem buscar e transformar dados antes de colocá-los na janela de contexto, reduzindo o volume de dados enviado
- Porém, conteúdos formatados como HTML, JSON e XML também podem ser extraídos com seletores como DOM/CSS, JSONPath e XPath, então isso não é uma vantagem exclusiva da CLI
Consumo progressivo de contexto
- Enquanto o MCP pré-carrega todo o conjunto de ferramentas e schemas, a CLI pode carregar contexto de forma progressiva via
--help
- Mas, no caso de ferramentas CLI personalizadas, o agente precisa explorar o conteúdo de help ao longo de vários turnos e, no fim, acaba carregando informações semelhantes ao schema do MCP, só que sem estrutura
- Em fluxos complexos o bastante, o agente acaba explorando quase toda a árvore, e o ganho de economia se torna pequeno
- Pesquisas da Vercel mostraram que, quando todo o índice de documentação foi colocado em
AGENTS.md, o uso da documentação pelo agente melhorou; fornecer o schema completo de antemão favorece a escolha correta da ferramenta
- Num cenário em que a Anthropic já oferece janela de contexto de 1 milhão de tokens, fica a dúvida se economia de tokens ainda é um argumento decisivo
A dualidade do MCP: stdio vs Streamable HTTP
Limites do modo stdio
- No modo
stdio, o servidor MCP roda localmente junto com o agente, acrescentando complexidade desnecessária em comparação com escrever uma CLI simples
- Na maioria dos casos de uso, o MCP em modo
stdio é desnecessário
O valor transformador do Streamable HTTP
- O MCP com transporte Streamable HTTP permite executar a mesma lógica em um servidor centralizado, sendo um elemento central para transformar vibe coding em engenharia agentic na adoção organizacional e enterprise
- A maioria dos influenciadores não consegue distinguir esses dois modos
Vantagens de um servidor MCP centralizado
Funcionalidades ricas de backend
- Em um servidor central, as ferramentas podem aproveitar recursos avançados da plataforma, como instâncias Postgres ou consultas de grafo Cypher baseadas em Apache AGE
- Do lado do agente, basta configurar o endpoint HTTP e o token de autenticação, o que simplifica a implantação
- Bancos locais como SQLite também são possíveis, mas têm limites quando se trata de compartilhar estado em toda a organização
Runtime efêmero de agentes
- Em ambientes de runtime efêmero como GitHub Actions, é possível usar ferramentas que dependem de backends complexos via servidores MCP remotos, sem instalação
- Isso delega ao servidor central o gerenciamento de workloads com estado em ambientes stateless
Autenticação e segurança
- Para acessar APIs seguras via CLI, todos os desenvolvedores precisam de acesso direto às chaves de API, o que vira um grande peso para a equipe de operações
- Com a centralização atrás de um servidor MCP, os desenvolvedores se autenticam no servidor MCP com OAuth, enquanto chaves de API e segredos sensíveis ficam controlados atrás do servidor
- Quando alguém sai da equipe, basta revogar o token OAuth; essa pessoa nunca teve acesso direto a outras chaves e segredos
Telemetria e observabilidade
- Em um servidor MCP centralizado, é possível coletar traces e métricas com OpenTelemetry usando ferramentas padrão
- Assim dá para entender quais ferramentas são eficazes, quais runtimes de agentes estão sendo usados e onde ocorrem falhas
- Também é possível fazer isso com ferramentas CLI, mas distribuição local exige atualização do lado do consumidor e é preciso reproduzir o scaffolding de telemetria em cada CLI
Implantação padronizada imediata e atualizações automáticas
- Ferramentas distribuídas como pacotes geram problemas de compatibilidade de versão de API, mas no MCP o servidor pode avisar o cliente sobre atualizações por meio de Subscriptions e Notifications
- MCP Prompts equivalem a um
SKILL.md entregue pelo servidor, e MCP Resources equivalem a um /docs entregue pelo servidor
O valor organizacional de MCP Prompts e Resources
- Conteúdo dinâmico: arquivos
*.md em repositórios são arquivos estáticos que exigem atualização manual, mas prompts e resources baseados em servidor podem ser gerados dinamicamente em tempo real
- Documentação útil apenas em certos contextos, dados de preço e estado atual do sistema podem ser injetados dinamicamente sem chamada de ferramenta
- Atualizações automáticas com consistência: arquivos
*.md distribuídos por repositório ou pacote precisam de sincronização, mas quando entregues como prompts MCP permanecem sempre atualizados
- Até documentação oficial de terceiros pode ser proxyada via servidor, eliminando a necessidade de copiar e atualizar manualmente no repositório
- Compartilhamento de conhecimento em toda a organização: conteúdos aplicáveis à organização inteira, como segurança, boas práticas de telemetria e considerações sobre deploy de infraestrutura, podem ser distribuídos de forma consistente para todos os repositórios, todos os workflows e todos os frontends de agentes (Claude Code, Codex, VS Code Copilot, GitHub Agents, OpenCode etc.)
- Em ambientes de microsserviços, também é possível que uma equipe acesse a documentação de outro serviço ou que a equipe de um serviço forneça skills dinamicamente a cada deploy
- Já há casos confirmados de funcionamento real de prompts e resources MCP em OpenCode e Claude Code CLI, e com apenas a configuração do cliente MCP não é necessário gerenciamento adicional após o deploy
Conclusão: em nível organizacional, o MCP é o presente e o futuro
- Há 6 meses o MCP era o grande tema do momento; hoje é criticado como principal causa de inchaço de contexto, mas os trade-offs e armadilhas semelhantes das CLIs personalizadas estão sendo ignorados
- Quando uma equipe pensa em como fazer a transição de vibe coding para engenharia agentic, ela naturalmente chega ao desenho e à missão do MCP
- Como mostra um caso recente na divisão AWS da Amazon (exigindo aprovação de engenheiros seniores para mudanças assistidas por IA), as equipes inevitavelmente terão de operar e manter sistemas de software produzidos por agentes de IA
- Os conselhos de Garry Tan e Andrew Ng podem valer em ambientes individuais homogêneos, mas são difíceis de aplicar diretamente em contextos organizacionais nos quais equipes com diferentes níveis técnicos e de experiência precisam convergir para qualidade consistente
- Para lançar software confiável e sustentável, é necessária uma disciplina de engenharia que garanta consistência, segurança, qualidade e precisão — e, para isso, o MCP é hoje a ferramenta adequada para organizações e empresas
6 comentários
CLI é uma ferramenta local, e MCP é um servidor, então os casos de uso são bem diferentes.
Não seria a mesma coisa rodar a CLI no servidor?
MCP reencarnado!
Documento relacionado: MCP está morto. Viva o CLI
Seria ótimo se a discussão sobre algum tipo de recurso de sandbox para CLI avançasse a ponto de permitir o uso de ferramentas de CLI também em apps móveis; ao tentar compatibilizar com dispositivos móveis de verdade, no fim parece que o principal gargalo é justamente o sandboxing.
Comentários no Hacker News
Tenho a impressão de que a maioria dos recursos de integração com IA que surgem hoje em dia é mal projetada.
Nem os comandos básicos foram padronizados, e em vez de documentação só há ajuda imprecisa gerada por LLM por toda parte.
No fim, parece que esses chamados “padrões de IA” vão surgir e desaparecer repetidamente. LLMs são essencialmente baseados em texto, então é difícil que operem com a precisão de um protocolo de rede. Esse tipo de engenharia centrada em texto acaba criando uma pirâmide de abstrações instável.
Acho que a estrutura mais útil entre as ferramentas de IA é envolver agentes probabilísticos com barreiras determinísticas.
Por isso eu uso MCP sobre HTTP. Por exemplo, o NanoClaw reforça a segurança ao filtrar mensagens do WhatsApp de forma determinística e fazer proxy de chaves de API. Esse tipo de arquitetura torna a IA mais confiável.
Essa estrutura oferece segurança e facilidade de gestão elevadas, e ainda permite gerar automaticamente CLIs a partir de um catálogo de ferramentas.
Um exemplo de implementação pode ser visto em smith-gateway
O núcleo open source pode ser visto em tenuo
O MCP separa com clareza a tomada de decisão da IA da execução determinística do sistema. Eu uso Claude Code com servidores MCP, e isso é muito eficiente: a IA cuida da resolução criativa de problemas, enquanto a execução segue caminhos previsíveis.
MCP é uma especificação de protocolo fixa para comunicação entre apps de IA.
Em vez de forçar o acoplamento de APIs entre aplicativos, como nas “integrações” tradicionais, ele oferece uma abstração de comunicação reutilizável como HTTP, FTP ou SMTP.
Acho que, para a IA interagir com serviços variados, é necessária uma linguagem comum desse tipo.
A especificação pode ser vista em modelcontextprotocol.io/specification/2025-11-25
Na prática, o que se precisa não é de um novo protocolo, mas de especificações de CLI ou API exploráveis de forma incremental. O argumento é que MCP é apenas uma solução provisória da época em que os primeiros agentes não conseguiam executar CLI.
Nessa visão, MCP é no fim das contas uma solução temporária para a imaturidade técnica.
Quando o MCP apareceu pela primeira vez, me pareceu um lixo excessivamente projetado, então não dei atenção.
Até hoje não me arrependo. O mesmo vale para LangChain. Seguir algo só porque está popular é arriscado.
Com um investimento de tempo mínimo, dá para obter um ganho enorme de eficiência.
Às vezes uma ferramenta tosca sobrevive justamente por simplificar um problema complexo de integração.
Se você ignorá-la só porque parece feia no começo, pode perder a chance de reconhecer uma futura infraestrutura padrão.
Nessa leitura, não se trata de overengineering, mas de uma estrutura clara e intuitiva.
O MCP remoto é razoável por facilitar o acesso a serviços, já que a autenticação é tratada automaticamente.
Mas, em comparação com a combinação de CLIs + Skills, ele traz muita sobrecarga de contexto (context bloat), além de perder vantagens do Unix CLI, como processamento em pipeline e entrada via heredoc.
Com CLIs, dá para gerar skills automaticamente a partir da saída de
--help, o que é eficiente.O MCP exige um processo persistente, enquanto uma CLI pode ser executada apenas quando necessário.
Ainda acho que o MCP é uma camada desnecessária.
Concordo que CLI > MCP, mas os benefícios de documentação e centralização podem ser resolvidos de outras maneiras.
Por exemplo, usando Skills, é possível incluir instruções tanto para CLI quanto para API, e carregá-las só quando necessário.
As vantagens de um MCP centralizado também podem, na prática, ser implementadas suficientemente com proxies existentes ou AWS SSO.
No fim, acho melhor documentar com Skills e deixar a interação real por conta de CLI ou REST API.
O argumento é que o conteúdo de Skills acaba sendo incluído no contexto e gerando sobrecarga, e que um proxy não consegue substituir completamente os recursos do MCP.
O MCP permite ativar prompts e recursos com comandos
/e referências@, algo que um proxy não consegue fazer.Uma demo relacionada pode ser vista nos .gif do fim do texto e na especificação do MCP.
Tenho a impressão de que o MCP é mais adequado para ambientes de consumo.
Em ambientes de desenvolvimento ele é complexo e ineficiente, mas para usuários comuns o MCP facilita entender quais funções o modelo pode executar.
Não exige configuração de ambiente, e numa GUI é possível visualizar as respostas como no Siri ou no Google Assistant.
Do ponto de vista de quem fornece ferramentas de IA para usuários não desenvolvedores dentro de empresas, a abordagem centralizada com MCP foi muito útil.
Deu para gerenciar de forma consistente tom de marca, terminologia interna, acesso a dados compartilhados e contexto de domínio.
Por meio dos métodos de recursos do MCP, foi possível oferecer “skills” padronizadas e controlar os padrões de conexão com dados.
O autor observa vários conceitos por diferentes ângulos, mas parece não conhecer conceitos já existentes como Token Notation (TOON).
Fica a impressão de que ele deseja a existência de algo que, na verdade, já existe.
O verdadeiro problema do MCP é o custo de manutenção.
Por exemplo, se você precisa de integração com o GitHub, acaba dependendo de um wrapper npm em vez de usar uma API já bem documentada.
Eu simplesmente uso
ghCLI oucurl. Se a API muda, o agente lê a nova documentação e se adapta.Com MCP, é preciso esperar até que o wrapper intermediário seja atualizado.
A alegação de segurança também é contraditória — ele surgiu sem autenticação e agora vende segurança como vantagem.
Na prática, isso é um problema que abordagens antigas como chroot ou scoped token já resolviam.
O único ponto em que o MCP realmente leva vantagem é no fluxo OAuth para não desenvolvedores. Para ferramentas de desenvolvedor, acho melhor simplesmente criar CLIs melhores.