Tentamos verificar independentemente todos os 22.561 servidores MCP. Apenas 18 puderam ser checados.
Eu mantenho um índice deduplicado de 22.561 servidores MCP. Tentei verificar independentemente todos eles em tempo de execução. Não escaneando a fonte no repositório, mas realmente acessando o servidor em execução para verificar se ele responde e se comporta como esperado. Apenas 18 puderam ser verificados.
Isso diz muito sobre como confiamos nas ferramentas que nossos agentes chamam.
Os números
- 22.561 servidores MCP indexados, deduplicados entre registros.
- 117 têm algum registro de comportamento ou confiabilidade independente. Isso é 0,52%.
- 18 expõem um endpoint MCP ativo que posso acessar e testar independentemente. Isso é 0,08%.
- 8.655 listam um endpoint http. Apenas cerca de 150 resolvem para um serviço hospedado real. Apenas 18 desses realmente respondem como um servidor MCP funcional.
O restante são repositórios do GitHub, pacotes npm ou servidores stdio locais. Código que você pode ler, mas não um serviço em execução que alguém possa verificar em produção.
Escaneamentos estáticos leem o código. Eles nunca veem o servidor em execução.
A maneira popular de avaliar um servidor MCP hoje é um escaneamento estático: ler a fonte no repositório, procurar problemas conhecidos, dar uma nota. Isso é útil, mas classifica o código em um repositório. Não é o servidor ao qual seu agente se conecta no momento da chamada, e os dois podem diferir.
Um servidor pode passar por uma revisão de código e então, em produção, ser lento, estar fora do ar, ter sido trocado ou se comportar de maneira completamente diferente de sua descrição. Os ataques que a comunidade de segurança mais se preocupa para agentes, envenenamento de ferramentas e rug pulls, acontecem em tempo de execução, após um humano aprovar o servidor. É exatamente onde um escaneamento estático não consegue ver.
A lacuna
Portanto, temos um ecossistema onde 99,9% dos servidores não podem ser acessados ou testados independentemente em produção, e o sinal de confiança dominante é uma leitura única de código que nem mesmo é o artefato em execução.
Isso não é um registro de confiabilidade. É uma caixa preta com um README bonito.
Se você executa agentes em produção, a questão não é se esse código passou por um escaneamento. É posso provar o que esse servidor fez nas últimas mil vezes que um agente o chamou. Hoje, para quase todos os servidores MCP, ninguém pode.
O que estou fazendo a respeito
Eu meço servidores MCP pelo comportamento, não lendo seu código. Todo servidor que consigo acessar é testado para verificar se responde, com que frequência, quão rápido e se faz o que afirma, ao longo do tempo, com um registro assinado e à prova de adulteração, para que a história não possa ser silenciosamente reescrita.
É uma pequena fatia do ecossistema hoje porque o ecossistema é estruturalmente difícil de verificar. Esse é o ponto. A lacuna é a história.
- Verifique qualquer servidor: https://dominionobservatory.com/atlas/score
- Os dados completos: https://dominionobservatory.com/atlas/report
- Como a verificação em tempo de execução funciona: https://dominionobservatory.com/atlas/liveness
Como você está verificando os servidores MCP que seus agentes usam em produção, se é que está?
O artigo destaca a dificuldade de verificar a confiabilidade dos servidores MCP, um aspecto crucial para empresas que dependem de agentes de IA. A falta de testes em tempo real pode levar a problemas de segurança e desempenho, impactando diretamente a operação de negócios.


