O MCP morreu?

(quandri.io)

1 pontos por GN⁺ 5 시간 전 | 2 comentários | Compartilhar no WhatsApp

MCP conecta LLMs a ferramentas externas, mas nos fluxos de trabalho de desenvolvimento os custos de contexto, a estabilidade operacional e a duplicação com CLI/API se mostram um peso considerável
Nas medições da Quandri, 77 definições de ferramentas de Linear, Notion, Slack e Postgres ocupam cerca de 21.077 tokens, ou 10,5% do contexto de 200K do Claude
Para consultar issues no Linear, a abordagem com MCP consome cerca de 12.957 tokens, muito mais do que a abordagem via CLI, com cerca de 200 tokens, porque as 42 definições de ferramentas ficam sempre carregadas
O MCP envolve processos de servidor separados, autenticação, inicialização, conflitos e latência de ida e volta externa, enquanto CLI/API é mais fácil de reproduzir, depurar e combinar no terminal
A Quandri encapsulou CLIs existentes em Skills e recuperou cerca de 21K tokens; usa MCP apenas quando não há CLI ou quando é necessário controle de permissões em nível de equipe

Os custos centrais que o MCP expôs

MCP (Model Context Protocol) conecta LLMs a ferramentas externas como GitHub, Linear, Notion e Slack, mas em fluxos reais de desenvolvimento os principais problemas passam a ser o uso de contexto, a estabilidade operacional e a sobreposição com CLIs/APIs já existentes
Desde o lançamento no fim de 2024, ele foi chamado de “USB-C do ecossistema de IA”, mas para desenvolvedores que o usam no dia a dia outros custos aparecem primeiro
Depois da medição, o Claude Code passou a incluir Tool Search with Deferred Loading, que carrega os esquemas de ferramentas MCP apenas quando necessário e reduz o uso de contexto em mais de 85%
Hoje, no Claude Code, o problema de inchaço de contexto foi bastante amenizado, mas questões de desempenho, depuração e arquitetura ainda permanecem

Consome uma grande parte da janela de contexto

A janela de contexto é o espaço que o LLM usa para trabalhar, e ao conectar um servidor MCP uma parte significativa pode ser ocupada só por definições de ferramentas, e não pelo conteúdo real da tarefa
Ao extrair e medir as definições reais das ferramentas dos servidores MCP conectados no ambiente da Quandri, verificou-se que, ao conectar os 4 servidores, 10,5% da janela de contexto é consumida apenas pelas definições das ferramentas
Tamanho das definições de ferramentas:
- Linear: 42 ferramentas, cerca de 51.229 caracteres, cerca de 12.807 tokens
- Notion: 14 ferramentas, cerca de 16.156 caracteres, cerca de 4.039 tokens
- Slack: 12 ferramentas, cerca de 15.168 caracteres, cerca de 3.792 tokens
- Postgres: 9 ferramentas, cerca de 1.755 caracteres, cerca de 438 tokens
- Total: 77 ferramentas, cerca de 84.308 caracteres, cerca de 21.077 tokens
Uso de contexto por modelo:
- No contexto de 200K do Claude, as definições de ferramentas ocupam 10,5%
- No contexto de 128K do GPT-4o, as definições de ferramentas ocupam 16,5%
Mesmo só o Linear já mantém 42 definições de ferramentas sempre carregadas, ocupando mais de 12.800 tokens; na prática, mesmo quando se usam apenas get_issue e save_issue, toda a definição vai junto
Exemplos de definições grandes de ferramentas:
- linear/save_issue: 2.479 caracteres, cerca de 619 tokens
- slack/search_public: 1.614 caracteres, cerca de 403 tokens
- linear/list_issues: 1.588 caracteres, cerca de 397 tokens
- notion/fetch: 1.379 caracteres, cerca de 344 tokens
- slack/send_message: 1.248 caracteres, cerca de 312 tokens

Carga de estabilidade operacional e desempenho

