Uptime de servidores MCP não é um espectro: 78% nunca falham um dia

Todo mundo cita a saúde do servidor MCP como um número. Eu também tenho citado um: cerca de 92% de um conjunto fixo de servidores responde em qualquer dia dado.

Esse número é real e também é inútil, porque não há servidor que se comporte assim. Eu probei os mesmos 400 endpoints MCP todos os dias durante um mês, e a população não é uma curva em forma de sino em torno de 92% — são dois grupos com quase nada entre eles.

O que eu fiz

No dia 30 de julho de 2026, eu peguei todos os endpoints no registro oficial do MCP que completaram um handshake anônimo e congelei 400 deles como uma coorte fixa. Desde então, todos os dias, os mesmos 400 recebem a mesma probe: abrir uma sessão, pedir a lista de ferramentas, registrar o que voltou.

Isso é deliberadamente não uma amostra fresca. Uma amostra fresca a cada dia diz o que o registro parece hoje. Uma coorte fixa diz o que acontece com os servidores à medida que envelhecem, e essas acabam sendo perguntas diferentes com respostas opostas.

Janela limpa: 2026-08-04 → 2026-08-27, 23 dias. Três execuções são excluídas e eu prefiro dizer o porquê do que não mencioná-las silenciosamente:

• 8/02 e 8/03 — o esquema de snapshot ainda não tinha o campo answered. Essas execuções registraram contagens de protocolo e ferramentas, mas não um booleano de passar/falhar, então não podem ser pontuadas. Elas não são zeros; elas são impossíveis de pontuar.
• 8/09 — a probe retornou 0 answered de 400. Quatrocentos servidores não falham simultaneamente; a probe falhou. A execução é nula.

A última quase envenenou todo este post, e a quase falha está na seção de método no final.

Descoberta 1: uptime é bimodal, não um espectro

Dos 400 servidores, aqui está quantos dias cada um ficou inacessível:

313 servidores (78,2%) nunca perderam um único dia. 22 (5,5%) nunca responderam uma vez. Tudo o mais — cada grau de confiabilidade parcial que existe — representa 65 servidores — 16,25%.

A média diária de 92% implica uma população de servidores um tanto instáveis. Essa população não está lá na maior parte. O que existe é um grande bloco confiável, um pequeno bloco morto e uma cauda fina.

Verificação de sensibilidade, porque dois dias merecem suspeita. 8/05 e 8/08 tiveram 38 e 41 servidores fora do ar em comparação com dias vizinhos de 23–28. Se eu descartar ambos, "nunca perdeu um dia" sobe para 341 (85,2%) e "fora pelo menos uma vez" cai para 59 (14,8%). Eu não estou descartando-os no título: essas mesmas contagens absolutas (38, 41) reaparecem em 8/26 e 8/27 como parte de um aumento constante, então a elevação sozinha não os condena. De qualquer forma, a forma se mantém, e as duas figuras abaixo não se movem nem um pouco.

Descoberta 2: "nunca respondeu" não é "morto"

Aqueles 22 servidores que nunca responderam uma vez em 23 dias — aqui está o que eles realmente retornaram no último dia:

Seis dos 22 estão retornando 401. Eles estão funcionando. Eles estão acessíveis. Eles estão recusando minha probe, porque minha probe é anônima e eles querem um token. Classificá-los como "mortos" seria errado, e é o erro específico que critiquei os números de MCP de outras pessoas por cometer. O balde genuinamente ausente é os sete 404s mais, por argumento, as quatro falhas de transporte.

Então: 5,5% nunca responderam a uma probe anônima. Algo abaixo de 3% parece realmente ausente.

Descoberta 3: um snapshot de um dia exagera a morte em cerca de um quarto

Três maneiras de perguntar "quantos estão fora", mesma coorte, mesmo dia final:

• fora no dia final: 41 (10,2%)
• fora nos últimos 5 dias consecutivos: 33 (8,2%)
• fora nos últimos 10 dias consecutivos: 29 (7,2%)

E na outra direção: 87 servidores estiveram fora pelo menos uma vez, mas 46 deles estavam de volta no dia final. Metade de todas as falhas observadas foi transitória.

Se você probe uma vez e publica o resultado, você chamará aproximadamente 41 servidores quebrados quando cerca de 33 estão persistentemente quebrados — uma exageração de ~24%. Duas probes com uma semana de intervalo não custam nada e removem a maior parte desse erro.

Descoberta 4: o registro ficou mais saudável enquanto seus servidores pioraram

Esta é a parte que eu não esperava, e só aparece porque a coorte fixa e a amostra fresca rodam lado a lado.

Todos os dias eu também extraio 400 aleatórios frescos de uma caminhada completa do registro ao vivo. Ao longo da mesma janela:

O registro cresceu mais de um terço em 23 dias, e subiu em todos os 21 pares de dias consecutivos (a caminhada de 8/05 retornou uma população parcial de 4.190 e está excluída). Ao longo exatamente desse período, os servidores que eu vinha observando desde julho ficaram ligeiramente piores, enquanto o registro como um todo parecia melhor.

Nada foi reparado. O agregado melhorou porque novas chegadas superam e superam o estoque em decadência. É um efeito de composição, e isso significa que as tendências de saúde em todo o registro falam sobre a taxa de crescimento, não sobre a durabilidade.

Eu quero ter cuidado sobre o quanto eu me apoio nisso. O declínio da coorte é pequeno, mas apertado (dp 0,8–1,3, e é monotônico na maior parte da segunda metade). O aumento da amostra fresca de +3,6pp está em aproximadamente 1,2 desvios padrão — sugestivo, não estabelecido. O crescimento de +37,3% e o declínio da coorte são os dois números sólidos; a direção do terceiro é consistente com eles, mas eu não publicaria isso sozinho.

O que isso muda se você depende dos servidores MCP

• Não leia uma média de uptime de frota como uma expectativa por servidor. Seu servidor específico está muito provavelmente no bloco de 78–85% que nunca falha, ou nos 5,5% que nunca funcionam. A média não descreve nenhum dos dois.
• Probe duas vezes antes de declarar algo quebrado. Metade do tempo de inatividade observado voltou.
• Trate 401 como um fato de configuração, não um fato de saúde. Seis dos meus 22 endpoints com pior desempenho são servidores saudáveis que querem um token.