Alguns servidores no HostedMCP têm o selo Verified. Esta página explica exatamente o que o selo mede, para você decidir quanto peso dar a ele.
Verified significa que um servidor passou nas nossas verificações automatizadas, versão 2, no repositório público, nos pacotes, nas dependências, nas descrições de ferramentas e no endpoint. Não significa que uma pessoa revisou o código, e nós nunca executamos o servidor em seu nome. Leia como "nenhum problema óbvio encontrado em dados públicos", não como uma garantia de segurança.
As verificações
Executamos onze verificações, uma vez por semana e sempre que o README ou os pacotes de uma listagem mudam. Cada resultado mantém sua evidência e um link para a fonte pública de onde veio, para que você possa conferir por conta própria.
| Grupo | Verificação | Peso | Fonte | O que reprova |
|---|---|---|---|---|
| Origem | Repositório de origem | 10 | GitHub | um pacote sem repositório vinculado, ou um que não conseguimos acessar |
| Origem | O pacote indica o mesmo repositório | 5 | npm, PyPI | os metadados do próprio pacote apontam para um repositório diferente |
| Origem | Proveniência de build | 10 | atestações Sigstore no npm e no PyPI | conta apenas quando existe uma atestação; sua ausência não é uma constatação |
| Origem | Licença | 5 | GitHub, SPDX | nenhuma licença, ou uma que não seja aprovada pela OSI |
| Práticas | Manutenção | 5 | GitHub | nenhum commit e nenhuma release nos últimos 365 dias |
| Práticas | OpenSSF Scorecard | 15 | OpenSSF | abaixo de 7 de 10 recebe parte do peso, proporcional à pontuação |
| Cadeia de suprimentos | Nome do pacote | 10 | nossa lista de pacotes populares | um nome a uma ou duas letras de distância de um pacote popular sob outro proprietário |
| Cadeia de suprimentos | Avisos | 15 | deps.dev, OSV | um aviso crítico no pacote ou em qualquer dependência resolvida dessa versão |
| Segurança de ferramentas | Instruções ocultas | 15 | descrições de ferramentas, README | texto direcionado ao modelo ("ignore previous instructions", blocos <IMPORTANT>), Unicode invisível, ou uma descrição de ferramenta que aponta para arquivos como ~/.ssh |
| Segurança de ferramentas | Ferramentas destrutivas | 5 | anotações de ferramentas | uma ferramenta nomeada como delete_*, drop_* ou exec* sem a anotação destructiveHint |
| Endpoint | Handshake MCP | 5 | uma requisição ao vivo nossa | um endpoint remoto em HTTP simples, ou um que não responde a initialize |
Como a pontuação é calculada
Uma verificação só conta quando temos os dados para ela. Um servidor hospedado não tem pacote, então as verificações de pacote, proveniência e advisory não se aplicam a ele; um repositório que o Scorecard não analisou não tem resultado de Scorecard. As verificações ignoradas ficam de fora do total, então um servidor não é penalizado por uma verificação que não conseguimos fazer.
A pontuação é o peso das verificações que passaram, sobre o peso das verificações que executamos, mas nunca sobre menos de 60 pontos. Quando menos de 60 pontos puderam ser verificados, os pontos faltantes contam como não aprovados: um servidor verificado em 40 pontos que passou em todos eles recebe 67, não 100. Até 14 de novembro de 2026 esse piso não existia, e esses servidores mostravam 100. Para ser Verified, um servidor precisa de:
- uma pontuação de 80 ou mais,
- nenhuma constatação grave (nome do pacote, HTTP sem criptografia, instruções ocultas ou um advisory crítico),
- pelo menos 60 dos 100 pontos verificados, para que um listing com quase nenhum dado não passe por padrão,
- um repositório de código-fonte público que tenha passado na verificação.
Cada página de servidor lista todas as verificações com seu resultado, sua evidência, a data em que foi executada e, quando o Scorecard informa, o commit que ela descreve. Mantemos os dez últimos resultados por servidor.
O que ele não informa
As verificações leem dados públicos e fazem uma única solicitação de handshake para endpoints remotos. Elas não executam o código de um servidor nem auditam sua lógica. Um servidor pode passar em todas as verificações e ainda assim fazer algo que você não gostaria, e um servidor bem construído pode ficar abaixo do esperado porque os dados de que precisamos não são publicados. Um servidor oficial do fornecedor do produto costuma ser um sinal de confiança melhor do que este selo.
Antes de instalar um servidor local, lembre-se de que ele é executado com as permissões do seu usuário. Leia o código-fonte, prefira servidores publicados pela própria empresa do produto e forneça a cada um um token com o menor acesso necessário. Nosso guia de segurança do MCP aborda isso em mais detalhes.
Algo errado?
Se uma verificação sinalizou seu servidor por engano, reivindique a listagem e avise a gente, ou envie um e-mail para legal@hostedmcp.org. Se você acha que um servidor Verified é prejudicial, escreva para o mesmo endereço e vamos analisar em até 72 horas.