O MCP foi declarado morto depois de uma onda de posts afirmando que as CLIs saem mais baratas para agentes de IA. Este artigo analisa os números reais de tokens, os prós e contras de segurança e os casos em que cada abordagem vence, para você escolher a certa para o seu projeto.
Em março de 2026, Denis Yarats, CTO da Perplexity, disse que a empresa estava se afastando do MCP internamente e passando a usar APIs diretas e ferramentas de linha de comando. Uma publicação sobre isso viralizou, e em poucos dias o veredito estava em toda parte: MCP está morto. Desenvolvedores compartilharam capturas de tela de listas de ferramentas consumindo sua janela de contexto, e as respostas estavam cheias de comandos de shell de uma linha fazendo o mesmo trabalho em uma fração do espaço.
Então algo estranho aconteceu. O protocolo não morreu. Ele continuou lançando novos servidores, continuou conquistando o apoio dos maiores nomes da IA e agora está sob a tutela da Linux Foundation. Então, qual é a verdade?
Este artigo separa o ruído dos números. Você verá o que o MCP realmente faz, onde as reclamações sobre tokens são justas, por que as CLIs parecem tão naturais para agentes de programação e onde um terminal simplesmente não consegue fazer o trabalho. Ao longo do texto, há uma tabela de decisão que você pode usar hoje e uma seção curta sobre como testar as duas abordagens com o conector MCP e a API REST do próprio PicassoIA.
💡 Resposta curta: o MCP não está morto, mas a forma preguiçosa de usá-lo, sim. Carregar cem definições de ferramentas logo no início é um problema de design, não um problema do protocolo.
A faísca foi uma declaração curta com um longo desdobramento. O CTO da Perplexity disse que a empresa estava saindo do MCP em suas ferramentas internas e voltando para APIs diretas e CLIs. Posts com títulos como "MCP está morto" e "MCP vs CLI" surgiram em poucas semanas, e o argumento se polarizou em dois grupos.
Nenhum desses posts foi um veredito oficial. Eram opiniões, e vários estavam respaldados por benchmarks reais mostrando grande economia de tokens quando um agente executa um comando em vez de carregar um servidor de protocolo. As reclamações eram justas. A afirmação de que o protocolo inteiro está acabado era grande demais para as evidências.
Os números que circularam eram impressionantes. Uma comparação de automação de navegador relatou cerca de 52.000 tokens para ler uma página de produto por meio de um snapshot MCP, contra cerca de 1.200 tokens para algumas consultas pontuais na linha de comando. Outro benchmark, listando dispositivos em uma ferramenta administrativa da Microsoft, relatou cerca de 35 vezes menos tokens com uma CLI. Trate números como esses como indicativos, já que dependem do servidor, da tarefa e do cliente. Mas a direção é difícil de contestar: um servidor inchado é caro.
Descontando as opiniões inflamadas, restam quatro reclamações:
git, curl, grep e docker em incontáveis exemplos, então os chamam bem sem instruções extras.Cada ponto é verdadeiro em alguns cenários. Nenhum deles é uma falha da ideia de um protocolo compartilhado.
Contexto não é gratuito. Cada token gasto com descrições de ferramentas é um token que deixa de ser usado no seu código, nos seus documentos ou na própria conversa. Prompts longos também custam dinheiro a cada chamada, e os modelos tendem a perder detalhes enterrados no meio de um contexto enorme. Por isso o argumento dos tokens pega tanto entre quem usa agentes o dia inteiro.
A Anthropic apresentou o Model Context Protocol em novembro de 2024 como uma forma padronizada para aplicações de IA acessarem ferramentas e dados externos. Pense nele como um USB-C para agentes. Sem um padrão, cada aplicação de IA precisa de um plugin personalizado para cada serviço, e o número de integrações se multiplica rapidamente.
Um cliente (a aplicação de IA) conversa com um servidor (a integração) por meio de um canal local ou por HTTP. O servidor anuncia ferramentas, recursos e prompts, e o cliente permite que o modelo os chame. Essa é a ideia central: um formato de conector, muitos dispositivos.
Os três blocos de construção correspondem a necessidades do dia a dia. Uma ferramenta executa uma ação, como criar um issue ou gerar uma imagem. Um recurso expõe dados para leitura, como um arquivo ou uma linha de banco de dados. Um prompt é um modelo reutilizável que o usuário pode acionar, como "revise este pull request". A maioria dos servidores reais depende quase inteiramente de ferramentas, e é aí que os custos de tokens se acumulam.
Em 9 de dezembro de 2025, a Anthropic doou o MCP para a Linux Foundation como projeto fundador da nova Agentic AI Foundation, cofundada com a Block e a OpenAI e apoiada pelo Google, Microsoft, Amazon Web Services, Cloudflare e Bloomberg. Protocolos acabados normalmente não ganham um lar neutro e não reúnem tantos concorrentes na mesma mesa.
Por isso, a pergunta útil não é se o MCP sobrevive. É como as pessoas devem chamá-lo.
Aqui os críticos têm um argumento forte. Relatos indicam que o servidor MCP oficial do GitHub gera cerca de 50.000 tokens em descrições de ferramentas antes que o agente tenha feito qualquer coisa. Um arquivo curto de skill que ensina o mesmo fluxo de trabalho pela linha de comando foi relatado com cerca de 200 tokens. É uma diferença de duas ordens de grandeza, e ela sai do espaço de que seu modelo precisa para a tarefa em si.
O segundo custo se esconde no meio do fluxo de trabalho. Se um agente busca uma transcrição longa em um sistema e a cola em outro, cada palavra atravessa o modelo duas vezes. A transcrição de uma reunião de uma hora pode chegar a dez mil tokens ou mais, então passá-la duas vezes significa pagar duas vezes, mesmo que o modelo nunca precisasse lê-la.
Em sua publicação de engenharia de 4 de novembro de 2025 sobre execução de código com MCP, a Anthropic descreveu um fluxo de trabalho do Google Drive para o Salesforce que caiu de cerca de 150.000 tokens para cerca de 2.000, uma economia de aproximadamente 98,7%. O agente moveu o texto pelo código, então o modelo viu apenas uma confirmação curta.
Leia isso com atenção. A solução ainda era o MCP. O agente apenas o chamou por meio de código, em vez de uma chamada de ferramenta por vez.
| Abordagem | Contexto inicial | Melhor em | Ponto fraco |
|---|---|---|---|
| Chamadas diretas de ferramentas MCP | Alto com muitas ferramentas | Conjuntos pequenos e curados de ferramentas | Inchaço e desvios de dados |
| MCP com execução de código | Baixo | Grandes conjuntos de dados, muitas etapas | Precisa de um sandbox |
| CLI em um shell | Quase zero | Ferramentas para desenvolvedores | Precisa de um terminal |
| CLI mais um arquivo de skill | Muito baixo | Fluxos de trabalho repetíveis | Precisa de manutenção |
Ferramentas de linha de comando carregam décadas de documentação, respostas em fóruns e histórico de shell. Um modelo que recebe o pedido de listar pull requests abertos de um autor específico vai escrever a linha certa na primeira tentativa:
gh pr list --state open --json number,title,author \
| jq '.[] | select(.author.login == "maria") | .title'
Uma linha, e só os títulos finais chegam ao modelo. O JSON bruto nunca entra no contexto. Pipes, filtros e redirecionamentos oferecem composição de graça aos agentes.
Uma CLI não anuncia toda a sua superfície logo de início. O agente executa --help apenas para o subcomando de que precisa, lê algumas linhas e segue em frente. Isso é divulgação progressiva, e é exatamente o que os grandes schemas de ferramentas não têm.
Há também um benefício para as pessoas. Tudo o que o agente executa, você pode rodar sozinho em um terminal para reproduzir um bug. Sem protocolo oculto, sem inspetor especial.
💡 Regra prática: se já existe uma CLI madura para a tarefa (git, gh, aws, kubectl, docker), deixe o agente usá-la.
Um engenheiro do Google DeepMind fez o contraponto mais claro: se o seu agente vive dentro de um app de notas no celular, "basta usar a CLI" não é uma opção. O mesmo vale para aplicativos de chat no navegador, assistentes corporativos com restrições e qualquer sandbox sem acesso a processos. A maioria das pessoas que usam IA todos os dias não está sentada diante de um terminal.
Um shell é um instrumento grosseiro. Um agente com terminal herda o sistema de arquivos, as variáveis de ambiente e todas as sessões logadas naquela máquina. Você pode cercá-lo, mas o padrão é totalmente aberto.
Para ser justo, nenhum dos caminhos é seguro por padrão. Uma página web, um e-mail ou um ticket pode trazer instruções ocultas destinadas ao modelo, e esse risco existe tanto se o texto chega por uma chamada de ferramenta quanto pela saída de curl. Sandboxes, credenciais somente leitura e aprovação humana para ações arriscadas importam nos dois mundos. A diferença é que o MCP oferece um lugar natural para aplicar esses limites, enquanto um shell puro deixa isso por sua conta.
Um servidor MCP pode expor apenas as ferramentas que você escolher. Um servidor remoto pode usar OAuth, para que cada pessoa aja com a própria identidade, e um gateway central pode registrar cada chamada. Para uma equipe de cinquenta pessoas, isso é melhor do que cinquenta notebooks, cada um guardando um token de longa duração em um arquivo de configuração.
O protocolo está respondendo às mesmas críticas levantadas por quem o questiona, e rapidamente:
Um resumo prático do momento atual: use uma CLI quando tiver um terminal, use um servidor MCP curado quando precisar de um protocolo e nunca converta automaticamente uma API inteira em dezenas de ferramentas.
| Situação | Melhor escolha | Por quê |
|---|---|---|
| Agente de programação local com terminal | CLI | Menor sobrecarga, os modelos conhecem as ferramentas |
| A ferramenta já tem uma ótima CLI | CLI | Pipes mantêm os dados fora do contexto |
| App de chat no navegador ou no celular | MCP | Não há shell disponível |
| Muitos usuários, ferramentas compartilhadas, necessidade de auditoria | MCP | OAuth, ferramentas com escopo, registros centrais |
| SaaS sem CLI e apenas com OAuth | MCP | Login padrão e schema de ferramenta |
| Fluxo de trabalho longo movendo arquivos grandes | Execução de código | Os dados ficam fora do modelo |
A maioria das equipes acaba usando as duas. O MCP cuida dos poucos sistemas que exigem login e governança, e a CLI cuida de tudo o que os desenvolvedores já fazem em um terminal.
Veja como isso funciona na prática. Um desenvolvedor solo que trabalha com um agente de terminal vai usar git, gh e docker o dia inteiro e adicionar um ou dois servidores MCP para coisas sem CLI, como uma ferramenta de design ou um rastreador de tickets. Uma equipe de suporte que usa um assistente de chat no navegador não tem nenhum shell, então um servidor MCP hospedado com login é o único caminho viável. Uma equipe de plataforma que roda dezenas de agentes quer registros centrais e ferramentas com escopo, então coloca um gateway na frente de alguns servidores curados.
As duas rotas dependem de um modelo que chame ferramentas de forma confiável. No PicassoIA, você pode comparar vários modelos de linguagem (LLM) em um só lugar: Claude Sonnet 5 para automatizar tarefas de programação, GPT 5.6 Sol para trabalhos complexos de programação, Kimi K2.6 para construir agentes e Gemini 3.5 Flash para conversas e código rápidos. Dê a mesma tarefa com ferramentas para dois deles e veja como cada um lida com uma chamada que falha.
Geração de imagens e vídeos é um bom campo de teste para esse debate. As saídas são grandes, os trabalhos levam tempo e a ferramenta precisa informar o progresso. O PicassoIA expõe os mesmos quatro modelos por meio de um conector MCP e de uma API REST: PicassoIA Image, PicassoIA Image Editor Pro, PicassoIA Video e Seedance 2.5 Lite para vídeo com áudio.
Até cinco trabalhos podem rodar ao mesmo tempo por conta, compartilhados entre todas as conexões.
Repare no que o protocolo faz bem aqui. O assistente não precisa conhecer uma URL, um cabeçalho ou um intervalo de consulta. As descrições das ferramentas dizem a ele como iniciar um trabalho e como acompanhá-lo, e o resultado volta no chat. Essa conveniência é exatamente o que o MCP promete, e, para um usuário não técnico em um navegador, ela é a diferença entre "funciona" e "não é possível".
Os mesmos modelos estão disponíveis em https://api.picassoia.com/v1, com um bearer token que começa com pia_sk_. O formato segue o estilo da Replicate: criar uma previsão, consultar o status e buscar a saída.
curl -s https://api.picassoia.com/v1/models/picassoia/picassoia-image/predictions \
-H "Authorization: Bearer $PICASSOIA_TOKEN" \
-H "Content-Type: application/json" \
-d '{"input": {"prompt": "A lighthouse at dawn, natural light, 16:9"}}'
A resposta traz um ID de previsão. Consulte GET /v1/predictions/{id} até que o status indique succeeded, e então baixe o arquivo. Verifique as páginas da API no picassoia.com para ver os campos de entrada exatos de cada modelo.
💡 Teste você mesmo: execute o mesmo prompt uma vez pelo conector MCP e uma vez pelo curl. Cronometre os dois, conte as etapas e decida qual se encaixa no seu fluxo de trabalho.
O MCP não está morto e a CLI não é modismo. São duas ferramentas com funções diferentes, e a jogada inteligente é alinhar cada uma ao lugar onde seu agente realmente trabalha. Abra o picassoia.com, escolha um modelo, escreva seu primeiro prompt e veja os dois caminhos em ação com as suas próprias imagens.
Escolha seu idioma
