MCP Registry: como auditar um servidor antes de colocar um agente em produção

O catálogo oficial de servidores MCP↳MCP7 conteúdosArquitetura de Sistemas Cognitivos: Integração de RAG, MCP e LLMs no Ecossistema .NETDev (Back & Front) · abr 2026MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025Agentes de IA com LLMs de Código Aberto: Integração Prática com o Model Context Protocol (MCP)AI · ago 2025Ver tudo em AI → ainda está em preview, com API travada na versão 0.1 desde outubro de 2025. Antes de plugar um servidor do Registry num agente em produção, vale rodar o checklist que o próprio projeto disponibiliza.

O catálogo oficial de servidores MCP ainda está em preview, com API travada na versão 0.1 desde outubro de 2025. Antes de plugar um servidor do Registry num agente em produção, vale rodar o checklist que o próprio projeto disponibiliza.

Por que auditar antes de plugar no agente

O MCP Registry (modelcontextprotocol/registry) se define como "um app store para servidores MCP": uma lista centralizada que clients MCP podem consultar para descobrir servidores. É um projeto comunitário mantido pelo Registry Working Group, hoje com Radoslav Dimitrov (Stacklok) como líder, além de Tadas Antanavicius (PulseMCP), Bob Dickinson (TeamSpark) e Preeti Dewani (Ravenmail).

Dois marcos de status importam para quem vai confiar nesse catálogo em produção. O registry saiu de uma fase interna e entrou em preview público em 8 de setembro de 2025, por meio de um post de anúncio. Em 24 de outubro de 2025 a API entrou em freeze na versão v0.1: o projeto promete estabilidade "por pelo menos um mês" enquanto integradores testam, mas deixa claro que o freeze vale só para a v0.1, e que o desenvolvimento da v0 (e depois da v1, essa sim mirando GA) continua em paralelo.

Em resumo: você está consumindo um catálogo que ainda pode resetar dados, ainda não tem GA e cuja API é estável só dentro da janela de freeze anunciada. Isso muda o que "validar um servidor" significa aqui: não basta ler a descrição no catálogo, é preciso auditar o manifesto, a procedência do publicador e rodar o servidor isolado antes de confiar nele dentro de um agente real.

Passo 1: suba o registry localmente antes de confiar no público

O primeiro movimento é não auditar direto contra a API de produção. O próprio repositório publica imagens Docker↳Docker46 conteúdosE o Docker Swarm? Contextos e motivadores diáriosDevSecOps · ago 2024Automatizando o ambiente de desenvolvimento e testes com DockerDevSecOps · mai 2019MySQL + Adminer + Docker Compose: montando rapidamente um ambiente para usoData · abr 2019Ver tudo em DevSecOps → prontas, então dá para inspecionar o comportamento do registry (e, por extensão, os metadados que ele expõe sobre um servidor) num ambiente isolado antes de apontar qualquer coisa para produção.

# Sobe o registry completo com PostgreSQL (dados efêmeros, resetam a cada restart)
make dev-compose

# Alternativa: imagem pronta, publicada automaticamente no GHCR
# Atenção: essa imagem não empacota PostgreSQL. É preciso subir um Postgres
# próprio e apontar o registry para ele via MCP_REGISTRY_DATABASE_URL
# (veja o docker-compose.yml do repositório para um exemplo funcional)
# antes de rodar o comando abaixo.
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:v1.0.0

A própria documentação do projeto é explícita sobre essa imagem alternativa: ela "não empacota PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →, então você precisa rodar o seu próprio e apontar o registry para ele via MCP_REGISTRY_DATABASE_URL" (veja o docker-compose.yml para um exemplo funcional). A documentação não detalha o que acontece se o registry for iniciado sem essa variável configurada e sem um Postgres próprio apontado; o caminho seguro é garantir o banco e a variável antes de rodar o comando acima.

Por padrão, o make dev-compose semeia o ambiente local a partir de um subconjunto filtrado da própria API de produção, para garantir que o seed reflete dados que passam na validação real. Se você quer trabalhar offline, sem bater na produção, existe um atalho explícito, mas ele desliga a validação de schema:

MCP_REGISTRY_SEED_FROM=data/seed.json MCP_REGISTRY_ENABLE_REGISTRY_VALIDATION=false make dev-compose

Esse detalhe importa: rodar com MCP_REGISTRY_ENABLE_REGISTRY_VALIDATION=false é ótimo para desenvolvimento, mas não prova nada sobre a qualidade de um manifesto real. Se o objetivo é auditoria, a validação precisa estar ligada.

Passo 2: verifique quem publicou, não só o que foi publicado

