Você conectou seu agente de IA — um programa que age por conta própria, chamando ferramentas externas pra fazer o trabalho — a uma dúzia de servidores MCP (Model Context Protocol — um padrão universal de plug pra ferramentas de IA, tipo USB só que pra dados). Testou tudo. A demo saiu perfeita. Mandou pra produção, onde sistemas de verdade quebram de verdade.
Aí veio o primeiro timeout de ferramenta. Seu agente repetiu a mesma chamada falhando nove vezes, torrou R$60 em tokens (pedaços de palavras que a IA processa, cobrados por uso) e alucinhou um resultado fake. Porque nada — literalmente nada no protocolo — informou que o erro era permanente.
Quatro prioridades, zero sobre erros
Em 19 de abril, o projeto MCP publicou seu roadmap de 2026. Quatro prioridades: evolução de transporte, comunicação entre agentes, governança, prontidão enterprise. Taxonomia de erros — aquilo que quebra todo agente em produção — não entrou na lista. Não foi mencionada. Não está planejada. Não está no radar de ninguém.
Isso não é um descuido que dá pra ignorar. A especificação oficial do MCP (revisão atual: 25 de novembro de 2025) define erros de execução de ferramentas como isError: true mais uma string de texto livre em inglês — a mesma estrutura de uma resposta de sucesso, só com um booleano invertido. Nenhum campo de código de erro. Nenhum header retry-after. Nenhum nível de severidade. A spec diz literalmente que erros de ferramentas contêm "feedback acionável que modelos de linguagem podem usar para se autocorrigir". Esse "feedback acionável" é uma frase desestruturada em inglês que o LLM precisa ler e interpretar sozinho.
O HTTP — o protocolo que seu navegador usa — resolveu isso há mais de trinta anos. 404 significa "não existe". 429 significa "devagar aí". 503 significa "tenta de novo depois". Três dígitos. Uma tabela de lookup. O MCP pede pra um modelo de linguagem probabilístico fazer o que um if-statement deveria.
Todo mundo constrói sua própria gambiarra
Alexey Tyurin publicou um MCP Reliability Playbook em 9 de março de 2026, pelo Google Cloud Community. Ele teve que inventar sua própria taxonomia de erros — CircuitOpenError, TimeoutError, RateLimitError — como erros tipados customizados, porque o protocolo não oferece nenhum. Circuit breaker com threshold de 50% de erros, exponential backoff com jitter. 317 testes só pra impedir que as ferramentas derrubassem o agente. Tudo customizado. Tudo por servidor. Tudo incompatível com a gambiarra de qualquer outra pessoa.
Enquanto isso, pesquisadores da Polytechnique Montreal analisaram 407 bugs específicos de MCP em 385 repositórios (publicado em 5 de março de 2026) e descobriram que tratamento de resposta de ferramentas era a categoria de falha mais frequente — 66,7% dos profissionais pesquisados já tinham enfrentado o problema. E um bug do Claude Code de 11 de março mostrou o protocolo quebrando de um jeito ainda mais básico: quando ferramentas MCP retornavam dados no campo content sem structuredContent, o Claude Code entendia como resposta vazia e tentava de novo infinitamente. O agente não sabia que já estava recebendo a resposta certa.
Os números não mentem
Pesquisa dos AWS Heroes de 18 de março quantificou o estrago: 97,1% das ferramentas MCP têm pelo menos um problema de qualidade na descrição, e chamadas encadeadas de ferramentas com 95% de sucesso individual entregam apenas 85,7% de confiabilidade no total. Adicione tratamento de erros desestruturado nessa cadeia e você está jogando dados com tráfego de produção.
O AAIF MCP Summit de 19 de abril em Nova York reuniu 1.200 participantes e teve o CEO da Linux Foundation, Jim Zemlin, chamando o MCP de "o Linux dos agentes". Comparação ousada — o Linux já tinha códigos de erro desde o dia um.
O que você deve fazer agora
Até que a Anthropic — dona do protocolo — lance uma revisão da spec do MCP com tipos de erro legíveis por máquina, encapsule suas ferramentas MCP com envelopes de erro estruturados: uma string error_type, um booleano is_retryable e um numérico retry_delay_seconds. Defina um budget fixo de retentativas por ferramenta no lado do cliente. Três tentativas no máximo. Depois falhe ruidosamente.
O ecossistema de ferramentas de agentes está repetindo o caos de tratamento de erros da web antiga a uma velocidade 10x maior. Em algum lugar entre "erro de ferramenta" e "R$60 em tokens queimados", existe um código de status de três dígitos esperando pra ser inventado. A plataforma que lançar isso primeiro vai ser dona da camada de confiabilidade da qual todo mundo vai depender — do mesmo jeito que o 200 OK virou infraestrutura invisível que ninguém mais pensa a respeito.
Até lá, seu agente está chutando. E ele não é bom em chutar.
