Quando a Anthropic lançou o Model Context Protocol no final de 2024, a comunidade dev tratou como se fosse a segunda vinda do REST. “O USB-C dos agentes de IA”, diziam. Todo mundo correu para criar servidores MCP, plugins apareceram aos montes, e de repente qualquer ferramenta de IA que se prezasse precisava ter integração MCP.

Dois anos depois, a lua de mel acabou. E o divórcio está sendo bem público.

Os sinais já vinham aparecendo desde o começo de 2026. Engenheiros de startups e big techs começaram a compartilhar relatos de que, na prática, o MCP criava mais problemas do que resolvia. Mas como ninguém queria ser o primeiro a falar mal do filho favorito da Anthropic, os relatos ficavam restritos a threads obscuras no Discord e mensagens no Slack de times de engenharia.

Um post no Hacker News chamado “MCP is dead?” acumulou centenas de pontos essa semana, e os comentários revelam uma frustração crescente entre devs que tentaram usar MCP na prática. A questão não é se o protocolo funciona — funciona. A questão é se ele deveria ser a primeira escolha para conectar agentes de IA a ferramentas. E a resposta, para a maioria dos casos, é um sonoro “provavelmente não”.

O que é MCP, afinal?

Pra quem não acompanhou: o Model Context Protocol é um padrão aberto criado pela Anthropic para conectar modelos de linguagem a ferramentas externas. Em vez de cada LLM ter sua própria forma de chamar APIs, o MCP propõe uma interface universal — um servidor expõe “tools” com schemas JSON, e qualquer cliente compatível pode usá-las.

A ideia é bonita. Na teoria, você conecta um servidor MCP do GitHub, outro do Jira, outro do banco de dados, e seu agente de IA tem acesso a tudo num protocolo padronizado.

Na prática, a coisa fica complicada rápido.

Problema 1: O MCP devora seu contexto

Esse é o elefante na sala que ninguém quer admitir.

Cada servidor MCP que você conecta injeta definições de ferramentas na janela de contexto do modelo. Parece inofensivo até você olhar os números. A equipe da Quandri fez um teste: 4 servidores MCP conectados consumiram 10,5% dos 200K tokens do Claude — antes de qualquer pergunta ser feita.

O servidor do Linear sozinho? 42 ferramentas, ~12.800 tokens. O do GitHub? 93 ferramentas, ~55.000 tokens. Você leu certo. O servidor MCP do GitHub custa 55 mil tokens só pra existir na conversa.

Pra contextualizar: 55 mil tokens é mais ou menos o conteúdo de um livro de 150 páginas. Você está queimando o equivalente a um livro inteiro do contexto do seu modelo só para ter acesso a ferramentas que talvez nem use naquela conversa.

E aqui mora o problema real: cada token consumido por definições de ferramentas é um token a menos disponível para raciocínio. Quando você enche o contexto de schemas MCP, o modelo tem menos espaço para pensar, analisar código, ou manter o histórico da conversa.

Benchmarks independentes confirmam: agentes usando CLI completaram 28% mais tarefas que agentes usando MCP com o mesmo total de tokens. A eficiência por token (tasks completadas / tokens gastos) foi 33% maior com CLI.

Problema 2: Confiabilidade questionável

Se você já usou MCP em produção — e não só num demo bonito no Twitter — sabe do que eu tô falando.

Servidores MCP crasham no meio de sessões. Autenticação expira sem aviso. O primeiro call é até 9,4x mais lento que chamadas CLI equivalentes por causa do overhead de inicialização. E quando um servidor cai, boa sorte tentando reconectar sem perder o estado da conversa.

Eu já presenciei um cenário clássico: agente rodando uma task de 20 minutos, servidor MCP do Jira perde a conexão no minuto 15, e o agente simplesmente continua como se nada tivesse acontecido — só que agora sem acesso ao Jira. O resultado? Metade das subtasks criadas, metade perdidas no limbo. E o pior: zero mensagem de erro.

# CLI: funciona há 15 anos, zero surpresas
gh pr list --state open --json number,title | jq '.[0:5]'

# MCP: precisa de servidor rodando, autenticação válida,
# protocolo compatível, e uma prece
mcp_github.list_pull_requests(state="open", limit=5)

