Voltar as noticias
Um gateway representou 24% da minha amostra e publiquei assim mesmo
MCP ProtocolMediaEN

Um gateway representou 24% da minha amostra e publiquei assim mesmo

Dev.to - MCP·7 de setembro de 2026

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 gatewaygateway.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

Contexto Triplo Up

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.

Noticias relacionadas

Gostou do conteudo?

Receba toda semana as principais novidades sobre WebMCP.