O que é um Registro MCP? (E o Problema NxM que Ele Resolve)

TL;DR: Um registro MCP é um catálogo centralizado de servidores MCP - o que eles fazem, como se conectar, quais ferramentas expõem e quem está autorizado a chamá-los. Sem um, cada desenvolvedor e agente mantém sua própria cópia dessas informações, a rotação de credenciais quebra tudo e o controle de acesso não existe. Com um, a descoberta de ferramentas é dinâmica, as credenciais são gerenciadas centralmente e o RBAC governa o que cada agente pode ver e chamar. Este post cobre o que é, como funciona e os modos de falha específicos que ele previne.

Há um padrão que eu vi se desenrolar em quase todas as equipes que escalam além de alguns servidores MCP.

As primeiras conexões parecem mágica. Você executa npx @modelcontextprotocol/server-github em um terminal, aponta o Claude Code para ele e seu agente pode de repente pesquisar repositórios. Limpo, rápido, sem código de cola. Então você adiciona o Jira. Depois o Confluence. Depois um servidor MCP do Slack e uma API de dados interna. Agora você tem seis servidores e doze desenvolvedores, e cada desenvolvedor tem seu próprio ~/.cursor/mcp.json ou .claude/settings.json com detalhes de conexão e credenciais codificados.

Quando um endpoint de servidor muda, você atualiza doze arquivos de configuração manualmente. Quando uma credencial é rotacionada, você caça cada desenvolvedor que a armazenou em cache. Quando um novo engenheiro se junta, você passa meio dia explicando quais servidores existem e como se conectar. Quando alguém sai, você espera ter se lembrado de revogar seus tokens individuais em cada um dos seis sistemas.

Esse é o problema do post-it distribuído. Um registro MCP é a infraestrutura que o substitui.

O que é um registro MCP

Um registro MCP é um catálogo centralizado que armazena metadados sobre cada servidor MCP em sua organização - o que ele faz, como se conectar a ele, quais ferramentas expõe, qual método de autenticação utiliza e quem está autorizado a acessá-lo.

A analogia que fez sentido para mim: é para servidores MCP o que um servidor DNS é para endereços IP, ou o que um registro de serviços é para microsserviços. Em vez de codificar endereços em todos os lugares, você tem um lugar autoritativo que sabe onde tudo está e como alcançá-lo. Os componentes procuram as informações em vez de tê-las embutidas.

No mínimo, uma entrada de registro contém:

• Identidade do servidor - nome, descrição, equipe proprietária, status de aprovação
• Detalhes de conexão - URL do endpoint, tipo de transporte (stdio vs Streamable HTTP vs SSE)
• Metadados de autenticação - qual autenticação o servidor requer e como obter credenciais
• Esquema de ferramentas - quais ferramentas o servidor expõe, quais parâmetros cada uma aceita
• Política de acesso - quais usuários, equipes ou agentes estão autorizados a se conectar

A separação entre detalhes de conexão e metadados de autenticação é o que torna a rotação de credenciais barata. Quando um token OAuth do GitHub é rotacionado, você atualiza um registro no registro. Cada agente e desenvolvedor que se conecta através do registro pega as novas credenciais automaticamente — sem necessidade de caça a arquivos de configuração.

O problema N×M

O problema que um registro resolve tem um nome em sistemas distribuídos: o problema de integração N×M.

Se você tem N agentes e M servidores MCP e os conecta diretamente, você tem N×M pontos de integração. Cada um precisa de sua própria configuração de conexão, suas próprias credenciais, seu próprio tratamento de erros, sua própria versão de "o que acontece quando o servidor se move".

Com 3 agentes e 3 servidores, são 9 pontos de integração. Com 8 agentes e 6 servidores, são 48. Com 240 engenheiros e 8 servidores - o tipo de escala onde isso se torna um problema operacional real - você está mantendo aproximadamente 1.900 entradas de configuração manualmente.

Um registro colapsa isso. Cada servidor é registrado uma vez. Cada agente se conecta ao endpoint do registro, declara o que precisa e o registro direciona para o servidor certo com as credenciais corretas. Pontos de integração N+M em vez de N×M.