A Quandri documentou que, em workflows reais, servidores MCP falham silenciosamente — o agente simplesmente para de ter acesso à ferramenta sem erro claro. Num ambiente onde você está pagando por token e esperando que um agente execute tarefas complexas autonomamente, falhas silenciosas são inaceitáveis.

Um paper publicado no arXiv em 2026 classificou as falhas mais comuns em software MCP: 37,5% são problemas de escalabilidade, 25% de convergência algorítmica, 25% de concorrência, e 12,5% de gerenciamento de memória. Não são bugs triviais — são falhas arquiteturais.

Problema 3: Reinventando a roda (só que pior)

Aqui é onde a coisa fica realmente irônica.

LLMs foram treinados em bilhões de exemplos de CLIs. O GPT-5.5 sabe usar git, curl, docker, kubectl, aws, gh e centenas de outras ferramentas de linha de comando de cor. Não porque alguém escreveu um plugin — porque o treinamento incluiu milhões de exemplos reais de uso.

Quando você usa MCP, está essencialmente pedindo pro modelo aprender uma interface nova que abstrai algo que ele já sabe fazer. É como ensinar alguém que já fala inglês fluente a usar um dicionário de sinais — pra se comunicar com uma pessoa que também fala inglês.

# O modelo já sabe fazer isso nativamente:
curl -s "https://api.github.com/repos/owner/repo/pulls?state=open" \
  -H "Authorization: Bearer $TOKEN" | jq '.[].title'

# MCP adiciona uma camada de abstração sobre a mesma API:
# → define schema JSON → registra no servidor → injeta no contexto
# → modelo parseia → chama servidor → servidor chama API → retorna

A composabilidade do Unix pipe é algo que LLMs entendem profundamente. command1 | command2 | command3 está tão entranhado nos pesos do modelo que ele improvisa combinações novas naturalmente. MCP não tem nada equivalente — cada ferramenta é uma ilha isolada.

Pense nisso: se você pede pro Claude “liste os PRs abertos e filtre os que têm mais de 7 dias”, ele monta um pipeline gh pr list --json ... | jq 'map(select(...))' sem pestanejar. Com MCP, ele precisa chamar list_pull_requests, esperar o resultado, processar internamente, e talvez chamar outra tool pra filtrar. Mais lento, mais tokens, mais pontos de falha.

E tem um detalhe que poucos mencionam: quando o modelo erra um comando CLI, o erro é imediatamente legível (fatal: not a git repository). Quando erra uma chamada MCP, o erro vem encapsulado em JSON com códigos genéricos que nem o modelo entende direito. Debugging vira um pesadelo.

Quando MCP faz sentido (sim, existem casos)

Seria desonesto dizer que MCP é inútil. Existem cenários onde ele brilha:

• Usuários não-técnicos: se seu público não sabe o que é um terminal, MCP fornece uma interface mais acessível
• SaaS sem CLI: muitas ferramentas cloud só têm API REST, sem CLI oficial — o MCP preenche esse gap
• Comunicação bidirecional em tempo real: MCP suporta SSE e websockets nativamente, algo que CLIs não fazem bem
• Governança enterprise: para organizações que precisam de audit trails, SSO integrado, e controle de acesso fino, MCP oferece uma camada padronizada

O roadmap 2026 do MCP mostra que o time está ciente dos problemas. Estão trabalhando em cost attribution, gateway behavior, e portabilidade de configuração. Mas essas são soluções para problemas enterprise — o dev individual programando com Claude Code ou Cursor provavelmente está melhor servido com CLIs.

Tem ainda uma quinta categoria que vale mencionar: prototipagem rápida. Se você está testando uma ideia de agente e quer conectar a 5 serviços diferentes em 10 minutos, MCP é imbatível. O setup é rápido, os SDKs são bem documentados, e funciona “o suficiente” pra validar um conceito. O problema é quando o protótipo vira produção sem ninguém trocar o MCP por algo mais robusto.

A estratégia que funciona em 2026

A comunidade parece estar convergindo para uma abordagem híbrida. Em vez de “MCP para tudo” ou “CLI para tudo”, a arquitetura que está ganhando tração é:

