Voltar as noticias
Verificando a Confiabilidade de Servidores MCP
MCP ProtocolAltaEN

Verificando a Confiabilidade de Servidores MCP

Dev.to - MCP·5 de junho de 2026

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 se refere apenas a projetos de hobby. Empresas reais também enviam servidores MCP (databricks, snowflake, paypal, netlify, appwrite, todos fazem isso), e a mesma lacuna se aplica em geral: dados de confiabilidade de 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 nos baixos 40s 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 é 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 arruína loops de agentes
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 enviar 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 para.
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: controle chamadas de ferramentas com confiança
Você não quer fazer isso manualmente em cada chamada. Controle isso. Consulte uma pontuação de confiança independente antes que seu agente chame uma ferramenta e bloqueie qualquer coisa abaixo do seu limite:

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 é None ou não d.get("total_calls"):
return True # não avaliado: sem dados independentes ainda
return score >= min_score

antes de chamar uma ferramenta:

if not trust_ok("https://some-mcp-server.com/mcp"):
raise RuntimeError("Bloqueado: servidor MCP abaixo do limite de confiança")
JavaScript e o padrão completo estão aqui: 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 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 rapidamente.

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 executar um servidor MCP, eu realmente gostaria de saber sua opinião: o que faria uma pontuação de confiabilidade que você realmente confiaria?

Contexto Triplo Up

Empresas brasileiras que utilizam servidores MCP devem estar cientes da falta de dados de confiabilidade, o que pode impactar diretamente suas operações. A implementação de um sistema de verificação independente pode evitar falhas em fluxos de trabalho. A regulamentação crescente em IA também exige maior transparência e responsabilidade.

Noticias relacionadas

Gostou do conteudo?

Receba toda semana as principais novidades sobre WebMCP.