O MCP precisa iniciar e manter processos separados, então podem ocorrer falhas de inicialização e problemas repetidos de autenticação
Cada chamada de ferramenta exige ida e volta até um servidor externo, o que reduz a velocidade de resposta da IA
Se o processo do servidor MCP cair, as ferramentas podem desaparecer no meio da sessão
Não fica claro quais permissões cada ferramenta realmente possui, então a visibilidade de permissões é baixa
No benchmark de Jira MCP em MCP is dead. Long live the CLI, o MCP foi 3 vezes mais lento por chamada do que invocar a REST API diretamente, e a primeira chamada, incluindo a inicialização, foi 9,4 vezes mais lenta
Essa diferença de desempenho não se limita ao Jira; ela decorre da estrutura em que se adiciona uma camada de processo chamada servidor MCP entre o LLM e a API base
A mesma sobrecarga também se aplica aos servidores de Linear, Notion e Slack na stack da Quandri

Duplicação com CLI/API existentes

CLI/API permite que pessoas e LLMs usem os mesmos comandos, mas o MCP existe apenas dentro da conversa com o LLM
CLI/API pode ser combinado livremente com pipes, jq e grep, enquanto o MCP fica preso ao formato retornado pelo servidor
CLI/API pode ser reproduzido e depurado imediatamente no terminal, enquanto o MCP só pode ser reproduzido dentro do contexto da conversa
O LLM já aprendeu a usar CLI/API por meio de man pages e StackOverflow, mas o MCP exige definições de ferramentas separadas
Na maioria dos casos, CLI/API já está instalado, enquanto o MCP exige configuração de servidor, autenticação e gerenciamento de processos adicionais

O custo em tokens para consultar uma issue no Linear

Ao consultar a mesma issue do Linear, a abordagem MCP consome cerca de 65 vezes mais tokens do que a abordagem CLI
A abordagem CLI usa cerca de 200 tokens:
- Prompt de comando curl: cerca de 50 tokens
- Resposta: cerca de 150 tokens
A abordagem MCP usa cerca de 12.957 tokens:
- 42 definições de ferramentas do Linear sempre carregadas: cerca de 12.807 tokens
- Chamada de ferramenta e resposta: cerca de 150 tokens
O exemplo via CLI chama diretamente a API GraphQL do Linear:

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

Alternativa: estratégia CLI-first e Skills

Uma abordagem que oferece na ordem CLI → API → documentação é mais leve e mais direta
Como o LLM já aprendeu a usar CLI em man pages e no StackOverflow, não é necessário carregar sempre definições de ferramentas separadas
Ao usar a CLI existente diretamente, evita-se desperdiçar contexto com definições de ferramentas, e como humanos e IA usam a mesma interface, a depuração fica mais fácil
Também é possível combinar livremente com outros comandos por meio de pipelines
Se o MCP é como “colocar todo o cardápio sobre a mesa de uma vez”, Skills está mais próximo de “pedir ao bibliotecário só o livro necessário”
O MCP carrega todas as definições de ferramentas ao conectar e ocupa contexto o tempo todo, enquanto Skills carrega só quando necessário e ocupa contexto apenas durante o uso
Quanto mais servidores houver, maior será a pressão de contexto do MCP; Skills não ocupa contexto permanentemente em proporção ao número de skills
O ponto principal é colocar instruções de uso de CLI dentro de Skills, e a maior eficiência vem da combinação com uma estratégia CLI-first
O exemplo de Skill para Linear inclui apenas a URL da API, o modo de autenticação, o comando curl para consultar issues, a forma de consulta GraphQL e a instrução de parsear JSON com jq:

# Linear Issue Lookup Skill  
- Linear API: https://api.linear.app/graphql  
- Auth: Bearer Token ($LINEAR_TOKEN env var)  
- Get issue: 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  
- Search issues (GraphQL): adjust the query field for JQL-like filtering  
- Results are JSON, parse with jq

Nessa abordagem, o LLM carrega esse conteúdo no contexto apenas quando chama a skill correspondente
Não é preciso carregar o tempo todo as 42 definições de ferramentas do Linear; basta carregar os comandos CLI necessários