CLI por padrão:

• Git, Docker, Kubernetes, AWS, GCP — use CLI direto
• O modelo já sabe, é mais rápido, gasta menos tokens
• Debugging é trivial (é texto puro no terminal)

MCP sob demanda:

• Ferramentas sem CLI (Notion, Figma, Salesforce)
• Integrações que precisam de estado bidirecional
• Ambientes enterprise com requisitos de compliance

Skills/plugins carregados on-demand:

• Em vez de injetar 93 ferramentas do GitHub no contexto, carregue só o que precisa
• gh pr list consome ~15 tokens. O schema MCP equivalente consome ~600

# Padrão ruim: conectar tudo via MCP
agent.connect_mcp("github")    # +55K tokens
agent.connect_mcp("linear")    # +12.8K tokens
agent.connect_mcp("slack")     # +8.4K tokens
agent.connect_mcp("notion")    # +5.7K tokens
# Total: 81.9K tokens queimados antes de começar

# Padrão bom: usar CLI + MCP seletivo
agent.use_cli("gh", "docker", "kubectl", "aws")  # ~0 tokens extras
agent.connect_mcp("notion")  # +5.7K tokens (sem CLI disponível)
# Total: 5.7K tokens — economia de 93%

A NSA já se manifestou

Num movimento que poucos esperavam, a NSA publicou um documento em 2026 analisando as implicações de segurança do MCP. O protocolo depende de um contexto de execução não-isolado, onde múltiplos streams de dados coexistem num espaço operacional compartilhado. Traduzindo: se um servidor MCP malicioso for conectado, ele pode potencialmente acessar dados de outros servidores na mesma sessão.

Isso não é teoria — pesquisadores já demonstraram ataques de “prompt injection via tool description” onde um servidor MCP injeta instruções maliciosas nas definições de ferramentas que são lidas pelo modelo.

Para organizações que lidam com dados sensíveis, esse é um red flag que não pode ser ignorado.

Os números não mentem: benchmark CLI vs MCP

Vários benchmarks independentes compararam as duas abordagens em 2026. Os resultados são consistentes, e todos apontam na mesma direção:

Esses números vêm de testes com o Claude Opus 4.6 executando tarefas reais de desenvolvimento: criar PRs, atualizar issues, deploy de containers, consultas a bancos de dados. Não é benchmark sintético — é workflow real de dev.

O dado mais impactante: em tarefas complexas com mais de 10 passos, agentes CLI completaram 89% versus 69% dos agentes MCP. A diferença aumenta com a complexidade porque, quanto mais longa a tarefa, mais o consumo de contexto do MCP começa a estrangular o raciocínio do modelo.

O que vem depois

MCP não vai morrer — pelo menos não no sentido literal. Mas a narrativa de “protocolo universal para tudo” já morreu. O que está emergindo é um ecossistema mais maduro onde MCP ocupa um nicho específico (integrações enterprise, SaaS sem CLI, usuários não-técnicos) enquanto CLIs dominam o dia a dia do desenvolvedor.

O padrão que eu vejo ganhando força é o de “skills carregáveis”. Em vez de manter 200 ferramentas no contexto o tempo todo, o agente carrega dinamicamente apenas as definições que precisa para a tarefa atual. Alguns frameworks já implementam isso — o Claude Code, por exemplo, usa uma abordagem similar com tool definitions sob demanda.

A ironia final: o MCP foi criado para ser o USB-C dos agentes de IA. Mas assim como o USB-C real, que deveria unificar tudo mas ainda convive com Lightning, micro-USB, e conectores proprietários — o MCP acabou sendo mais um padrão num mundo que já tinha soluções funcionais.

A diferença é que, no caso do USB-C, eventualmente todo mundo migrou. No caso do MCP, a migração inversa já começou.

Se você está construindo agentes de IA hoje, meu conselho é pragmático: comece com CLI pra tudo que tem CLI, use MCP pra SaaS que não tem alternativa, e invista seu tempo aprendendo a compor ferramentas Unix em vez de configurar servidores MCP. Seus tokens — e seu bolso — vão agradecer.

—

Fonte de inspiração: MCP is dead? — Quandri Engineering Blog