
Um gateway representou 24% da minha amostra e publiquei assim mesmo
Onze dias atrás, publiquei um artigo dizendo que o tempo de atividade do servidor MCP é bimodal: de 400 servidores de registro testados diariamente, 78,2% nunca perderam um dia e 5,5% nunca responderam uma vez.
Ambos os números estão aritmeticamente corretos e um deles é enganoso, porque 97 desses 400 "servidores" são 97 caminhos de URL em um único gateway — gateway.pipeworx.io.
Eu gostaria de dizer que não sabia. Três dias antes daquela postagem, em 2026-08-24, acrescentei uma correção publicada a quatro artigos anteriores para esse exato defeito, nomeando este exato gateway. Eles ainda estão lá, no topo de cada peça. Então escrevi um novo artigo, do mesmo grupo, e não apliquei a correção que passei um dia escrevendo.
Então, esta postagem é essa correção, aplicada tarde — além da coisa que surgiu que eu não esperava.
O que o grupo realmente é
O grupo fixo é de 400 endpoints do registro oficial do MCP, congelado em 2026-07-30, testado todos os dias desde então. Contados como endpoints, são 400. Contados pelo domínio que os opera:
| unidade | contagem |
|---|---|
| endpoints | 400 |
| hosts distintos | 284 |
| operadores distintos | 242 |
endpoints em gateway.pipeworx.io
|
97 (24,2%) |
| top-5 operadores | 133 (33,2%) |
| top-10 operadores | 157 (39,2%) |
Um operador é um quarto da amostra. Os dez principais são dois quintos dela.
Reafirmando os números publicados
Mesma janela de 23 dias (2026-08-04 → 08-27), mesmo método, uma coluna adicionada:
| como publicado (400 endpoints) | excluindo o único gateway (303) | |
|---|---|---|
| nunca perdeu um dia | 313 — 78,2% | 223 — 73,6% |
| nunca respondeu uma vez | 22 — 5,5% | 22 — 7,3% |
| parcial (a cauda) | 65 — 16,2% | 58 — 19,1% |
| média de tempo de atividade diário | 92,0% | 89,6% |
90 dos 313 servidores no bloco "nunca perdeu um dia" — 28,8% dele — são aquele único gateway. Sete de seus 97 caminhos não atingiram a meta e 90 a superaram: dois estavam fora em 08-05, um em 08-08, e quatro em 08-27. Em todos os outros dias da janela, respondeu 97 de 97. A direção do erro é a que minha própria auditoria previu com antecedência: um grande operador perfeitamente confiável inflaciona o denominador saudável, então eu estava exagerando a confiabilidade, em 4,6 pontos na figura principal e 2,4 na média diária.
A forma bimodal sobrevive a tudo isso. O nível não.
A parte que eu não previ: o agregado agora tem clima
Minha auditoria interna fechou a questão da concentração com esta frase: "Nunca falha, então não inflaciona uma contagem de falhas — inflaciona o denominador saudável." Essa era a premissa fundamental: ela tornava a direção do viés conhecível com antecedência, que é a única razão pela qual uma correção poderia ser emitida sem reexecutar tudo.
Já estava errado três dias depois — quatro dos caminhos do gateway falharam em 08-27 — e quebrou corretamente em 09-05.
Tempo de atividade diário do grupo, dividido:
| data | todo o grupo | o gateway (97) | todos os outros (303) |
|---|---|---|---|
| 2026-09-02 | 89,5% | 95,9% | 87,5% |
| 2026-09-03 | 89,5% | 95,9% | 87,5% |
| 2026-09-05 | 75,8% | 60,8% | 80,5% |
| 2026-09-06 | 89,8% | 95,9% | 87,8% |
| 2026-09-07 | 77,8% | 48,5% | 87,1% |
Observe 2026-09-07. O número da população cai 12,0 pontos durante a noite. Os outros 303 servidores se movem 0,7 pontos — 37 fora no dia anterior, 39 fora naquele dia. Cada parte da queda é de um operador: 30 timeouts e 20 HTTP 503s no gateway.
Dê a cada operador um voto em vez de cada endpoint um voto — a média das taxas de tempo de atividade por operador, 242 operadores — e os mesmos dois dias leem completamente diferente:
| data | por-endpoint | por-operador |
|---|---|---|
| 2026-09-03 | 89,5% | 86,8% |
| 2026-09-05 | 75,8% | 80,3% |
| 2026-09-06 | 89,8% | 87,5% |
| 2026-09-07 | 77,8% | 86,9% |
Uma queda de 12,0 pontos por endpoint é uma queda de 0,6 pontos por operador. Se você está rastreando a "saúde do MCP" como uma série temporal construída a partir de contagens de endpoints, um pedaço da sua variância é uma tarde de uma empresa.
Observe que 09-05 e 09-07 não são o mesmo evento. Em 09-05, a cauda também se moveu (80,5% contra uma linha de base de ~87,5%), então o tempo de atividade por operador realmente caiu, em 7,2 pontos. Em 09-07, apenas o gateway se moveu. Dois mergulhos superficialmente idênticos na manchete, dois fatos subjacentes diferentes — que é todo o argumento para não ler a manchete.
Foi minha rede? Não, e os dados podem descartá-la em vez das minhas garantias. Latência mediana das respostas bem-sucedidas em 09-07: o gateway 13.272 ms, todos os outros 965 ms. Em um dia normal, o gateway é o rápido — 216 ms em 09-03 contra 688 ms para o resto. Ele estava lutando mesmo onde respondeu. O caso de contraste é 2026-08-25, quando o gateway rodou 3.943 ms e todos os outros rodaram 5.203 ms — ambos elevados juntos. Esse dia foi meu fim. 09-07 não foi.
O teste fora da amostra, que é por que a correção importa
Corrigir a concentração tornou a descoberta original mais forte, não mais fraca, e eu só descobri isso porque tive que refazer a análise.
O artigo de 08/27 classificou todos os 400 em três grupos usando 08/04–08/27. Os onze dias desde então são um holdout que a classificação nunca viu. 8 dos 11 dias são utilizáveis; 08-29, 08-30 e 09-04 estão excluídos porque a sondagem se reportou como completo: false e não retornou pontuações. Eles não são zeros, estão ausentes.
Porcentagem de cada grupo que teve zero dias de queda no holdout:
| grupo (atribuído 8/04–8/27) | n | limpo no holdout | n excl. gateway | limpo, excl. gateway |
|---|---|---|---|---|
| nunca perdeu um dia | 313 | 72,8% | 223 | 90,6% |
| a cauda parcial | 65 | 55,4% | 58 | 58,6% |
| nunca respondeu | 22 | 0,0% | 22 | 0,0% |
Média de dias de queda fora de 8, todos três nas populações de-concentradas para que sejam comparáveis: 0,15 para o bloco confiável (223), 1,88 para a cauda (58), 7,95 para o bloco morto (22). Agrupados sobre os 400, os primeiros dois são 0,36 e 2,18; o bloco morto é 7,95 de qualquer maneira, porque nenhum de seus membros está no gateway.
Duas coisas surgem.
T
Empresas brasileiras que dependem de servidores MCP devem estar atentas à concentração de dados em um único gateway, pois isso pode afetar a análise de desempenho e a tomada de decisões. A correção de dados é crucial para manter a integridade das informações e a confiança nas métricas.