Quando o MCP ainda faz sentido

Quando um serviço não tem CLI, o MCP pode ser a única forma de conexão
Para usuários não desenvolvedores que não usam terminal, o MCP pode ser mais acessível
Em comunicação bidirecional em tempo real que vai além de simples requisição e resposta, o MCP pode ser adequado

Critérios para escolher acesso a banco de dados

No fim, acesso a banco de dados é execução de consultas, e o LLM já conhece bem SQL e consultas MongoDB
Se você colocar as informações do banco e o modo de usar a CLI em uma Skill, além do schema, o LLM pode escrever consultas sem MCP
O exemplo de Skill para Postgres inclui apenas host, schema das tabelas e modo de uso da CLI psql:

# Postgres Skill  
- Host: postgres://localhost:5432/myapp  
- Tables: users (id, name, email), orders (id, user_id, status)  
- CLI: psql -h localhost -d myapp -c "SELECT * FROM users WHERE ..."

Em bancos de dados, o MCP também tem vantagens:
- Segurança de consultas: o servidor MCP pode impor modo somente leitura e bloquear consultas perigosas no nível do servidor
- Proteção de credenciais: na abordagem CLI, a string de conexão pode ficar exposta no prompt, enquanto o servidor MCP gerencia as credenciais internamente
Para desenvolvimento local ou banco pessoal, Skills + CLI é mais leve, mais rápido e mais fácil de recuperar de erros
Para banco de produção ou ambiente compartilhado por equipe, o MCP é adequado, e proteções como validação de consultas no nível do servidor e controle de acesso são importantes
Na maioria dos fluxos de trabalho de desenvolvimento, o MCP tende a ser engenharia excessiva

Como a Quandri usa isso

A Quandri usa Bash + CLI, Skills e MCP em conjunto, conforme o serviço
Para ferramentas usadas todos os dias, como gh, psql e aws, usa Bash + CLI:
- sem custo de contexto
- alta flexibilidade
- depuração imediata no terminal
Para fluxos repetitivos e com várias etapas, como criação de commits e revisão de PRs, usa Skills:
- carregadas apenas quando são chamadas
Para serviços como Slack, Linear e Notion, que não têm uma CLI forte, usa MCP
Também usa MCP quando o mais importante é autenticação em nível de equipe ou definição de escopo de permissões, como no acesso a banco de dados de produção
Se já existe CLI e a autenticação local é possível, essa costuma ser a forma mais leve
Se o serviço não tem CLI ou exige autenticação consistente para toda a equipe, o MCP ganha valor

Conclusão e método de medição

Mais importante do que conectar tudo é ensinar bem
Na Quandri, substituir servidores MCP por Skills que encapsulam CLIs existentes recuperou cerca de 21K tokens de contexto
Nos fluxos diários, as falhas de inicialização desapareceram, e a depuração continuou no terminal
Carregar apenas as ferramentas necessárias, no momento necessário, junto com instruções de CLI, é mais eficiente
O MCP pode evoluir no futuro para resolver esses problemas, mas no estado atual Skills é a melhor escolha
Método de medição:
- extração do schema JSON de cada ferramenta dos servidores MCP realmente carregados no ambiente Claude Code
- medição do tamanho com base em nome da ferramenta, descrição e parâmetros
- estimativa de tokens usando a heurística de cerca de 1 token a cada 4 caracteres
- estimativa total dos servidores extrapolada a partir da média das ferramentas amostradas

Quer continuar recebendo tópicos de tecnologia selecionados? Siga o canal no Telegram. @GeekNewsBrasil

2 comentários

aer0700 3 시간 전

Acho que basta escolher a tecnologia que faz sentido para a sua própria situação. Para dizer que morreu, ela já está sendo usada demais, na minha opinião.

GN⁺ 5 시간 전

Comentários no Hacker News

