Você conectou seu agente de IA a quinze servidores MCP — Slack, GitHub, Jira, banco de dados — e testou até tudo funcionar em perfeita harmonia. MCP (Model Context Protocol) é o padrão universal de plug que permite agentes de IA conversarem com ferramentas externas, tipo USB só que para dados. Sua demo ficou linda. Seu chefe balançou a cabeça aprovando. Você mandou pra produção.

Agora a parte que ninguém te avisou: servidores MCP não são pacotes estáticos parados no seu disco. São processos ao vivo e endpoints remotos. E até 25 de abril de 2026, nenhuma plataforma de agentes vai te avisar quando um deles cair, ficar arrastado, ou começar a devolver lixo.

Metade das suas ferramentas já pode estar morta

Em 20 de abril, a RapidClaw auditou 1.847 servidores MCP públicos em sete registries. O resultado: 52% estão mortos ou abandonados. Apenas 17% — 315 servidores — se qualificaram como prontos para produção. O servidor MCP mediano tem seis commits na vida, um mantenedor, zero testes e não é atualizado há 142 dias.

É desse ecossistema que seu agente depende. Um cara ou coroa decide se a ferramenta que ele está chamando ainda funciona.

E o próprio protocolo MCP não ajuda em nada. Não existe health check endpoint embutido — nenhuma forma padronizada do servidor dizer "estou vivo e funcionando". Os SDKs implementam um ping básico, mas não tem /health, não tem /ready, não tem liveness probe. Cada time faz o seu, ou — mais comumente — não faz nada.

O buraco no formato do protocolo

A lacuna não está só nas plataformas — está na spec. HTTP tem status codes. gRPC tem health checking services. Kubernetes tem liveness e readiness probes. MCP tem... um método ping que confirma que a camada de transporte está viva, não que o servidor consegue fazer o trabalho dele.

Um servidor MCP de banco de dados pode responder ao ping enquanto seu connection pool está esgotado. Um servidor MCP do GitHub pode dar pong de volta enquanto o auth token expirou há três semanas. O protocolo não distingue entre "transporte funciona" e "ferramenta funciona". Essa distinção importa quando seu agente queima tokens tentando de novo uma ferramenta que tecnicamente responde, mas funcionalmente mente.

O Agent Observability do Google, lançado em 22 de abril como parte do Gemini Enterprise Agent Platform, rastreia contagem de requisições e latência p95 para servidores MCP. Duas métricas. Já cobrimos as lacunas maiores da plataforma — o resumo é que o Google construiu tracing a nível de agente, não monitoramento a nível de ferramenta. A AWS apresentou uma abordagem similar de catálogo com o Agent Registry em 17 de abril — uma lista telefônica de agentes, não um monitor de saúde. Ambos reconhecem que ferramentas precisam de tratamento de infraestrutura. Nenhum dos dois realmente verifica se suas ferramentas estão vivas.

Pra comparar: qualquer microsserviço meia-boca — um pedaço pequeno e independente do seu backend — tem health checks, taxas de erro, análise de qualidade de resposta e alertas automáticos. Seu servidor MCP ganha um contador de requisições e um cronômetro.

O que quebra quando uma ferramenta quebra

Quando um servidor MCP degrada silenciosamente, seu agente não sabe. Ele ou alucina uma resposta (inventa algo), fica retentando silenciosamente queimando tokens — os pedaços de texto que a IA lê, cada um custando dinheiro — ou falha sem te dizer qual ferramenta quebrou. Traces de observabilidade de agentes mostram o que o agente decidiu. Não mostram se a ferramenta estava saudável quando respondeu. Você vê o sintoma. Não consegue diagnosticar a causa.

É como monitorar sua aplicação web mas não monitorar o banco de dados dela. O dashboard fica verde até tudo pegar fogo.

O que fazer agora

Se você está rodando agentes em produção, trate cada servidor MCP como uma dependência de microsserviço:

  • Defina timeouts. O protocolo MCP não vai fazer isso por você.
  • Defina fallbacks. Se uma ferramenta caiu, seu agente precisa de um Plano B, não de uma alucinação improvisada.
  • Monitore a qualidade das respostas. Um 200 OK que retorna lixo é pior que uma falha limpa.
  • Envolva conexões em circuit breakers — um padrão que corta um serviço falhando antes que ele arraste todo o resto junto.
  • Aceite o teto. Seu agente é exatamente tão confiável quanto sua ferramenta menos confiável.

A maioria dos times não orçou essa tubulação. A maioria dos times vai aprender por que deveria ter feito.

A camada que falta

A stack de agentes em abril de 2026 tem modelos mais espertos, registries maiores e gateways mais chiques. O que não tem é SRE de ferramentas — Site Reliability Engineering aplicada às ferramentas das quais os agentes dependem. Artigos anteriores neste canal argumentaram que engenharia de confiabilidade de agentes ainda não existe. A auditoria da RapidClaw prova que o problema vai um nível mais fundo: você não pode ter agentes confiáveis quando o protocolo que eles falam nem sequer define o que "saudável" significa para uma ferramenta.

A primeira plataforma que lançar monitoramento de saúde a nível de ferramenta com endpoints /health e /ready embutidos na spec MCP — não colados por cima por cada vendor — captura a camada de confiabilidade que o ecossistema inteiro está precisando.

Você começou com quinze servidores MCP que funcionavam perfeitamente no dev. Em produção, uns oito deles estão a um cara ou coroa de morrer. Ninguém está vigiando. Talvez comece por aí.