MCP registry: como descobrir, autorizar e versionar ferramentas de agente em escala

Um catálogo de ferramentas de agente não é uma planilha que alguém mantém atualizada. É infraestrutura. O MCP registry é a camada que catalogou cada servidor MCP publicado, registra quem pode enxergá-lo e diz qual versão está de pé; e ele decide o que existe antes de qualquer gateway decidir o que passa.

O blog já cobriu as duas camadas vizinhas. O protocolo MCP define como a mensagem viaja entre modelo e ferramenta. O gateway MCP define o que passa, com que política, a que custo e com que auditoria. Nenhuma das duas responde à pergunta que aparece antes de todas elas: quais ferramentas existem, quem pode vê-las e qual versão está atendendo quem.

Essa pergunta é barata de responder com 8 servidores MCP. Com 80, ela vira um problema de catálogo, e o catálogo tem metadado, política e ciclo de vida. O gargalo deixou de ser latência e passou a ser saber o que existe.

O que é um MCP registry?

Um MCP registry é um catálogo de metadados de servidores MCP: nome, dono verificado, onde o pacote está hospedado, como executar e quais tools cada servidor publica. Ele não hospeda código nem tráfego. Hospeda a informação que permite a um cliente descobrir e conectar um servidor sem que um humano cole uma URL em um arquivo de configuração.

O registry oficial do Model Context Protocol entrou em preview em 8 de setembro de 2025, anunciado no blog do próprio protocolo com a assinatura de seus mantenedores e de Theodora Chu, gerente de produto do MCP na Anthropic. O texto de lançamento é direto sobre a intenção: ser a fonte única de verdade para servidores MCP públicos, com o registry e a especificação OpenAPI que o descreve publicados como código aberto.

Duas decisões desse anúncio importam mais do que o lançamento em si.

A primeira é a separação entre metadado e pacote. npm, PyPI e Docker Hub continuam hospedando código e binários. O registry hospeda o ponteiro. Um pacote weather-mcp mora no npm; o registry guarda que aquele servidor, naquela versão, corresponde àquele pacote. Quando alguém pergunta por que a instalação falhou, a resposta pode estar em qualquer um dos dois, e são dois donos diferentes.

A segunda é que o registry oficial não é para ser consumido direto por aplicações cliente. A documentação é explícita: ele é feito para agregadores a jusante, como marketplaces de servidores MCP, que puxam o metadado por REST API em intervalos regulares (o exemplo que a própria documentação cita é uma vez por hora) e curam em cima disso. Aplicações cliente consomem esses outros registries, que implementam a mesma especificação OpenAPI.

Aqui está a consequência que quase ninguém planeja. O registry público resolve a descoberta do que é público. Ele não resolve a descoberta do que é seu.

Por que o registry público não resolve o problema do seu time

O registry oficial não aceita servidores privados. A documentação trata o caso sem rodeio: servidores acessíveis apenas a um conjunto restrito de usuários, publicados em rede interna ou em registry de pacote privado, não entram. A recomendação para esse contexto é hospedar um registry privado próprio e colocar os servidores lá.

Isso não é uma limitação contornável com configuração criativa. É desenho. O registry público é um mecanismo de namespace e procedência para o que é aberto; o seu catálogo interno é outra coisa, com outro dono, outra política e outro ciclo de vida.

A partir daí, a contagem de integrações de uma empresa vira o problema real. Um time de plataforma que roda agentes em produção acumula servidores MCP de três origens distintas, e cada origem tem um regime de confiança diferente:

• Servidores públicos, instalados a partir de um pacote em npm, PyPI ou Docker Hub, com procedência verificável pelo registry oficial.
• Servidores internos, escritos pelo próprio time, que expõem sistemas da empresa e não têm lugar no catálogo público.
• Servidores de terceiros contratados, que rodam remotos, exigem OAuth e trazem o próprio ciclo de revisão.

Sem um catálogo, a descoberta acontece no escuro. O agente descobre a tool que o desenvolvedor colou no arquivo de configuração dele. Não existe inventário, não existe dono declarado, não existe política de escopo. E aí aparece a pergunta que trava a reunião de arquitetura: este agente pode chamar o servidor que emite nota fiscal?

