Se você está conectando servidores MCP a um agente, está assumindo uma dependência sem SLA, sem histórico de tempo de atividade e sem registro de falhas. Funciona na demonstração. Então, seis semanas depois, começa a falhar metade de suas chamadas, ou sua latência triplica, e ninguém percebe até que um fluxo de trabalho quebre.

Eu queria saber quão ruim isso realmente é, então construí um índice neutro de todo o ecossistema. Aqui está o que os dados dizem e uma maneira de 30 segundos para se proteger.

Os dados
Nós deduplicamos todos os servidores MCP que conseguimos encontrar nos principais registros. A contagem: 22.561 servidores.

Quantos têm algum dado de confiabilidade independente, significando que uma terceira parte realmente observou se eles funcionam em tempo de execução? Cerca de 0,5%.

Isso não são apenas projetos de hobby. Empresas reais também lançam servidores MCP (databricks, snowflake, paypal, netlify, appwrite, todos fazem), e a mesma lacuna se aplica em toda parte: dados de confiabilidade em tempo de execução independentes são a exceção, não a regra. E aqui está a parte que deve te incomodar mais do que a lacuna de cobertura. Entre os servidores que podemos medir, a maioria pontua na casa dos 40 baixos de 100. O ecossistema se otimizou para a quantidade de servidores e ignorou se eles funcionam.

Composição, para os curiosos: ~30% é código e ferramentas de desenvolvimento (a maior categoria de longe), o restante está fragmentado entre busca, dados, IA, produtividade e uma longa cauda.

Por que estrelas do GitHub não ajudam você
O instinto é confiar em um servidor porque o repositório tem estrelas ou a empresa é bem conhecida. Estrelas medem popularidade em um ponto no tempo. Elas não dizem nada sobre:

se o endpoint está ativo agora
sua taxa de sucesso quando chamado com argumentos reais
latência, especialmente a cauda p95 que estraga os loops do agente
se as descrições das ferramentas mudaram (um vetor real de injeção de prompt: um servidor pode trocar sua descrição de ferramenta depois que você confiou nele)
Uma empresa respeitável pode lançar um servidor MCP que é lento, instável ou abandonado. Sinais estáticos não vão pegar isso. Você precisa do comportamento em tempo de execução.

Como avaliar um servidor MCP (lista de verificação prática)
Chame-o você mesmo antes de confiar nele. Faça um verdadeiro handshake de inicialização e uma chamada de ferramenta representativa. Meça a latência e se realmente retorna resultados válidos.
Olhe para a cauda, não a média. Uma média de 50ms com um p95 de 6s significa que um em cada vinte passos do agente trava.
Verifique a atualidade. Quando o repositório foi tocado pela última vez? Um servidor abandonado é uma interrupção latente.
Trate as descrições das ferramentas como entrada não confiável. Elas são instruções voltadas para o modelo; um servidor malicioso ou comprometido pode envenená-las.
Obtenha um sinal independente. Um marketplace não pode avaliar de forma neutra os servidores que hospeda e vende (conflito de interesse), então procure uma terceira parte que meça o comportamento em tempo de execução.
Esse último ponto é a lacuna que estamos preenchendo. Você pode consultar a pontuação de confiança independente de qualquer servidor aqui: dominionobservatory.com/atlas/score. Servidores sem dados medidos aparecem como "não avaliados" em vez de um número falso, porque fingir saber é pior do que admitir que você não sabe.

A versão de 30 segundos: roteie através de um gateway de confiança
A proteção mais fácil é parar de chamar servidores desconhecidos diretamente e roteirizar as chamadas de ferramentas do seu agente através de um gateway de confiança. Você muda uma URL base. Ele verifica a pontuação do servidor, bloqueia qualquer coisa abaixo do seu limite, encaminha a chamada e devolve um recibo de atestação.

em vez de chamar o servidor diretamente:

POST https://target-server.com/mcp

roteie o mesmo corpo JSON-RPC através do gateway:

POST https://dominionobservatory.com/atlas/gateway?target=https://target-server.com/mcp&min_score=50
Uma chamada bloqueada retorna um 403 com a pontuação e o motivo. Uma chamada aprovada retorna a resposta normal do servidor mais cabeçalhos que você pode registrar para auditoria:

X-Dominion-Trust: pass:92
X-Dominion-Receipt: urn:dominion:gw:... (id do recibo de atestação)
X-Dominion-Attestation: link para o registro arquivável
Documentação do gateway: dominionobservatory.com/atlas/gateway.

Prefere verificar inline sem proxyar seu tráfego? Consulte a pontuação você mesmo antes de cada chamada:

import requests

def trust_ok(server_url, min_score=70):
r = requests.get("https://dominionobservatory.com/atlas/server",
params={"url": server_url}, timeout=5)
if r.status_code == 404:
return True # não indexado ainda, permitir mas registrar
d = r.json()
score = d.get("trust_score")
if score is None or not d.get("total_calls"):
return True # não avaliado: sem dados independentes ainda
return score >= min_score

if not trust_ok("https://some-mcp-server.com/mcp"):
raise RuntimeError("Bloqueado: servidor MCP abaixo do limite de confiança")
Ambos os padrões (gateway + inline), com JavaScript: dominionobservatory.com/atlas/gate.

Por que isso importa mais a cada mês
A regulamentação está alcançando. A governança de IA agente da IMDA de Cingapura está em vigor, as obrigações de transparência da Lei de IA da UE se aplicam a partir de agosto de 2026, e a manutenção de registros do MiCA está ativa. Se seus agentes agem com ferramentas de terceiros, você cada vez mais terá que provar o que eles usaram e que foi verificado. Os próprios registros internos de uma empresa não são um registro neutro. Esse é um post diferente, mas está chegando rápido.

Por enquanto: pare de confiar em servidores MCP porque são populares. Meça-os, ou use alguém que o faça.

Dados completos do ecossistema: dominionobservatory.com/atlas/report. Se você construir ou operar um servidor MCP, eu realmente gostaria de saber sua opinião: o que faria uma pontuação de confiabilidade que você realmente confiaria