Onde você hospeda seu servidor MCP determina sua durabilidade

Eu investiguei todos os servidores MCP remotos listados no registro oficial — 10.716 endpoints — e então fiz uma pergunta que os números agregados escondem: quando uma listagem está morta, onde ela está hospedada?

A resposta não está distribuída de forma uniforme. Não está nem perto de ser distribuída uniformemente.

Taxa de falha por plataforma de hospedagem

Contando um endpoint como falho se ele retorna um 404 duro, falha no DNS, expira, recusa a conexão ou apresenta 5xx:

Um servidor MCP na Vercel é aproximadamente onze vezes mais provável de ainda responder do que um atrás de um túnel rápido do Cloudflare, e cerca de dez vezes mais provável do que um na Smithery.

Isso não é uma afirmação sobre a qualidade da engenharia. É uma afirmação sobre o que cada uma dessas coisas é.

O padrão é efemeridade, não qualidade

URLs trycloudflare.com vêm de túneis rápidos — eles são projetados para serem temporários e o nome do host muda toda vez que você reinicia. Túneis gratuitos do ngrok têm a mesma ideia. Os níveis gratuitos da Railway e Render entram em modo de espera e podem ser recuperados. Uma URL de qualquer um desses é uma conveniência de desenvolvimento que alguém colou em um diretório público permanente.

A Vercel e workers.dev se comportam de maneira diferente: a URL é estável, o nível gratuito não expira o nome do host, e uma implantação que para de receber tráfego ainda resolve.

Portanto, o registro não está cheio de projetos abandonados, mas sim de projetos cuja porta da frente nunca foi permanente desde o início. O código pode estar bom. A listagem aponta para uma porta que se moveu.

Concentra-se fortemente

1.490 endpoints no registro estão mortos no sentido mais forte — 404 duro no caminho anunciado, ou DNS que não resolve mais. Esses estão espalhados por apenas 343 domínios, e os dez principais domínios representam 67% deles:

191  smithery.ai
173  railway.app
125  wishpool.app
109  mctx.ai
100  klymax402.com
 84  trycloudflare.com
 63  onrender.com
 63  apify.com
 62  workers.dev
 34  alpic.live

Vários desses são plataformas que geram endpoints MCP em massa. Quando uma delas muda um esquema de URL ou expira um nível, centenas de entradas do registro quebram de uma vez. Este é o modo de falha de um diretório que armazena URLs em vez de resolvê-las.

177 listagens nunca tiveram uma URL real

Enquanto agrupava falhas, encontrei entradas cujas URLs ainda contêm variáveis de modelo não substituídas:

https://{api_host}/mcp
https://{HAPI_FQDN}:{HAPI_PORT}/mcp
https://{ATLAS_MCP_URL}
https://{roster_host}/mcp

177 listagens contêm um espaço reservado, um localhost ou um example.com. 73 delas falham no DNS pela razão óbvia.

O subconjunto interessante é a outra metade: 14 delas estão ativas. URLs como https://mcp.cardog.io/mcp?api_key={api_key} funcionam porque o espaço reservado está em um parâmetro de consulta que o servidor ignora quando ausente. O autor pretendia como documentação — "coloque sua chave aqui" — e o registro armazenou isso como um endpoint literal. Ambas as leituras são razoáveis. Apenas uma delas é uma URL.

O que eu faria com isso

Se você está publicando um servidor MCP: a escolha da hospedagem é uma decisão de durabilidade sobre sua listagem, não apenas sobre seu aplicativo. Um túnel rápido em um diretório permanente tem uma vida útil esperada medida em horas. Use algo com um nome de host estável antes de publicar a URL em algum lugar que você não pode atualizar facilmente.

Se você está consumindo o registro: não trate uma listagem como um endpoint. Cerca de um quarto delas não irá atendê-lo, as falhas se agrupam por plataforma, e aproximadamente uma em sessenta contém um espaço reservado que alguém esqueceu de preencher. Resolva antes de depender.

Se você mantém um diretório de URLs: este é o argumento para revalidação periódica. Um registro que nunca re-verifica suas entradas converge para ser uma lista de coisas que costumavam existir.

Método

Cada entrada remota ativa em registry.modelcontextprotocol.io, deduplicada por URL — 10.716 endpoints. Uma chamada JSON-RPC initialize anônima cada, timeout de 10s, classificada pela resposta real. Consciente do transporte: o registro declara 9.647 streamable-http e 1.068 remotos legados sse, e o transporte legado abre com um GET em vez de um POST, então sondar tudo com um verbo inflaciona a contagem de 405/404. Eu verifiquei isso especificamente — quase nada mudou, mas eu verifiquei antes de publicar em vez de depois.

A sondagem anônima é um limite inferior. Um servidor que requer uma chave é contado como vivo, mas restrito, não morto, e eu não posso ver se está saudável atrás da chave.

Contagens são um momento no tempo. Re-executar é o ponto; instantâneas únicas de um sistema em movimento são anedóticas com casas decimais.

Anteriormente: Eu verifiquei todos os servidores MCP no registro oficial — o censo sobre o qual esta análise é construída, incluindo a correção onde minha primeira tentativa cobriu 3% do registro e eu publiquei como 'todos'.