Escopo de descoberta: o mesmo servidor, três respostas

Aqui está o ponto que separa um catálogo de uma lista. Um catálogo responde o que existe no repositório geral. Um registry responde o que existe para você, aplicando política de visibilidade segregada por time, agente e ambiente operacional para proteger ferramentas críticas de acessos indevidos.

O metadado de um servidor MCP publicado é único. A visibilidade dele não é. O mesmo servidor de leitura de banco aparece para o agente de análise financeira e desaparece para o agente de suporte ao cliente, e a diferença mora na política de escopo, não no registro.

A permissão da ferramenta não é a permissão do agente, e essa confusão custa caro. Quem resolveu identidade e rastreabilidade do agente cobriu metade do problema; a outra metade é o escopo de publicação e de descoberta no nível do servidor MCP e da tool que ele expõe. As permissões de acesso e rastreabilidade em agentes de IA respondem quem é o agente e o que ele fez. O registry responde o que ele pode encontrar.

A autorização de um servidor MCP remoto

Autorizar um servidor MCP remoto é um fluxo OAuth 2.1, e o protocolo não deixa isso no ar. Quando o transporte é HTTP, o servidor protegido atua como resource server OAuth e o cliente descobre os metadados do authorization server antes de qualquer chamada. Transporte local por stdio segue o caminho oposto: as credenciais vêm do ambiente, e a especificação recomenda que esse caminho não siga o fluxo OAuth.

Vale marcar o que é opcional e o que não é, porque a leitura preguiçosa trata os dois como iguais.

O subconjunto é a parte interessante. A especificação diz, em texto, que implementa uma seleção de features dessas normas para preservar segurança e interoperabilidade sem carregar complexidade desnecessária. Traduzindo para a operação: não existe um servidor MCP "com OAuth completo" e outro "sem OAuth". Existe um conjunto específico de capacidades acordadas, e é contra ele que o seu catálogo precisa registrar o que cada servidor exige.

O ciclo de vida de publicação de uma tool

Publicar uma tool em um catálogo é um procedimento com etapas, e cada etapa deixa um registro que alguém vai consultar depois. O ciclo abaixo segue o que a documentação do registry oficial exige de um publicador.

1. Verificar o namespace. O nome do servidor segue formato de DNS reverso e amarra a origem a uma conta verificada. Com autenticação por GitHub, o nome assume a forma io.github.usuario/*; com autenticação por domínio, a forma com.exemplo.*/* e a prova vem de um registro TXT publicado no DNS daquele domínio.
2. Declarar o metadado. O server.json carrega o nome único, a versão, onde o servidor está hospedado, as instruções de execução e os dados de descoberta. É esse arquivo que um agregador vai ler.
3. Publicar a versão. A versão é obrigatória, precisa ser única por publicação e, uma vez publicada, versão e metadado não podem mais ser alterados. Corrigir significa publicar de novo.
4. Aplicar o escopo. O catálogo interno recebe a entrada com dono, time, ambiente e as tools expostas, e é aqui que a visibilidade deixa de ser uniforme.
5. Registrar a política de autorização. O que aquele servidor exige para ser chamado, e qual identidade de agente pode listá-lo.
6. Consumir e versionar. Clientes e agregadores puxam o metadado, e cada consumidor passa a depender de uma versão específica. A dívida começa exatamente aqui.

O passo 3 é onde a maioria das arquiteturas perde o controle, e a documentação explica por quê. O registry recomenda versionamento semântico, mas aceita qualquer formato de string. Quando a versão publicada não parseia como semântica, ela é marcada como "latest" de qualquer forma. E existe uma proibição explícita: strings que parecem faixa de versão, como ^1.2.3, ~1.2.3, 1.x ou 1.2.*, são recusadas.

Repare no que isso significa para o seu catálogo interno. Você pode registrar 2025.11.25 e 2025.6.18 como versões válidas, e a comparação entre elas deixa de ser aritmética. Se uma das duas não parseia, o critério de desempate passa a ser o timestamp de publicação. Um catálogo que ordena versão por string coloca 1.10.0 antes de 1.9.0.

Como versionar sem quebrar quem já consome

