Descoberta pré-autenticação no MCP: o que os números dizem e o que um diretório vê

Desde maio de 2025, o repositório da especificação MCP carrega uma questão em aberto (#540): um servidor MCP deve expor o que oferece antes que um cliente se autentique? O tópico foi discutido por mais de um ano — autodescrição versus limites de autenticação, descobribilidade versus menor exposição. Esta semana, finalmente obteve dados, e os dados mudam a forma do argumento.

Este post cobre a medição do lado do probe e adiciona a visão que geralmente não obtemos nesses tópicos: o que um diretório de servidores vê quando tenta descrever servidores MCP em escala de ecossistema.

A medição

unempyd sondou endpoints MCP remotos anonimamente — um initialize e um tools/list por endpoint, no máximo um endpoint por domínio de publicador — e publicou o método e os resultados (relatório completo).

A primeira passagem amostrou 100 endpoints do registro oficial: 45 retornaram uma lista de ferramentas sem credenciais. A correção que se seguiu é mais importante do que essa manchete. De 20.492 conectores remotos no maior índice público, 16.375 não declaram autenticação alguma. Para quatro quintos da população, responder tools/list sem autenticação é uma configuração documentada, não um erro — contar isso não diz nada sobre nada.

A população onde a questão significa algo são os 117 endpoints cujos operadores escolheram exigir credenciais (OAuth2 ou uma chave de API). Desses:

• 18 serviram a lista completa de ferramentas para um chamador anônimo — eles pretendem exigir autenticação e não a aplicam em tools/list
• 19 recusaram, mas sem um desafio RFC 9728 que um cliente pudesse seguir — uma recusa que nenhum cliente compatível pode agir
• 79 recusaram corretamente, com metadados de recurso protegido que se resolveram
• 1 anunciou metadados que não poderiam ser buscados

Portanto, aproximadamente 15% dos endpoints que pretendem exigir autenticação não a aplicam em tools/list, e outros 16% recusam de uma forma que nenhum cliente compatível pode agir.

A falha também não está distribuída uniformemente. Contra os endpoints MCP de primeira parte de doze grandes fornecedores de SaaS que documentam uma exigência de OAuth, nenhum dos onze que responderam serviu qualquer coisa. As falhas se concentram em servidores construídos por pequenas equipes — precisamente onde um padrão padrão faz mais trabalho, porque um padrão é fundamental exatamente para as pessoas que não lerão a especificação.

O que o lado do diretório vê

Indexamos 69.077 servidores MCP do GitHub, npm e fonte PyPI, 133.426 rastreados em todo o ecossistema (marketnow.site). Aqui está a parte da população que a sondagem do lado do endpoint não pode ver: a maioria dos servidores MCP não tem nenhum endpoint remoto acessível. Eles existem como repositórios e pacotes. Para a maioria do ecossistema, a única superfície de descoberta pré-autenticação que existe hoje é o código-fonte e os metadados do pacote.

A questão do endpoint e a questão da descobribilidade já estão desacopladas na prática. Qualquer resposta para #540 que apenas governe o que um endpoint ativo serve deixa a maior parte do ecossistema exatamente onde já está: descrito por READMEs, manifestos de pacotes e análise estática.

Um 401 é indistinguível de um erro

Do lado do diretório, a ambiguidade é concreta. Quando um servidor retorna 401 para um chamador anônimo, um crawler não pode distinguir "autenticação exigida por design" de "mal configurado" — a intenção do operador não é legível por máquina. Classificamos a partir da fonte quando o endpoint recusa: ferramentas do README e metadados do pacote, risco de instalação a partir da análise estática, e a listagem é rotulada como "autenticação exigida, não sondada." Isso é uma solução alternativa, não um sinal. É honesto sobre o que sabemos, mas não pode informar a um operador que seu servidor é um dos 18.

Nada pode, hoje. Essa é a parte do argumento final na discussão que atravessa todo o debate: um servidor que pretende exigir autenticação e falha em aplicá-la não tem um mecanismo que torne a falha visível para seu próprio operador.

O meio-termo que ainda não existe

O compromisso proposto na discussão — um manifesto de capacidade não autenticado em vez da lista de recursos concreta — tem uma ausência mensurável. Na primeira passagem, nenhum dos servidores pré-autenticados serviu algo que se parecesse com um manifesto. O que existe na prática é binário: recusa total ou a superfície chamável completa — mediana de 5 ferramentas, máximo de 302, 926 ferramentas divulgadas na amostra, com nomes e esquemas de entrada incluídos.

Um manifesto assinado com nomes de capacidade e contagens — sem esquemas de entrada, nada chamável — resolveria ambas as direções ao mesmo tempo. Diretórios poderiam descrever um servidor sem que sua fronteira de autenticação vazasse qualquer coisa explorável. Operadores que desejam descoberta teriam um canal que não requer servir a lista concreta de ferramentas. E a classificação de risco de instalação se tornaria substancialmente menos dependente da análise de fonte, que atualmente é a única alternativa honesta.

A barreira RFC 9728

Qualquer que seja a solução a longo prazo, há um piso disponível agora: um 401 deve publicar metadados de recurso protegido que se resolvem. Dezenove dos 117 nem sequer ultrapassam essa barreira. Um crawler que entende o RFC 9728 pode pelo menos registrar a fronteira de autenticação corretamente — que é a diferença entre "autenticação exigida, não sondada" como uma suposição e como um fato verificado.

O que fazemos enquanto isso

A indexação focada na fonte é a estratégia, independentemente de como a especificação se concretize. Um servidor com autenticação ainda recebe uma listagem real — capacidades, classificação de segurança, rotulado honestamente em vez de silenciosamente vazio. O pipeline de submissão pública valida e lista a partir da fonte, para que um servidor possa ser descoberto sem nunca servir um endpoint anônimo. E as 29 regras estáticas por trás dos níveis de risco de instalação — padrões de injeção nas descrições de ferramentas, segredos embutidos, APIs perigosas — são executadas contra a fonte, onde os mesmos padrões que envenenam as descrições de ferramentas implantadas são visíveis antes que alguém as implante.

Se a descoberta pré-autenticação se tornar padrão, os 18 deixam de ser um erro. Se não, eles precisam de algo no protocolo que torne a falha visível. De qualquer forma, o lado do diretório continua descrevendo servidores a partir da fonte — porque para a maioria do ecossistema, esse é o único lado que existe.