Eu lidero na OpenAI a equipe responsável pelo ChatGPT App Store, pelos plugins do Codex e pelo MCP de forma geral, e o ponto que os textos dizendo que “o MCP morreu” deixam passar é que, na prática, não importa muito se o MCP é usado como protocolo de transporte
O motivo de o MCP não ter morrido é que quase todas as empresas do planeta estão criando servidores MCP, e nós sabemos disso porque falamos diretamente com elas
Muitas dessas empresas não têm CLI e, em alguns casos, nem API externa, mas ainda assim estão criando servidores MCP
Internamente, daria para transformar todos os servidores MCP em CLI, usar modo de código ou implementar descoberta de ferramentas, mas isso são só detalhes de implementação; o ponto central é que agentes de IA passam a acessar serviços que antes não conseguiam acessar
Pode até ser discutível se o MCP morreu como camada de comunicação com a qual o modelo conversa diretamente, mas dizer que o MCP morreu como protocolo não faz sentido nenhum
Por causa dos recursos de uso de computador/navegador do app Codex, esse argumento ficou mais fraco do que antes, e se você ainda não testou, o nível é realmente impressionante
- Acho bem provável que o MCP morra
  O principal motivo é que, seja a implementação real uma API, a web ou uma CLI, ele adiciona mais uma camada e mais uma pessoa por cima, com risco de dessincronização
  A IA não deveria usar um protocolo ou conjunto de instruções diferente daquele que as pessoas acessam, conhecem e usam
  Hoje as empresas querem expor servidores MCP porque isso está na moda, mas na prática o que acontece é usar o Claude para criar um servidor MCP em cima de uma API existente e, de vez em quando, mandar atualizar para bater com a documentação pública
  Como a documentação da API já é pública e o Claude Code também criou servidores MCP lendo só documentação pública da internet, o MCP parece um atalho temporário para as limitações atuais dos modelos
- No fim, MCP é mais ou menos uma marca para “API que um modelo de linguagem grande consegue usar”
  Como resultado, até empresas menos orientadas a tecnologia estão criando APIs para que suas ferramentas não pareçam ultrapassadas na era dos agentes
  Eu concordo com o objetivo em si, mas outra questão é se eu escolheria isso como protocolo para esse fim; de todo modo, virou um protocolo que as pessoas conhecem e realmente usam
- Essa fala de que “quase todas as empresas do planeta estão criando servidores MCP” soa justamente como uma câmara de eco
- O MCP continua consumindo a valiosa janela de contexto para resolver um problema que, na prática, não existe
  A ideia de que sem MCP um agente não conseguiria acessar um serviço é, no melhor dos casos, enganosa; como o artigo diz, acesso já é possível só com ferramentas de linha de comando e sua entrada e saída
  Mesmo sob um ponto de vista puramente técnico, o MCP tem menos componibilidade do que ferramentas de linha de comando, e quem não der importância à componibilidade vai acabar pagando esse preço
  Falando de forma direta, existe viés de investimento, e o fato de estarem vendendo MCP para um monte de empresas não refuta esse viés
  Basta olhar para a Microsoft para ver que utilidade e qualidade técnica têm pouca relação com o quanto algo se espalha; para alguns, a relação é até inversa
  Também suspeito que o fato de a OpenAI estar empurrando o MCP agora tem muito a ver com fatores organizacionais, algo que pode ser difícil de perceber internamente
- Essa história de estarem criando MCP onde não existe CLI é bem preocupante
  Há uma diferença entre replicar funcionalidades de uma CLI existente para uma integração melhor com agentes e transformar isso na única interface que prende todo mundo a uma especificação que depois pode até ser considerada inferior
  Aí mais adiante vai ser preciso pagar a dívida de MCP, e no fim talvez saísse mais barato simplesmente não fazer isso
