MCP morreu silenciosamente. Corsair mostra o que o substitui.
Eu tinha quarenta e três ferramentas conectadas a um único agente e o observava enlouquecer em tempo real.
A tarefa era estúpida e simples. "Pegue os últimos dez e-mails do meu Gmail e resuma tudo relacionado à proposta que enviei na terça-feira." Um trabalho em duas etapas. Leia o e-mail. Resumir. É isso. Em vez disso, o agente chamou uma ferramenta de pesquisa do Slack. Em seguida, uma ferramenta de calendário que conectei para um projeto diferente. Em seguida, ele tentou invocar gmail_get_messages — exceto que esse não era o nome da função. A ferramenta real era read_gmail_inbox. O agente teve a alucinação de uma chamada de API que parecia plausível de um esquema que ele lembrava parcialmente por meio de 38.000 tokens de definições iniciais de ferramentas.
Interrompi a corrida, abri o log de entrada e contei. Antes mesmo de meu prompt chegar ao modelo, MCP injetou mais de 40.000 tokens de esquemas de ferramentas na janela de contexto. Quarenta mil fichas. Para responder a uma pergunta sobre dez e-mails. O agente nunca teve chance.
Foi nesse momento que parei de defender MCP e comecei a procurar o que vem a seguir. Vou analisar o que descobri – incluindo um pequeno projeto de código aberto chamado Corsair que acho que aponta para a arquitetura real para uso da ferramenta em 2026. Mas primeiro, você precisa entender o que realmente quebrou. Porque "MCP está morto" não é exagero. É o que a matemática diz quando você ultrapassa o protocolo nas demonstrações de brinquedos.
O que MCP deveria fazer
A Anthropic lançou o Model Context Protocol no final de 2024 com um discurso limpo e ambicioso. LLMs são cérebros sem mãos e pernas. Eles conseguem raciocinar brilhantemente sobre código, linguagem e estratégia, mas não conseguem postar um tweet, ler sua caixa de entrada ou atualizar uma planilha sem recursos externos. MCP deveria ser esse encanamento - padronizado, neutro em relação ao fornecedor e universal.
O mecânico foi direto. Você expõe uma ferramenta. A ferramenta anuncia um esquema JSON descrevendo seu nome, parâmetros e o que faz. O cliente MCP injeta o esquema de cada ferramenta disponível na janela de contexto do modelo no início da conversa. O modelo escolhe a ferramenta certa, gera uma chamada estruturada e o tempo de execução a executa. Adicionar ferramenta. Obtenha capacidade. Repita.
Eu acreditei nisso completamente. No ano passado, escrevi sobre [os três MCPs que transformaram Claude em meu centro de operações] (https://www.mejba.me/blog/must-have-mcps-claude-code) - Canva, Zapier e Stripe conectados juntos mudaram a forma como trabalhei por cerca de seis meses. Com três ou quatro ferramentas, o MCP parece mágico. O protocolo desaparece. Você pede coisas em inglês simples e elas acontecem.
Mas três ou quatro ferramentas é a versão de brinquedo. No momento em que você aumenta a escala — no momento em que você tenta conectar a pilha real que um profissional em atividade usa — a arquitetura se abre de três maneiras específicas.
O problema do inchaço da janela de contexto
Aqui está o número que encerrou o romance para mim.
De acordo com um benchmark de 2025 do Scalekit, a mesma operação que utilizou 1.365 tokens por meio de uma CLI custou 44.026 tokens por meio de MCP. Isso representa aproximadamente 32x a sobrecarga do token e quase tudo foi injeção de esquema – 43 definições de ferramentas agrupadas no contexto antes que o agente tivesse lido um único caractere da pergunta real do usuário. Todas as outras análises respeitáveis que li desde então chegam ao mesmo bairro. A equipe de engenharia da CodeRabbit mediu servidores MCP individuais consumindo mais de 55.000 tokens de esquema antecipadamente. A pesquisa do Cyclr descobriu que com mais de 50 ferramentas, os esquemas podem consumir de 5 a 7% de uma janela de contexto de 200 mil antes do início da conversa.
Leia esses números com atenção. Cinco a sete por cento do seu contexto – desaparece – antes que alguém digite alguma coisa.
O problema é arquitetônico e não de implementação. MCP foi projetado com base na suposição de que o modelo precisa ver todas as ferramentas para usar todas as ferramentas. Essa suposição era razoável quando os agentes tinham quatro ou cinco ferramentas. É catastrófico quando eles têm quarenta. E quarenta não é o limite superior – é aproximadamente o que um único desenvolvedor ativo acumula entre GitHub, Slack, Linear, Sentry, seu banco de dados, seu e-mail, seu calendário e seu CMS.
Eu vi minhas próprias configurações ultrapassarem sessenta ferramentas sem tentar. Cada um parece “gratuito” quando você o adiciona. Cada um tributa cada solicitação futura, quer você o use ou não.
Quando as alucinações começam
Aqui está a parte que a maioria dos artigos enterra. O custo do token é o problema chato. O problema interessante é o que acontece com o raciocínio do modelo quando sua atenção precisa se espalhar por dezenas de esquemas de ferramentas.
Há um padrão que tenho visto repetidamente tanto em meus próprios registros quanto na pesquisa publicada. Quando a utilização do contexto ultrapassa cerca de 70%, a precisão da seleção de ferramentas do modelo entra em colapso. Ele começa a combinar parâmetros entre ferramentas semelhantes. Ele chama a ferramenta certa com argumentos de um esquema de ferramenta diferente. Inventa ferramentas que não existem, mas que soam como deveriam. E – este é genuinamente enervante – faz tudo isso com total confiança. As chamadas alucinadas parecem exatamente iguais às reais.
Os benchmarks do estilo Scalekit também se alinham com o trabalho acadêmico. O artigo RAG-MCP do arXiv (2505.03275) executou um teste de estresse onde alimentaram um LLM com um conjunto crescente de descrições de ferramentas MCP e observaram a precisão da seleção cair de um penhasco. Com a abordagem de despejo de esquema completo – a forma como o MCP funciona hoje – eles mediram 13,62% de precisão na seleção de ferramentas. Com a seleção baseada em recuperação, o mesmo modelo nas mesmas consultas atingiu 43,13%. Mais que o triplo da precisão com menos da metade dos tokens de alerta.
Isso não é um problema de ajuste. Esse é um problema do tipo “toda a abordagem está errada”.
Darei o exemplo mais concreto de meus próprios testes. Eu tinha duas ferramentas conectadas: send_email (via Gmail MCP) e send_message (via Slack MCP). Mesma estrutura verbal. Diferentes plataformas. Diferentes formatos de parâmetros. Cerca de uma em cada sete execuções, o agente geraria uma chamada para send_email com os parâmetros channel e text do Slack. O tempo de execução o rejeitaria. O agente pediria desculpas, tentaria novamente e, às vezes, teria sucesso e às vezes falharia de uma maneira diferente. Cada nova tentativa queimava tokens. Cada modo de falha era único. Depurar parecia perseguir fantasmas.
Quando reduzi para doze ferramentas, a taxa de falhas caiu para quase zero. Doze ferramentas — para um agente realizando um trabalho. Esse é o teto prático que o MCP oferece na produção.
O imposto de fragmentação de esquema
Embora as especificações do MCP sejam tecnicamente padronizadas, a realidade de executá-lo entre fornecedores em 2026 é mais confusa do que o marketing sugere.
Agora conectei servidores MCP de pelo menos oito fornecedores diferentes e posso dizer com absoluta certeza que o "esquema JSON" esconde um oceano de inconsistências. Alguns servidores retornam erros como objetos estruturados. Alguns retornam erros como strings inseridas em respostas bem-sucedidas. Alguns servidores paginam. Alguns não o fazem e truncam silenciosamente. Alguns servidores respeitam a distinção de campo opcional/required. Alguns tratam tudo conforme necessário e quebram se você omitir alguma coisa. A autenticação varia de OAuth limpo a "colar este token em um arquivo de configuração e orar".
Cada uma dessas inconsistências força o modelo ou o desenvolvedor a escrever uma lógica defensiva. Multiplique isso pelo número de servidores MCP que você está executando e a promessa do “protocolo unificado” se transforma em “sopa de esquema JSON com código do adaptador no meio”.
A questão mais profunda é que MCP padronizou o transporte, mas não a semântica. Dois servidores podem ser MCP válidos e não se comportarem de maneira semelhante. Tudo bem quando você tem um ou dois. É um imposto de integração quando você tem vinte anos.
Mais construtores do que usuários
Aqui está o sinal sobre o qual ninguém quer falar nos materiais de marketing do MCP. Veja os registros. Pulso MCP. Diretório de Conectores da Antrópica. Forjaria. Glama. Existem agora milhares de servidores MCP. A maioria deles tem algumas estrelas do GitHub e quase nenhum usuário real.
A comunidade está cheia de pessoas construindo servidores MCP. É surpreendentemente vazio de pessoas que os executam em produção em grande escala. A razão não é um mistério – são os três problemas que acabei de resolver. A primeira vez que você tenta conectar quinze dessas coisas em um agente, você bate no muro. Você silenciosamente recua para três ou quatro ferramentas, ou abandona completamente o MCP e volta para chamadas diretas de API, ou começa a escrever código agressivo de gerenciamento de contexto para compactar o que o MCP injeta.
Escrevi exatamente sobre esse padrão em meu artigo sobre [como o modo de contexto corrigiu meu problema de memória do Claude Code] (https://www.mejba.me/blog/context-mode-claude-code-bloat). O Modo de Contexto é uma solução inteligente para o sintoma – ele retira as saídas da ferramenta MCP do contexto depois de consumidas. Mas isso não resolve o problema upstream de cada esquema sendo injetado na inicialização. Isso apenas evita que o sangramento mate o paciente.
Quando o ecossistema da solução alternativa se torna maior que o próprio protocolo, o protocolo está em apuros.
A mudança do modelo mental: do cartão da biblioteca à enciclopédia
Aqui está o enquadramento que finalmente funcionou para mim. MCP trata as ferramentas como livros que você carrega consigo. Cada vez que você inicia uma conversa, você carrega todos os livros de que pode precisar em sua mochila e então raciocina enquanto é esmagado pelo peso deles. O modelo tem que considerar todos eles, o tempo todo, só para garantir.
Existe uma maneira melhor e óbvia. Não carregue os livros. Leve um índice. Quando precisar de informações, procure qual livro as contém, busque apenas esse livro e leia.
Este é o modelo da enciclopédia. O modelo sabe quais livros existem — seus títulos, uma descrição de uma linha, o domínio aproximado — e busca o esquema completo somente quando uma consulta realmente o exige. Esta é exatamente a arquitetura RAG (geração aumentada de recuperação) trazida para documentar perguntas e respostas há vários anos. Simplesmente não o aplicamos à seleção de ferramentas porque o design original do MCP não previu a escala.
Aplique RAG a ferramentas em vez de documentos e a matemática se inverte. Em vez de cada conversa começar com 40.000 tokens de esquema, ela começa com talvez 200 tokens de ferramenta index. Quando o usuário solicita algo, uma pesquisa vetorial recupera os dois ou três esquemas de ferramentas relevantes, eles são injetados no contexto e o modelo escolhe um. As taxas de alucinação caem porque o modelo não está se afogando em opções que parecem semelhantes. Os custos de token caem porque você está pagando pelo que usa, não pelo que poderia usar. A contagem de ferramentas torna-se efetivamente ilimitada.
Karpathy tem apontado ideias relacionadas há algum tempo - abordei alguns de seus pensamentos sobre arquitetura RAG quando escrevi sobre [construir uma base de conhecimento pessoal RAG em Obsidian] (https://www.mejba.me/blog/karpathy-obsidian-rag-knowledge-base). As ferramentas são apenas outro tipo de artefato recuperável. Deveríamos tratá-los dessa forma.
Digite Corsair
Corsair é um projeto de código aberto no GitHub (github.com/corsairdev/corsair) que implementa exatamente esse padrão. Não vou fingir que é um produto sofisticado ainda – não é. O repositório é jovem, os documentos são escassos e a comunidade é pequena. Mas a arquitetura é a resposta mais honesta que já vi para as perguntas que o MCP não consegue responder.
Veja como funciona a nível mecânico.
Você instala o Corsair como uma camada entre seu agente e suas ferramentas. Ele vem com um catálogo de definições de plugins para serviços comuns – Slack, Gmail, GitHub, Google Calendar e muito mais sendo adicionados. Os metadados de cada plugin residem em um índice vetorial. Quando seu agente recebe uma consulta, Corsair executa primeiro uma pesquisa semântica no catálogo de plug-ins, recupera apenas os esquemas de ferramentas do plug-in relevantes e os expõe ao modelo. Todo o resto fica fora de contexto.
Para o agente, Corsair parece um pequeno número de metaferramentas – pesquise no catálogo, busque um plugin, execute uma chamada. Para você, como desenvolvedor, expor vinte integrações equivale aproximadamente a uma linha de código. A complexidade está dentro do tempo de execução do Corsair, onde ela pertence.
O modelo de credencial é a parte que mais apreciei. Corsair armazena autenticação localmente em um banco de dados em arquivo. Nenhuma retransmissão de nuvem obrigatória. Nenhum painel de terceiros gerenciando seus tokens OAuth. Se você quiser conectar seu Gmail pessoal e o GitHub do seu cliente no mesmo agente, os segredos permanecerão em sua máquina. Para quem construiu agentes que tocam sistemas sensíveis, isso é mais importante do que qualquer linha de especificações de recursos.
A diferença na experiência do desenvolvedor
Deixe-me tornar o contraste concreto com a sensação de um trabalho típico de fiação em cada abordagem.
No MCP, adicionar um serviço é uma cerimônia de várias etapas. Encontre o servidor MCP correto. Leia seu README. Configure-o em seu cliente (Claude Desktop, Cursor, tempo de execução personalizado - todos diferem ligeiramente). Autenticar. Reinicie seu cliente. Teste. Perceba que um parâmetro tem um nome um pouco diferente do que dizem os documentos. Depurar. Perceba que o formato de resposta do servidor não corresponde ao padrão. Escreva análise defensiva. Reinicie novamente. Agora faça isso para o próximo serviço. E o próximo.
No padrão de recuperação no estilo Corsair, adicionar um serviço está mais próximo de "registrar o plug-in, armazenar a credencial, pronto". O agente não precisa ser reconfigurado. A janela de contexto não aumenta. Nada mais no sistema precisa saber.
Quero ser preciso aqui porque estou realmente tentando não exagerar. Corsair especificamente é inicial. O catálogo de plugins é pequeno. Você atingirá arestas se tentar usá-lo para algo de nicho hoje. Mas o padrão — recuperação de ferramenta orientada por RAG — é para o qual todos os projetos sérios de infraestrutura de agente que observei estão convergindo. A própria Anthropic publicou recentemente uma pesquisa sobre carregamento lento de esquema e controle dinâmico de ferramentas. O artigo arXiv "Tool Attention Is All You Need" (2604.21816) apresenta o mesmo argumento arquitetônico de um ângulo diferente. A direção está definida, mesmo que a implementação principal ainda não esteja totalmente cristalizada.
Onde MCP ainda faz sentido
Quero ser justo, porque acho que muitos posts “X está morto” exageram e perdem credibilidade. MCP não é inútil. É simplesmente inadequado para a escala que a maioria de nós está buscando.
MCP é genuinamente bom quando você tem um conjunto de ferramentas pequeno, fixo e selecionado - digamos, de três a sete - ao qual deseja que todas as conversas tenham acesso. O modelo de esquema inicial é adequado nessa escala. A latência é baixa. A atenção da modelo tem espaço para se espalhar sem quebrar. As vantagens da padronização do protocolo superam a sua sobrecarga. Se você estiver construindo um agente focado que faz uma coisa – um revisor de código com três ferramentas, um assistente de redação com quatro – MCP é adequado. É possivelmente a resposta certa.
MCP também faz sentido como backend. Você pode imaginar sistemas de recuperação como Corsair falando MCP nos bastidores para a invocação real da ferramenta, enquanto a camada de descoberta acima dela opera com base em princípios de recuperação. O protocolo torna-se infraestrutura em vez de modelo voltado para o usuário. É provável que tudo isso aconteça a longo prazo.
O que MCP não é bom é o trabalho real que os agentes mais ambiciosos precisam fazer - coordenar dezenas de serviços, definir dinamicamente quais ferramentas são relevantes para cada tarefa e permanecer abaixo do limite de utilização de contexto onde o raciocínio entra em colapso. Para essa carga de trabalho, o modelo de injeção de esquema está estruturalmente errado e nenhuma compressão de contexto o salva.
O que estou fazendo agora
Dividi minha própria infraestrutura de agentes em duas faixas. Para agentes de escopo único e com escopo restrito - meu bot de revisão de código, meu conversor de captura de tela para CSS, meu agente de triagem de e-mail - vou permanecer no MCP. Três a cinco ferramentas cada. Nenhuma recuperação necessária. O protocolo funciona.
Para meu agente de operações de uso geral — aquele que precisa lidar com e-mail, calendário, GitHub, meu CMS, minhas análises, meu CRM e uma dúzia de outros sistemas — mudei para uma arquitetura baseada em recuperação. Estilo Corsair hoje, possivelmente algo mais maduro em seis meses. A lei simbólica por si só justificou a migração. A queda acentuada nas chamadas de ferramentas alucinadas justificou isso duas vezes.
O modelo mental que aplico agora a cada novo agente é este: de quantas ferramentas serão necessárias? Se a resposta for “cinco ou menos, nunca”, MCP está bem. Se a resposta for “Eu realmente não sei e provavelmente mais de dez”, procuro a recuperação. O ponto de cruzamento está em torno de oito ferramentas, na minha experiência, e não é elegante - o desempenho diminui rapidamente quando você o cruza.
Esse único ponto de decisão me poupou horas de depuração de chamadas alucinadas e colapsos de raciocínio. Eu gostaria que alguém tivesse me entregado há um ano.
Perguntas frequentes
MCP está realmente morto ou apenas lutando em escala?
MCP não está morto para agentes pequenos e focados com três a sete ferramentas – funciona bem aí. Ele está funcionalmente morto para agentes de uso geral que precisam de acesso a dezenas de serviços, porque a injeção de esquema causa inchaço de contexto e alucinações de seleção de ferramentas que as abordagens baseadas em recuperação resolvem de forma limpa. A maioria das equipes de produção está hibridando silenciosamente.
O que é Corsair e ele está pronto para produção?
Corsair é uma camada de integração de código aberto para agentes AI (github.com/corsairdev/corsair) que usa RAG para recuperar dinamicamente apenas esquemas de ferramentas relevantes por consulta, em vez de injetar todos eles antecipadamente. É cedo – pequeno catálogo de plug-ins, documentos em evolução – mas o padrão arquitetônico que ele representa é para o qual a infraestrutura de agente séria está convergindo.
Por que adicionar mais ferramentas MCP piora os agentes?
Cada ferramenta MCP injeta de 550 a 1.400 tokens de esquema no contexto no início da conversa. Nas últimas 50 ferramentas, isso consome de 5 a 7% de uma janela de contexto de 200 mil antes mesmo de a pergunta do usuário chegar. Quando a utilização do contexto ultrapassa cerca de 70%, a atenção do modelo se fragmenta em ferramentas de aparência semelhante, as taxas de alucinação aumentam e a precisão da seleção de ferramentas entra em colapso.
Como RAG-MCP melhora a precisão da seleção de ferramentas?
O artigo RAG-MCP (arXiv 2505.03275) mostrou que a seleção de ferramentas baseadas em recuperação alcançou 43,13% de precisão versus 13,62% para a linha de base de injeção de esquema no mesmo benchmark – mais que o triplo da precisão com menos da metade dos tokens de prompt. O modelo vê apenas as ferramentas relevantes para a consulta atual, portanto sua atenção não fica fragmentada.
Devo migrar do MCP para uma abordagem baseada em recuperação agora mesmo?
Se o seu agente usa menos de oito ferramentas e funciona bem, fique. Se você está enfrentando explosões de alucinação, aumentando os custos de tokens ou planejando escalar além de dez ferramentas, comece a prototipar uma camada de recuperação como Corsair agora. O ponto de cruzamento não é elegante: o desempenho diminui rapidamente quando você o atravessa e a migração é mais fácil antes de haver tráfego de produção, dependendo da arquitetura antiga.
Vamos trabalhar juntos
Procurando construir sistemas AI, automatizar fluxos de trabalho ou dimensionar sua infraestrutura tecnológica? Eu adoraria ajudar.
- Fiverr (compilações e integrações personalizadas): fiverr.com/s/EgxYmWD
- Portfólio: mejba.me
- Ramlit Limited (soluções empresariais): ramlit.com
- ColorPark (design e marca): colorpark.io
- xCyberSecurity (serviços de segurança): xcybersecurity.io