A regra do registry é dura e vale internalizar: a versão publicada não muda. Metadado publicado não muda. Se um servidor precisa corrigir o que declarou, ele publica uma versão nova, e a anterior continua existindo no histórico.

Isso protege a integridade do catálogo e transfere o problema para o consumidor. Quarenta consumidores escritos contra a v1 de um servidor não migram porque a v2 ficou disponível. Migram quando alguém decide que migram. E essa decisão precisa de um lugar para morar.

O protocolo tem uma peça que ajuda, e ela é recente o suficiente para passar despercebida. Na revisão em vigor, a corrente 2026-07-28, cada requisição declara a versão do protocolo que usa, e o servidor aceita ou rejeita requisição por requisição. Se o servidor não suporta a versão pedida, ele responde com um erro que lista as versões que suporta, e o cliente pode tentar de novo com uma versão mútua. A negociação é por chamada, não por sessão.

Junto com isso, um cliente que quer escolher a versão antes de tudo pode chamar uma RPC obrigatória que devolve, numa única requisição, as versões suportadas, as capacidades e a identidade do servidor. Chamar é opcional. Saber que ela existe não é.

O detalhe que fecha o argumento é este: um servidor MCP declara se vai emitir notificação quando a lista de tools disponíveis mudar. Ou seja, a descoberta de ferramentas em MCP é dinâmica por contrato, não por convenção. Um agente conectado a um servidor pode ver o conjunto de tools crescer ou encolher durante a operação.

E é exatamente por isso que um arquivo de configuração estático não é um catálogo. Ele é uma fotografia. Se o servidor muda o conjunto de tools e a sua política de descoberta não acompanha, o agente passa a operar contra um inventário que já não corresponde ao que existe.

Convenção interna ou catálogo gerenciado?

A decisão real não é entre comprar uma ferramenta e não comprar nada. É entre manter uma convenção que só funciona enquanto o time é pequeno, e operar um catálogo com metadado, escopo e ciclo de versão. As duas opções são legítimas em faixas diferentes de escala. A escala decide.

A leitura honesta da tabela é que a coluna da esquerda é correta até o momento em que deixa de ser, e ninguém marca a data. O sinal de que a data chegou tem nome: quando existe uma integração que ninguém consegue explicar de onde veio, e um agente em produção que a chama.

Onde essa camada encosta no modelo econômico

A conexão entre catálogo e custo não é óbvia, e vale desenhar. Cada tool publicada é uma chamada que pode ser repetida, e cada chamada repetida é token. Sem registro de quem consome o quê, a fatura de inferência de um mês não é atribuível a nenhum time, e a discussão sobre roteamento de custo fica sem base de rateio.

O mesmo vale para capacidade. Um catálogo que registra quantas tools cada servidor expõe e quantos consumidores as chamam permite comparar volume de invocação entre fornecedores e ajustar o custo por tarefa com dado, não com estimativa. A camada de registro é anterior ao roteamento, mas é ela que produz o inventário sobre o qual o roteamento vai operar.

Erros que aparecem depois do primeiro trimestre

Três padrões aparecem em praticamente toda operação que passa de um time piloto para vários, e nenhum deles é um erro de ferramenta. São erros de processo que a ferramenta apenas revela.

O primeiro é tratar o registry público como inventário interno. Ele não aceita servidor privado, e forçá-lo a aceitar significa publicar metadado de sistema interno em catálogo aberto. A saída correta é operar um registry privado que implemente a mesma especificação OpenAPI, o que também preserva o suporte das aplicações cliente.

O segundo é publicar sem dono. Um metadado sem responsável declarado é um metadado que ninguém atualiza, e a depreciação de uma tool sem dono acontece por abandono, não por decisão. Quando o servidor morre, o agente que o chamava descobre em produção.

O terceiro é confundir versão de servidor com versão de API remota. Para um servidor local, a recomendação é alinhar a versão do servidor com a versão do pacote. Para um servidor remoto com API versionada, a recomendação é alinhar com a versão da API. Misturar os dois regimes produz um catálogo em que a mesma string de versão significa duas coisas.

Na revisão corrente, o protocolo também marca features como depreciadas sem removê-las de imediato: uma feature depreciada documenta o caminho de migração e permanece na especificação por pelo menos doze meses antes de se tornar elegível para remoção. Quem opera catálogo interno precisa do mesmo mecanismo, com prazo declarado. Sem prazo, depreciação é intenção.