Esse texto parece ter sido escrito por IA
Essencialmente, o MCP é algo próximo de JSON-RPC com alguns campos especiais obrigatórios
Dá para ter preocupações com JSON-RPC, mas ainda é necessária uma camada de descoberta de serviços com a qual modelos de linguagem grandes consigam se integrar
Isso precisa funcionar em vários lugares, como sites, aplicativos desktop e serviços de backend, e a CLI é só um dos pontos de encontro com esse tipo de sistema
Seja qual for a substituição do MCP, mesmo que defina de outro jeito o protocolo de comunicação ou os campos de descoberta de ferramentas, a chance é grande de acabar em algo parecido
- Sempre que leio textos sobre MCP, parece que a internet inteira ou o HN está tendo um ataque coletivo
  Dizem que API é melhor que MCP, mas MCP é só uma API com algumas instruções extras para a IA conseguir descobrir como usar
  Também falam para usar CLI, mas eu sinceramente não sei o que isso quer dizer exatamente
  O motivo de modelos de linguagem grandes usarem bem ferramentas CLI comuns como ffmpeg é que esse conhecimento já está consolidado nos pesos do modelo
  Se você criar uma CLI nova, ainda vai precisar ensinar a IA a usá-la; se quiser que essa parte de “ensinar” venha do servidor, isso é MCP; se quiser deixar isso numa forma estática local, isso é skill
  Não entendo por que existe tanta discussão em torno de uma ideia tão simples
- O problema é que o MCP ocupa contexto de forma relativamente permanente e não vem junto com um sistema limpo de instalação/remoção e descoberta
  As skills deveriam ser todas baseadas em MCP, carregadas só quando necessário, e fáceis de gerenciar e descobrir tanto por humanos quanto por IA para funcionarem direito
  Pelo alcance real de aplicação, o escopo inicial era estreito demais, mas se colocarem algo em cima disso, talvez ainda dê para reviver
Sobre a alegação de que o “Problema 1: engole a janela de contexto”, não vejo muita diferença em relação a executar linearcli --help, notioncli --help, slackcli --help em sequência
Pelo contrário, no MCP o ambiente de execução pode colocar no contexto apenas o título de cada ferramenta, e a documentação completa pode ser adicionada depois por servidor MCP ou por ferramenta, quando necessário
Para obter o mesmo efeito com CLI, todas as CLIs teriam de oferecer um comando como --short-descr
O “Problema 2: baixa confiabilidade operacional” também não faz sentido: se a ferramenta usa uma REST API, o protocolo é parecido, então não há motivo para o MCP ser mais lento
Se for mais lento, é bem provável que seja um problema de implementação, como uma camada de MCP em cima da API ou um servidor terceirizado rodando em um datacenter distante
A maioria dos servidores MCP pode até ser uma bagunça, mas isso é um problema da indústria, não do protocolo
O “Problema 3: se sobrepõe a CLI/API existentes” faz sentido quando já existe uma ferramenta de CLI, e um servidor MCP para SQL ou um MCP de curl realmente parece desperdício de tokens
Mas a maioria das organizações não tem CLI e, quando tem, geralmente só existe uma API projetada para ser usada por programas, não por grandes modelos de linguagem
Dizer “forneça primeiro na ordem CLI → API → documentação” soa como dizer que, em vez de um site lento e ineficiente, a empresa deveria primeiro entregar um cliente nativo de desktop e um cliente nativo mobile
- Não pesquisei isso a fundo, mas, tirando as versões mais recentes do Claude Code, eu entendia que o MCP era pré-carregado no contexto
  Se não for usado com frequência, é preciso desligá-lo e ligá-lo de novo quando necessário
  Se você colocar exemplos de uso no arquivo de skills, também dá para reduzir a primeira chamada de --help; e, no caso de CLI, também parece fácil subir um subagente com contexto separado e receber só o resultado
