MCP Está Morto? Uma Análise Profunda Sobre o Protocolo de Contexto de Modelo

O Protocolo de Contexto de Modelo (MCP) deveria ser o grande unificador — uma maneira padrão para agentes de IA se comunicarem com as ferramentas e serviços de que precisam para realizar seu trabalho. Lançado no final de 2024, foi rapidamente aclamado como "o USB-C do ecossistema de IA", adotado pela Anthropic, OpenAI e um crescente ecossistema de provedores de ferramentas.

Mas a lua de mel pode ter acabado. Uma nova análise devastadora da Quandri Engineering, combinada com um debate acalorado no Hacker News (195 pontos, 174 comentários), causou um sério dano à reputação do MCP. O veredicto? O MCP consome contexto, tem baixa confiabilidade e se sobrepõe significativamente a ferramentas CLI e API existentes que já funcionam muito bem.

Problema 1: Ele Devora a Janela de Contexto

A descoberta mais condenatória da análise da Quandri é o volume de tokens consumidos pelas definições de ferramentas do MCP. Em sua pilha do mundo real (Linear, Notion, Slack e servidores MCP do Postgres), as definições de ferramentas sozinhas consumiram mais de 21.000 tokens — isso é 10,5% de uma janela de contexto de Claude de 200K, e 16,5% do contexto de 128K do GPT-4o.

O problema é de nível arquitetônico. Cada definição de ferramenta inclui seu esquema JSON — parâmetros, descrições, tipos de retorno — e cada um é carregado no contexto, independentemente de o modelo algum dia usá-lo. O Linear sozinho envia 42 definições de ferramentas (~12.807 tokens), mesmo que você use apenas get_issue e save_issue.

Analogia de restaurante do artigo: "Você se senta e 10 cardápios estão espalhados pela mesa. Não há espaço para comida de verdade."

Atualização: Desde que essas medições foram feitas, o Claude Code lançou Busca de Ferramentas com Carregamento Diferido, que carrega esquemas de ferramentas MCP sob demanda e reduz o uso de contexto em mais de 85%. Portanto, esse problema específico está sendo mitigado — mas as preocupações arquitetônicas permanecem.

Problema 2: Baixa Confiabilidade Operacional

Os problemas de confiabilidade do MCP são mais difíceis de ignorar. A equipe da Quandri documentou vários modos de falha que decorrem da arquitetura do MCP:

Os números de desempenho são alarmantes. O autor do artigo original fez um benchmark do Jira MCP contra sua API REST diretamente: o MCP era 3× mais lento por chamada e 9,4× mais lento na primeira chamada, incluindo a sobrecarga de inicialização. Este não é um problema específico do Jira — é arquitetônico. Cada servidor MCP adiciona uma camada de processo entre o LLM e a API subjacente.

Problema 3: Sobreposição com CLI/API Existentes

Talvez a crítica mais fundamental: o MCP duplica funcionalidades que já existem e funcionam melhor.

A comparação de tokens é brutal. Para procurar a mesma questão do Linear:

• Abordagem CLI: ~200 tokens no total (50 para o comando curl do prompt, 150 para a resposta)
• Abordagem MCP: ~12.957 tokens no total (12.807 para definições de ferramentas sempre carregadas, 150 para a chamada real)

Isso é 65× mais tokens para a mesma operação.

A Alternativa CLI-Primeiro

A alternativa proposta é elegantemente simples: fornecer ferramentas CLI existentes para LLMs. Os LLMs já aprenderam com páginas de manual, StackOverflow e milhões de gists do GitHub. Eles já sabem como construir comandos curl, passar por jq e filtrar resultados com grep. Nenhum novo protocolo é necessário.

# Abordagem CLI — funciona hoje, nenhum servidor MCP necessário
curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' \
  https://api.linear.app/graphql

Qual é a Verdadeira História?

Vamos ser justos: o MCP não vai a lugar nenhum da noite para o dia. O investimento no ecossistema é significativo — a Anthropic adquiriu a Stainless especificamente para acelerar as ferramentas MCP, e plataformas importantes como GitHub, Notion e Linear já lançaram servidores MCP oficiais. O protocolo resolve um problema real: fornecer uma interface padronizada para agentes de IA interagirem com serviços externos.

Mas a crítica levanta questões importantes sobre filosofia arquitetônica. A abordagem "SSH em uma caixa e usar CLI" que tornou LLMs como Claude Code e Codex tão eficazes é fundamentalmente mais simples do que o modelo de servidor MCP. Não requer nova infraestrutura, negociação de protocolo, nem gerenciamento de ciclo de vida de processos separado.

Como um comentarista do HN colocou: "O MCP parece estar resolvendo um problema que não existe — já tínhamos interfaces funcionais entre software e software. A inovação é que os LLMs agora podem usar essas mesmas interfaces."

A Conclusão

O artigo original "MCP está morto" — que dá nome a este debate — pode ser intencionalmente provocativo. Mas os dados por trás dele são reais. Para equipes que estão construindo fluxos de trabalho de agentes de IA hoje, a escolha entre MCP e acesso direto a CLI/API não é ideológica: é um custo mensurável em tokens, latência e confiabilidade.

A abordagem mais inteligente? Não escolha. Use o MCP para o que ele é bom (descoberta padronizada, prototipagem rápida, compatibilidade de ecossistema) e recorra a chamadas diretas de CLI/API para alta frequência, sensíveis à latência.