Aqui está o ponto que mais surpreende quem vem de registries tipo npm ou PyPI: um Pull Request neste repositório, adicionando um server.json, um diretório de servidor ou uma entrada em data/seed.json, não publica nada. A documentação é explícita: mesmo que o PR seja aceito e mergeado, isso não lista o servidor no catálogo real. A publicação de verdade acontece por outro caminho, fora do GitHub do registry.

Quem publica usa a CLI oficial, o mcp-publisher, e precisa provar posse do namespace que está reivindicando:

# Builda a CLI de publicação a partir do próprio repo
make publisher
./bin/mcp-publisher --help

A prova de posse de namespace segue regras específicas, e é aqui que mora a parte útil para auditoria: um namespace io.github.<usuario>/<servidor> só pode ser publicado por quem está logado como aquele usuário no GitHub (via OAuth) ou rodando dentro de uma GitHub Action no repositório daquele usuário (via OIDC). Já um namespace de domínio próprio, como me.adamjones/<servidor>, exige prova de posse do domínio por verificação DNS ou HTTP. Na prática, isso funciona como um selo mínimo: antes de confiar num servidor, vale checar se o namespace dele bate com uma identidade real e verificável, não com um nome escolhido livremente.

Passo 3: rode a validação de schema do próprio manifesto

O repositório mantém, dentro de pkg/model/, os modelos de dados que descrevem a estrutura esperada de um server.json, e dentro de internal/validators/ a lógica que checa se um manifesto cumpre essa estrutura. Existem ainda scripts dedicados em tools/validate-*.sh só para validação de schema. O comando que amarra tudo isso (lint, validação de schema e todos os testes) é um só:

make check

Vale rodar esse comando contra o server.json do servidor que você pretende usar, mesmo que ele já esteja listado no catálogo público: estar listado hoje não garante que o manifesto permanece válido amanhã, especialmente enquanto o projeto ainda está em preview e sujeito a mudança de schema antes da GA. Se make check falhar, você já tem o primeiro tropeço documentado antes de colocar o servidor na frente de um agente.

Passo 4: rode isolado com um client MCP antes do agente real

O manifesto validado nos passos anteriores responde "quem publicou isso" e "o manifesto segue o schema esperado", mas não responde sozinho "o que esse servidor realmente faz quando chamado". O que um servidor expõe de fato em runtime (tools, resources, prompts) pode ou não bater exatamente com o que o manifesto promete, e isso só se confirma rodando o servidor de verdade.

O caminho que eu seguiria, antes de qualquer promoção para produção, é rodar o servidor isolado com um client MCP de teste, observando quais tools ele expõe de fato e com quais parâmetros, comparando isso com o que o manifesto promete. Só depois, com esse comportamento observado, eu plugaria o servidor num agente real, de preferência num ambiente de staging que reproduza as mesmas chamadas que o agente faria em produção.

Os tropeços que você vai encontrar

Num projeto ainda em preview, com API em freeze parcial, alguns problemas são praticamente garantidos ao longo desse processo:

• Versão com schema quebrado: como o freeze cobre só a v0.1 da API, e o desenvolvimento de v0/v1 continua em paralelo, um server.json validado hoje pode falhar em make check depois de uma mudança de schema; rodar a validação de novo antes de cada deploy evita surpresa.
• Escopo de permissão mal declarado: a responsabilidade de declarar corretamente as tools cai sobre quem publicou o servidor; o manifesto válido não é garantia de que a lista de capabilities está completa ou atualizada.
• Ausência de um mecanismo formal de assinatura do artefato: a documentação descreve prova de posse de namespace (OAuth, OIDC, DNS, HTTP), mas não detalha um mecanismo de assinatura criptográfica do pacote publicado em si; a confiança, hoje, está mais em "quem é o dono do nome" do que em "o binário não foi alterado depois de publicado".
• Dados que resetam: ambientes locais subidos com make dev-compose usam armazenamento efêmero e reiniciam limpos a cada restart, então qualquer teste de regressão precisa ser reproduzido, não só rodado uma vez.

O que fica em aberto

O projeto ainda caminha para uma GA, e a própria documentação trata a v0.1 como um freeze temporário para coletar feedback, não como a versão final da API. Isso quer dizer que o roteiro de auditoria descrito aqui, rodar local, checar namespace, validar schema, isolar com um client antes do agente, tende a continuar necessário até que o registry assuma formalmente mecanismos mais fortes de verificação de artefato. Até lá, tratar o catálogo como ponto de partida, e não como selo de confiança pronto, é a diferença entre um servidor MCP auditado e um servidor MCP só listado.

Fonte: MCP Registry — documentação oficial (modelcontextprotocol/registry)