O benefício secundário: quando um servidor se move (nova URL, novo cluster, novo transporte), você atualiza uma entrada no registro. Nada a jusante quebra.

O que um registro não é

Vale a pena ser explícito porque "registro MCP" significa coisas diferentes em diferentes contextos:

O registro MCP público (o que está em registry.npmmcp.com ou similar) é um catálogo de descoberta — uma lista pesquisável de servidores MCP disponíveis publicamente que os desenvolvedores podem navegar para encontrar ferramentas. É como uma página de listagem de loja de aplicativos. Não autentica conexões, não impõe controle de acesso ou fornece um histórico de auditoria. É um ótimo lugar para encontrar servidores. Não é infraestrutura de produção.

Um registro MCP empresarial é sobre o que este post trata: o catálogo operado privadamente que governa como seus agentes específicos se conectam aos seus servidores específicos, com autenticação, RBAC e registro de auditoria. Mesmo conceito (metadados centralizados), contexto operacional diferente.

Um registro MCP não é um proxy. Um proxy lida com transporte. Um registro lida com metadados e políticas. Na prática, os dois são frequentemente implantados juntos — o registro conhece os servidores, o proxy realmente roteia o tráfego para eles — mas são componentes distintos.

A lacuna de governança no MCP bruto

O MCP bruto não tem controle de acesso embutido. Qualquer agente com a URL de conexão de um servidor pode chamar qualquer uma de suas ferramentas. O agente de um desenvolvedor júnior e o agente de um engenheiro sênior têm acesso idêntico. Um sub-agente com permissões excessivas tem o mesmo raio de explosão que a conta de serviço que o gerou.

A camada de governança que um registro adiciona:

RBAC no nível da ferramenta. Não apenas "a equipe A pode acessar o servidor Jira" mas "a equipe A pode chamar search_issues e create_issue mas não delete_issue." A política de acesso é definida no registro e aplicada antes que a chamada da ferramenta chegue ao servidor.

Filtragem de visibilidade pré-chamada de ferramenta. Os agentes só veem as ferramentas que estão autorizados a usar em primeiro lugar. Um agente que navega pelas ferramentas disponíveis via tools/list recebe uma lista filtrada com base em sua identidade — não o conjunto completo de capacidades do servidor. Isso é importante: um agente que não sabe que uma ferramenta destrutiva existe não pode chamá-la acidentalmente.

Gerenciamento centralizado de credenciais. Os usuários se autenticam uma vez no registro. O registro gerencia credenciais a jusante — tokens OAuth para GitHub, chaves de API para Jira, tokens de conta de serviço para APIs internas — e as atualiza automaticamente. A desativação é uma ação: revogar o acesso do usuário ao registro. Cada sistema a jusante está coberto.

Registro de auditoria por invocação de ferramenta. Cada chamada de ferramenta registrada: qual agente, qual identidade de usuário, qual ferramenta, quais parâmetros, qual foi a resposta, a que horas. Quando uma equipe de segurança pergunta "quais agentes acessaram a API de dados de produção no mês passado", é uma consulta em vez de dois dias de arqueologia de logs.

Servidores MCP Virtuais: o primitivo de escopo de acesso

Um conceito que vale a pena entender porque é genuinamente útil: Servidores MCP Virtuais.

Um servidor MCP virtual é um endpoint lógico curado que expõe um subconjunto de ferramentas de um ou mais servidores MCP reais. Em vez de dar a um agente acesso a um servidor MCP do Jira inteiro com todas as suas ferramentas de leitura e escrita, você define um servidor virtual chamado "finance-readonly" que expõe apenas as ferramentas do Jira que o fluxo de trabalho financeiro precisa — e nada mais.

O agente aponta para o endpoint do servidor virtual. Ele vê uma superfície de ferramenta limitada e apropriada para o propósito. O roteamento real para o servidor subjacente acontece dentro da camada de registro/gateway, invisível para o agente.

Esse é o padrão que resolve o problema do "agente com permissões excessivas" sem exigir que cada agente implemente seu próprio controle de acesso.