O texto não tem data, mas diz que o carregamento tardio de ferramentas é uma atualização recente que saiu depois da redação do texto
Só que o carregamento tardio de ferramentas foi adicionado em novembro de 2025: https://www.anthropic.com/engineering/advanced-tool-use
Portanto, esses números têm pelo menos 7 meses, e não entendo por que isso foi publicado agora
- É estranho ainda estarem discutindo isso
  Por causa de carregamento tardio de ferramentas, contexto grande e cache de prompt, 2026 ficou completamente diferente de 2025
  O argumento de que CLI economiza tokens também cai por terra se a primeira etapa for executar --help
  Se o método de chamada não estiver na memória dos parâmetros, o problema continua o mesmo: ele precisa estar no contexto de qualquer jeito
- Mais do que isso, o texto parece ainda mais antigo e dá a entender que GPT-4o é o estado da arte
- O carregamento tardio de ferramentas não faz parte do MCP
  É um parâmetro exclusivo da API do Claude que a maioria das outras APIs de grandes modelos de linguagem não oferece
- O texto é de 29 de maio de 2026, e dizer que essa atualização “recente” veio depois do texto é mentira para parecerem melhor
Acho que havia um ótimo texto defendendo que MCP funciona bem em nível organizacional, quando é preciso oferecer aos funcionários não técnicos que usam ferramentas internas de agentes um acesso unificado e seguro às APIs utilitárias internas
A ideia seria codificar os fluxos de trabalho como skills para compartilhá-los entre instâncias, e deixar para o MCP o que exigir acesso a APIs sensíveis ao contexto
- Seria este texto? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
- Se for isso, fico curioso sobre qual seria a vantagem do MCP em comparação com o agente acessar a API diretamente
- Fico pensando se isso substituiria um sistema de permissões para proteger a API
  De qualquer forma, a API provavelmente precisa ter algum tipo de mecanismo de autorização
- Exato
  É exatamente por isso que empresas como a Runlayer estão crescendo rápido, e sem um plano de controle centralizado o MCP vira um campo minado
Além dos pontos já levantados, o MCP remoto é controlado pelo servidor, então o produtor pode adicionar novos recursos sem precisar atualizar as skills e CLIs de todos os clientes
Além disso, o MCP remoto é mais seguro porque não exige permissão para executar código de verdade no sistema local
As skills geralmente empacotam scripts com npx/uvx, o que na prática é tão arriscado quanto curl npm.com | bash
Já implementei skills que conectam equipes a sistemas internos de gestão da empresa, e no fim acabei registrando isso como MCP
O MCP em si é completamente inútil, porque só expõe grep em documentação e chamadas de API, mas o principal motivo para escolher esse caminho foi a distribuição
Equipes não técnicas querem uma UI em que tudo funcione ao adicionar uma URL e em que o OAuth seja guiado, e o MCP permite isso no Claude e no ChatGPT
A forma como as chamadas MCP aparecem na UI de chat também é melhor e mais clara para o usuário
Em vez de lidar com servidores MCP e distribuir CLIs para todas as plataformas, fico pensando se não seria melhor expor a API por SSH
SSH é um protocolo perfeito para grandes modelos de linguagem
Agentes de programação já conseguem usar isso, e ssh api@example.com list-users já bastaria
É bem provável que 90% dos usuários já tenham ssh instalado, e tanto a entrada quanto a saída são texto, então é ideal para grandes modelos de linguagem
Ele já resolve autenticação por chave pública, saída em streaming, entrada/saída interativa e, se quiser, até transferência de arquivos via scp/rsync
Se o usuário conectou a conta ao Github ou GitLab, você poderia até reaproveitar a chave ssh e deixar a autenticação pré-configurada, de modo que bastasse conectar e já entrar
- É só escalar isso para o tamanho de toda a organização
A analogia do restaurante não é boa
É algo como “há 10 cardápios abertos sobre a mesa e não sobra espaço para colocar a comida; além disso, toda vez que você vai pedir precisa abrir o cardápio de novo”, mas pedidos repetidos não são tão comuns a menos que seja um restaurante de tapas
A comida pode ser colocada em cima do cardápio, e normalmente os cardápios são retirados depois do pedido, liberando a mesa, ou seja, o contexto
Se for usar analogias para explicar, seria bom fazer um esforço para torná-las mais relevantes