Perguntas frequentes

O que é um MCP registry? É um catálogo de metadados de servidores MCP. Guarda nome, versão, dono verificado, onde o pacote está hospedado e como executar. Não hospeda código nem tráfego, e existe para que um cliente descubra e conecte servidores sem configuração manual.

O registry oficial aceita servidores privados? Não. A documentação recomenda explicitamente que quem tem servidores internos, publicados em rede privada ou em registry de pacote privado, hospede um registry próprio. O registry oficial é um mecanismo de procedência para o que é público.

O que é mcp authorization e quando ela se aplica? É o fluxo de autorização do protocolo, baseado em OAuth 2.1, e ele é opcional. Quando implementado sobre transporte HTTP, o servidor age como resource server e o cliente descobre os metadados antes de chamar. Em transporte stdio, a recomendação é buscar credenciais do ambiente.

O que significa descoberta dinâmica de ferramentas em MCP? Um servidor pode declarar que vai notificar clientes quando a lista de tools disponíveis mudar. A descoberta é dinâmica por contrato da especificação, não por convenção de fornecedor. Um arquivo de configuração estático é uma fotografia, não um catálogo.

Uma versão publicada pode ser corrigida? Não. A versão precisa ser única por publicação e, uma vez publicada, versão e metadado não podem ser alterados. Corrigir exige publicar uma versão nova. O registry recusa strings que parecem faixa de versão, como ^1.2.3 e 1.2.*.

Dá para operar sem catálogo gerenciado? Dá, e é a escolha correta abaixo de algumas dezenas de integrações. O custo aparece quando uma integração não tem origem explicável e um agente em produção a chama. A convenção interna não falha por escala, falha por falta de dono declarado.

Referências e Leitura Complementar

• The MCP Registry, documentação oficial do protocolo, acesso em 17 de setembro de 2026: fonte única de verdade, formato server.json, namespace por DNS reverso, escopo para agregadores a jusante e a regra que não admite servidor privado.
• Versioning Published MCP Servers, acesso em 17 de setembro de 2026: imutabilidade da versão publicada, recomendação de versionamento semântico e a proibição de strings de faixa.
• How to Authenticate When Publishing to the Official MCP Registry, acesso em 17 de setembro de 2026: as formas de nome io.github.usuario/* e com.exemplo.*/*, e a autenticação por registro TXT no DNS.
• Authorization, especificação na revisão 2026-07-28, acesso em 17 de setembro de 2026: OAuth 2.1 como base, o caráter opcional da autorização e as normas do subconjunto implementado.
• Versioning, acesso em 17 de setembro de 2026: a revisão corrente, a negociação por requisição e a política de depreciação com prazo mínimo de doze meses.
• Tools, acesso em 17 de setembro de 2026: a capacidade tools com listChanged, que torna a descoberta dinâmica por contrato.
• Introducing the MCP Registry, 8 de setembro de 2025: o anúncio de lançamento do registry oficial em preview, com sub-registries públicos e privados.

O que fazer na segunda-feira

A ordem importa. Ela é o inverso da intuição. Antes de escolher um gateway, conte quantos servidores MCP a empresa tem, quantos donos declarados existem para eles e quantos consumidores chamam cada versão. Esse levantamento cabe em uma tarde e responde a pergunta que nenhuma decisão de tráfego responde.

Se o número for pequeno, uma convenção interna com dono nomeado por servidor resolve. Se o número passou da dezena, a camada de registro deixou de ser documentação e virou infraestrutura, e a diferença prática é quem responde quando um agente chama uma ferramenta que ninguém sabia que existia.

É exatamente essa transição que o Nexforce Agents endereça com o Nexforce Work: a camada de catálogo, permissões e conectores MCP existe para funcionar quando a operação sai de um time piloto e passa a vários, com a lista de ferramentas disponíveis sob controle em vez de sob convenção. Os agentes de IA B2B que rodam em produção dependem disso, e o Nexforce Code consome os mesmos servidores MCP como ferramentas externas.

O catálogo é a parte do sistema que ninguém olha até o dia em que ele é a única coisa que explica o que aconteceu.